From paulej@packetizer.com Fri Oct 4 18:23:00 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8469521F9CAF for ; Fri, 4 Oct 2013 18:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cygXJb9VRaBw for ; Fri, 4 Oct 2013 18:22:55 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E2BBF21F9D9A for ; Fri, 4 Oct 2013 18:22:51 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r951Morp028436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 4 Oct 2013 21:22:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1380936170; bh=IJ8Z5wfKuxR9evP/ZeLvByDw1pXThT+XCjFC+ulQw4o=; h=From:To:Subject:Date:Content-Type:Message-Id:Mime-Version: Reply-To; b=GKOBcKeVE3iuFvRwGvzTBnVjKH81OrxBVVmEuKe3g7j84VkG6S0jCD0iSlddlT9qC bMEgjS1LKqi2UXICeCzOozZ7kkVEvdbUuM7qZD1jSdHNAQ9t7b/dtgTxiUk5W3Ot6F Ukq80m4rur1tyF+8UWFxa4QrWLvVuWpsw+5EL7Io= From: "Paul E. Jones" To: webfinger@ietf.org Date: Sat, 05 Oct 2013 01:22:59 +0000 Content-Type: multipart/alternative; boundary="------=_MB1768D863-ADA9-4A7F-9184-9ABD63556EC2" Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.18661.0 Subject: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Paul E. Jones" List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 01:23:00 -0000 --------=_MB1768D863-ADA9-4A7F-9184-9ABD63556EC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Folks, As you know, properties (both link and subject-specific properties) are=20 identified via a URI. For applications that are defined outside the=20 IETF, those organizations are able to define any URI they wish to use. =20 For any we might define within the IETF, however, we need something. In anticipation of having such a need, I think we should create a=20 document along the lines of RFC 6755 for WebFinger. Specifically, we=20 would define a URN sub-namespace as: urn:ietf:params:webfinger One such potentially-useful subject-specific properties are "name",=20 which would be the the subject's name intended for human consumption. =20 If you've queried my WebFinger server, you would know I currently=20 advertise my name in English and Chinese. For the "default" name, the=20 URN might be: urn:ietf:params:webfinger:name For language-specific variants, it might be: urn:ietf:params:webfinger:name:zh-CN Defining the various properties and their meaning is an exercise for=20 another day, but I hope you see the value in defining the URN=20 sub-namespace. Thoughts? Paul --------=_MB1768D863-ADA9-4A7F-9184-9ABD63556EC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Folks,
 
As you know, properties (both link and subject-specific properties)= are identified via a URI.  For applications that are defined outside= the IETF, those organizations are able to define any URI they wish to use.=   For any we might define within the IETF, however, we need something.=
 
In anticipation of having such a need, I think we should create a docu= ment along the lines of RFC 6755 for WebFinger.  Specifically, we woul= d define a URN sub-namespace as:
 
   urn:ietf:params:webfinger
 
One such potentially-useful subject-specific properties are "name",= which would be the the subject's name intended for human consumption. = ; If you've queried my WebFinger server, you would know I currently adverti= se my name in English and Chinese.  For the "default" name, the URN= might be:
 
   urn:ietf:params:webfinger:name
 
For language-specific variants, it might be:
 
   urn:ietf:params:webfinger:name:zh-CN
 
Defining the various properties and their meaning is an exercise for= another day, but I hope you see the value in defining the URN sub-namespac= e.
 
Thoughts?
 
Paul
 
--------=_MB1768D863-ADA9-4A7F-9184-9ABD63556EC2-- From barryleiba.mailing.lists@gmail.com Fri Oct 4 18:43:35 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594C621F9A97 for ; Fri, 4 Oct 2013 18:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.985 X-Spam-Level: X-Spam-Status: No, score=-101.985 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lExzLINfLQy4 for ; Fri, 4 Oct 2013 18:43:35 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D260C21F9978 for ; Fri, 4 Oct 2013 18:43:32 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eo20so3925572lab.3 for ; Fri, 04 Oct 2013 18:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xsIp8Dy78FxjYCeKFG4EyfEzNEcqPx85q4oEu14LVQc=; b=d3WD/QMsi0ql9hxA5luCnIAsKUDxMHmFLmC+eIwKPvM8ZUGRMyZqE9LfMOQTzSnIJV nnzMMbc9k9KLQU1uVOZ7QM58sGBv9b+jmCTigORt+AmT6077qT0KZDUsSl1GBepyl9Wm yc7RBwjAswqRmlDYLnkxGcXOwxUtO1ttlDbzt7ivEURpRKfNi2n9jp/CnTP8Kg+UGpXT Yw2zUsJgdE36DLQTwnGfMIjTw4Wp9/plNQH69gjd0HJQqJhfkVK7Synw4uie+zdOp8Ap CNSAJtDeuQA6W4NSnhdA8QxryL41Ig0Y29bH2ASAfPW/tJTB28HgeEHrotrg9ijUfxcu xEFA== MIME-Version: 1.0 X-Received: by 10.152.26.72 with SMTP id j8mr14478606lag.19.1380937410451; Fri, 04 Oct 2013 18:43:30 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.134.232 with HTTP; Fri, 4 Oct 2013 18:43:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Oct 2013 21:43:30 -0400 X-Google-Sender-Auth: RRcxBzzI-HoLAh-XkwlTK2JGBXQ Message-ID: From: Barry Leiba To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 01:43:35 -0000 > Defining the various properties and their meaning is an exercise for another > day, but I hope you see the value in defining the URN sub-namespace. I do, but I don't see the value of defining it *before* there's something to register in it. Had it been defined in the webfinger spec, I'd say fine. But it seems unnecessary to mint a document just to define it. Why not just let the first usage of it do the defining? Barry From melvincarvalho@gmail.com Sun Oct 6 06:19:53 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D77921F999C for ; Sun, 6 Oct 2013 06:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id segEsP35EDPM for ; Sun, 6 Oct 2013 06:19:52 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 84C4721E80AD for ; Sun, 6 Oct 2013 06:19:43 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id eo20so4610725lab.6 for ; Sun, 06 Oct 2013 06:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oudP2v2jJZp96yBA6unSnWdDo3hV73JzwIj72e3Mhu0=; b=MkmaUK0GXV/PMfIkGiqby+jsEe1MKQ1czxw8fb0u64ejwmSGVbMbr38VvwbEZTXzcH vaaGFZJTGaHeYpJcTeW/htwFyUnrngtw3wjzn5cTAgi5nHbZKb59tCgmDFNAq5b/69qN 5GWWzykVWATpx7F6VaOZojnsF4NxyEw3L4c+CbjAufgjHiN5lmKfLTQdFz7udt70EgkM U5JtyC+P6EmlT7gzZMtbcJwIsyK5JZASqg1G8kljpNjqxYoU0SS/DZonfwS1L3y3FIGr zG8PAIA5sGq7cgsjYSZTPpyPCtrzLWVBGqN0KH8r3nTZfScYdYac/hrJowJtCVehUx5L h4aw== MIME-Version: 1.0 X-Received: by 10.112.51.101 with SMTP id j5mr20762440lbo.17.1381065582434; Sun, 06 Oct 2013 06:19:42 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Sun, 6 Oct 2013 06:19:42 -0700 (PDT) In-Reply-To: References: Date: Sun, 6 Oct 2013 15:19:42 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a1133646073e1b704e8126360 Cc: webfinger Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 13:19:53 -0000 --001a1133646073e1b704e8126360 Content-Type: text/plain; charset=ISO-8859-1 On 5 October 2013 03:22, Paul E. Jones wrote: > Folks, > > As you know, properties (both link and subject-specific properties) are > identified via a URI. For applications that are defined outside the IETF, > those organizations are able to define any URI they wish to use. For any > we might define within the IETF, however, we need something. > > In anticipation of having such a need, I think we should create a document > along the lines of RFC 6755 for WebFinger. Specifically, we would define a > URN sub-namespace as: > > urn:ietf:params:webfinger > > One such potentially-useful subject-specific properties are "name", which > would be the the subject's name intended for human consumption. If you've > queried my WebFinger server, you would know I currently advertise my name > in English and Chinese. For the "default" name, the URN might be: > > urn:ietf:params:webfinger:name > > For language-specific variants, it might be: > > urn:ietf:params:webfinger:name:zh-CN > > Defining the various properties and their meaning is an exercise for > another day, but I hope you see the value in defining the URN sub-namespace. > Cant this be done using traditional HTTP keys. The advantage being that they can be systematically dereferenced using http GET, rather than having to look it up in a central registry in a non machine readable way. This is what has been going on for 10+ years, with FOAF, schema.org, open graph protocol and others. Have I missed something? > > Thoughts? > > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --001a1133646073e1b704e8126360 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 5 October 2013 03:22, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:
Folks,
=A0
As you know, properties (both link and subject-specific properties) ar= e identified via a URI.=A0 For applications that are defined outside the IE= TF, those organizations are able to define any URI they wish to use.=A0 For= any we might define within the IETF, however, we need something.
=A0
In anticipation of having such a need, I think we should create a docu= ment along the lines of RFC 6755 for WebFinger.=A0 Specifically, we would d= efine a URN sub-namespace as:
=A0
=A0=A0 urn:ietf:params:webfinger
=A0
One such potentially-useful subject-specific properties are "name= ", which would be the the subject's name intended for human consum= ption.=A0 If you've queried my WebFinger server, you would know I curre= ntly advertise my name in English and Chinese.=A0 For the "default&quo= t; name, the URN might be:
=A0
=A0=A0 urn:ietf:params:webfinger:name
=A0
For language-specific variants, it might be:
=A0
=A0=A0 urn:ietf:params:webfinger:name:zh-CN
=A0
Defining the various properties and their meaning is an exercise for a= nother day, but I hope you see the value in defining the URN sub-namespace.=

=A0
=A0
Thoughts?
=A0
Paul
=A0

___________= ____________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--001a1133646073e1b704e8126360-- From ve7jtb@ve7jtb.com Sun Oct 6 07:05:42 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0034521E80C3 for ; Sun, 6 Oct 2013 07:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTgEiQitfSx7 for ; Sun, 6 Oct 2013 07:05:30 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id AA10A21E80BD for ; Sun, 6 Oct 2013 07:05:29 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id f12so6130686wgh.5 for ; Sun, 06 Oct 2013 07:05:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=w/sfI8cPnXKvnQ98CiSV72p7bP+VtvjxOKZpGfZ9K48=; b=SB0V7T61Y2+BMhA4ALoN1mm4gsJIh7trYfgkkCw4fmSLP4G/FxmsmDxgrZCRntAqCZ NabxzapytrQB44CpbCqkVpgPd/qz5FCESHJt9692eR0IusLbahIJS5QuI9A8jU9HHkKk HAx/bQ7ppW8LWiBOJ3oErPoiycEKPlcnfbtsnA+uqE9ng9sfgcdvVE839amGdGRcavAm au+NmBgPxp+tPF4XiAQzSghp1fVdaO5hpALzxv8gFUgfqCTiatUHH6/b2DIXnFOVfDO8 fcpGbiMmTbaUClcH7Sn2sWqKwpRlUl+b4mELvjkpJAqi6vHSGp6KGtCn+sFJzdWnEnx+ s6Vw== X-Gm-Message-State: ALoCoQlqW7x72jWrst3FodzrwMcslOSa6LX436I8NX3ILXZcyZoRetxYysPxVP4GGaM9cQk9JlY3 X-Received: by 10.180.198.44 with SMTP id iz12mr15328819wic.32.1381068328574; Sun, 06 Oct 2013 07:05:28 -0700 (PDT) Received: from [192.168.0.93] ([195.99.165.34]) by mx.google.com with ESMTPSA id q5sm29666072wiz.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Oct 2013 07:05:27 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_67BCB271-F469-45E4-91F9-81752626E3FF"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: John Bradley In-Reply-To: Date: Sun, 6 Oct 2013 15:05:25 +0100 Message-Id: <208721BC-8EB8-418B-8F71-AA4642F11208@ve7jtb.com> References: To: Melvin Carvalho X-Mailer: Apple Mail (2.1510) Cc: "Paul E. Jones" , webfinger Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 14:05:42 -0000 --Apple-Mail=_67BCB271-F469-45E4-91F9-81752626E3FF Content-Type: multipart/alternative; boundary="Apple-Mail=_D0D8A461-048B-4BFF-BC2C-94C2CC81475F" --Apple-Mail=_D0D8A461-048B-4BFF-BC2C-94C2CC81475F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 That was my assumption as well. There is no requirement for a URN = namespace,. Documenting the usage of the agreed http URI keys is the task that needs = to undertaken by someone, John B. On 2013-10-06, at 2:19 PM, Melvin Carvalho = wrote: >=20 >=20 >=20 > On 5 October 2013 03:22, Paul E. Jones wrote: > Folks, > =20 > As you know, properties (both link and subject-specific properties) = are identified via a URI. For applications that are defined outside the = IETF, those organizations are able to define any URI they wish to use. = For any we might define within the IETF, however, we need something. > =20 > In anticipation of having such a need, I think we should create a = document along the lines of RFC 6755 for WebFinger. Specifically, we = would define a URN sub-namespace as: > =20 > urn:ietf:params:webfinger > =20 > One such potentially-useful subject-specific properties are "name", = which would be the the subject's name intended for human consumption. = If you've queried my WebFinger server, you would know I currently = advertise my name in English and Chinese. For the "default" name, the = URN might be: > =20 > urn:ietf:params:webfinger:name > =20 > For language-specific variants, it might be: > =20 > urn:ietf:params:webfinger:name:zh-CN > =20 > Defining the various properties and their meaning is an exercise for = another day, but I hope you see the value in defining the URN = sub-namespace. >=20 > Cant this be done using traditional HTTP keys. The advantage being = that they can be systematically dereferenced using http GET, rather than = having to look it up in a central registry in a non machine readable = way. This is what has been going on for 10+ years, with FOAF, = schema.org, open graph protocol and others. Have I missed something? > =20 > =20 > Thoughts? > =20 > Paul > =20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail=_D0D8A461-048B-4BFF-BC2C-94C2CC81475F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 That was my assumption as well.   There is no requirement for a URN namespace,.

Documenting the usage of the agreed http URI keys is the task that needs to undertaken by someone,


John B.


On 2013-10-06, at 2:19 PM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:




On 5 October 2013 03:22, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,
 
As you know, properties (both link and subject-specific properties) are identified via a URI.  For applications that are defined outside the IETF, those organizations are able to define any URI they wish to use.  For any we might define within the IETF, however, we need something.
 
In anticipation of having such a need, I think we should create a document along the lines of RFC 6755 for WebFinger.  Specifically, we would define a URN sub-namespace as:
 
   urn:ietf:params:webfinger
 
One such potentially-useful subject-specific properties are "name", which would be the the subject's name intended for human consumption.  If you've queried my WebFinger server, you would know I currently advertise my name in English and Chinese.  For the "default" name, the URN might be:
 
   urn:ietf:params:webfinger:name
 
For language-specific variants, it might be:
 
   urn:ietf:params:webfinger:name:zh-CN
 
Defining the various properties and their meaning is an exercise for another day, but I hope you see the value in defining the URN sub-namespace.

Cant this be done using traditional HTTP keys.  The advantage being that they can be systematically dereferenced using http GET, rather than having to look it up in a central registry in a non machine readable way.  This is what has been going on for 10+ years, with FOAF, schema.org, open graph protocol and others.  Have I missed something?
 
 
Thoughts?
 
Paul
 

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--Apple-Mail=_D0D8A461-048B-4BFF-BC2C-94C2CC81475F-- --Apple-Mail=_67BCB271-F469-45E4-91F9-81752626E3FF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDA2MTQwNTI1WjAjBgkqhkiG9w0BCQQxFgQUavadRVLl 6R5yFUV0o81TBEOFtLcwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAS0Ch44ETtw5tKdezP+wwLIRbayzMly5s9KKtfKm7 ADhx38vt3oDhNfnP+qBWSXlp3WyCdoJbxzkN7gQNd3mnWid5F3UwxGZPrjIijjCrQ0h78bOa8cTt rhiRyB6mDrdimbzJ12W5XuxMdi12untxHiqfv3EDeBo/OiVRHAC22ms35YfLBuq/WckvcA4tipp5 Q38uh+OEbZwf4IhltQAk0tt+jNrF2CK3LNHlCXTM91E9/CzQf1Vp0GMjGYDG4FPIs7K3hMFSRtT8 jcLiuKd4vnV+rnkgE52TeYCV6WIWoXMAIL3GVE/4HeJdWkdwaCd2xTNeAAzwx/ROUQC9YlfeaAAA AAAAAA== --Apple-Mail=_67BCB271-F469-45E4-91F9-81752626E3FF-- From paulej@packetizer.com Sun Oct 6 08:16:47 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E42A21E80C3 for ; Sun, 6 Oct 2013 08:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtFQSiyWnDAO for ; Sun, 6 Oct 2013 08:16:43 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 16BC421E80C1 for ; Sun, 6 Oct 2013 08:16:43 -0700 (PDT) Received: from dyn-157.arid.us (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r96FGdHE021106 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 6 Oct 2013 11:16:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1381072600; bh=7lIdhZxhf7fKuwXABvnPlhW6YQRFCPMRxFvEnG9G4F0=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=WkOAGhDF3BVYo+bStpR8QY7gzmsdkV6vc7wN71WgBS3frli2N46VdVfX98vASI79E gt9hFW/qmF6/s/YLmb69YxggtAnvZkrDW69+qUqVLp34292/XUZusayN2k6FjwM+Me dmjMjg6hZ1/oeiWqSgtHDRgkFaxjhUI53j/yqoBA= User-Agent: Kaiten Mail In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----X9OVXXT4Q9XW9Y4G3V26QFWB40NHT1" From: "Paul E. Jones" Date: Sun, 06 Oct 2013 11:16:38 -0400 To: Melvin Carvalho Message-ID: Cc: webfinger Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 15:16:47 -0000 ------X9OVXXT4Q9XW9Y4G3V26QFWB40NHT1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Yes, any URI can be used to identify a property. However, there has to be some agreed scheme and structure for things defined in the IETF. The point of the suggestion was to specify that. We could use HTTP, but I've never seen that scheme used in IETF documents for this type of thing. I've seen URNs, though. Paul -------- Original Message -------- From: Melvin Carvalho Sent: Sun Oct 06 09:19:42 EDT 2013 To: "Paul E. Jones" Cc: webfinger Subject: Re: [webfinger] Registration of a URN for WebFinger Properties On 5 October 2013 03:22, Paul E. Jones wrote: > Folks, > > As you know, properties (both link and subject-specific properties) are > identified via a URI. For applications that are defined outside the IETF, > those organizations are able to define any URI they wish to use. For any > we might define within the IETF, however, we need something. > > In anticipation of having such a need, I think we should create a document > along the lines of RFC 6755 for WebFinger. Specifically, we would define a > URN sub-namespace as: > > urn:ietf:params:webfinger > > One such potentially-useful subject-specific properties are "name", which > would be the the subject's name intended for human consumption. If you've > queried my WebFinger server, you would know I currently advertise my name > in English and Chinese. For the "default" name, the URN might be: > > urn:ietf:params:webfinger:name > > For language-specific variants, it might be: > > urn:ietf:params:webfinger:name:zh-CN > > Defining the various properties and their meaning is an exercise for > another day, but I hope you see the value in defining the URN sub-namespace. > Cant this be done using traditional HTTP keys. The advantage being that they can be systematically dereferenced using http GET, rather than having to look it up in a central registry in a non machine readable way. This is what has been going on for 10+ years, with FOAF, schema.org, open graph protocol and others. Have I missed something? > > Thoughts? > > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > ------X9OVXXT4Q9XW9Y4G3V26QFWB40NHT1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Yes, any URI can be used to identify a property. However, there has to be some agreed scheme and structure for things defined in the IETF. The point of the suggestion was to specify that.

We could use HTTP, but I've never seen that scheme used in IETF documents for this type of thing. I've seen URNs, though.

Paul



From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sun Oct 06 09:19:42 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] Registration of a URN for WebFinger Properties




On 5 October 2013 03:22, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,
 
As you know, properties (both link and subject-specific properties) are identified via a URI.  For applications that are defined outside the IETF, those organizations are able to define any URI they wish to use.  For any we might define within the IETF, however, we need something.
 
In anticipation of having such a need, I think we should create a document along the lines of RFC 6755 for WebFinger.  Specifically, we would define a URN sub-namespace as:
 
   urn:ietf:params:webfinger
 
One such potentially-useful subject-specific properties are "name", which would be the the subject's name intended for human consumption.  If you've queried my WebFinger server, you would know I currently advertise my name in English and Chinese.  For the "default" name, the URN might be:
 
   urn:ietf:params:webfinger:name
 
For language-specific variants, it might be:
 
   urn:ietf:params:webfinger:name:zh-CN
 
Defining the various properties and their meaning is an exercise for another day, but I hope you see the value in defining the URN sub-namespace.

Cant this be done using traditional HTTP keys.  The advantage being that they can be systematically dereferenced using http GET, rather than having to look it up in a central registry in a non machine readable way.  This is what has been going on for 10+ years, with FOAF, schema.org, open graph protocol and others.  Have I missed something?
 
 
Thoughts?
 
Paul
 

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


------X9OVXXT4Q9XW9Y4G3V26QFWB40NHT1-- From wnorris@gmail.com Thu Oct 10 10:50:27 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E0721F9A40 for ; Thu, 10 Oct 2013 10:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxtmd4EMBV51 for ; Thu, 10 Oct 2013 10:50:23 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2E63221F9BAD for ; Thu, 10 Oct 2013 10:49:31 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id f12so2944893wgh.14 for ; Thu, 10 Oct 2013 10:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Hm7R/FNIvE2eK9G39uW7E9EGZ6jY+CXZBT8nFc2LveQ=; b=IYjAXZWr/btMzD/WXs+Eorxs5LV7ODH8bpw8VtF5BxYXYsDwPRHL76JATJ5foXGYx/ dFiDaivYX5TaIXtiHlgXhKzleC+uoMPfIJwtb+jksCfmaFSN5k39lwVR0zXO3KEmaBSZ qYZMPGA2vHf+Uwn9U1WNxSwbmtme/s3i9qab3nzptv0HuvHFwxooip9DUd1tP3lB3jpD QZpLMETcmLWv4vWJxVHfD2p+1CFO3D7JjWflQamwbvzptcrK3VJzuuXJRwwfYvRXHLRx Ru/JSlLacOGe1cqc0/KyMhcuvy6PufJmvVcvYD1cXHefR6PWQMiTT4O9NfVLJb7KWH4/ dupQ== X-Received: by 10.180.89.42 with SMTP id bl10mr8714755wib.47.1381427369108; Thu, 10 Oct 2013 10:49:29 -0700 (PDT) MIME-Version: 1.0 Sender: wnorris@gmail.com Received: by 10.194.108.233 with HTTP; Thu, 10 Oct 2013 10:48:59 -0700 (PDT) In-Reply-To: References: From: Will Norris Date: Thu, 10 Oct 2013 10:48:59 -0700 X-Google-Sender-Auth: JtLTs9yGq4AiOt0vEfVpES9hWSo Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d04447e2f9e78dd04e8669f34 Cc: webfinger , Melvin Carvalho Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 17:50:28 -0000 --f46d04447e2f9e78dd04e8669f34 Content-Type: text/plain; charset=ISO-8859-1 There irony here is that WebFinger itself was created to solve the problem of resolving an otherwise unresolvable URI (originally mailto and later acct URIs). URNs have the same problem, and since they have no well-defined host, you can't even use WebFinger to resolve them. I know there have been some efforts to define URN resolution (rfc2483 et al), but as far as I know none are very well adopted. Using HTTP URIs makes the most sense to me. But do we really need yet another registry of properties, the vast majority of which I'm sure have been defined in a dozen other places? Is there a reason why reusing one of these existing namespaces would not work? (and if something WebFinger specific really is desirable, then we can continue using webfinger.net, which has already been used for http://webfinger.net/rel/avatar/ and http://webfinger.net/rel/profile-page/. That was kind of the idea of running it as a static site out of the GitHub "webfinger" org; it's very easy to give others access to everything. That's what we've done with activitystrea.ms for several years now) On Sun, Oct 6, 2013 at 8:16 AM, Paul E. Jones wrote: > Yes, any URI can be used to identify a property. However, there has to be > some agreed scheme and structure for things defined in the IETF. The point > of the suggestion was to specify that. > > We could use HTTP, but I've never seen that scheme used in IETF documents > for this type of thing. I've seen URNs, though. > > Paul > > > ------------------------------ > *From:* Melvin Carvalho > *Sent:* Sun Oct 06 09:19:42 EDT 2013 > *To:* "Paul E. Jones" > *Cc:* webfinger > *Subject:* Re: [webfinger] Registration of a URN for WebFinger Properties > > > > > On 5 October 2013 03:22, Paul E. Jones wrote: > >> Folks, >> >> As you know, properties (both link and subject-specific properties) are >> identified via a URI. For applications that are defined outside the IETF, >> those organizations are able to define any URI they wish to use. For any >> we might define within the IETF, however, we need something. >> >> In anticipation of having such a need, I think we should create a >> document along the lines of RFC 6755 for WebFinger. Specifically, we would >> define a URN sub-namespace as: >> >> urn:ietf:params:webfinger >> >> One such potentially-useful subject-specific properties are "name", which >> would be the the subject's name intended for human consumption. If you've >> queried my WebFinger server, you would know I currently advertise my name >> in English and Chinese. For the "default" name, the URN might be: >> >> urn:ietf:params:webfinger:name >> >> For language-specific variants, it might be: >> >> urn:ietf:params:webfinger:name:zh-CN >> >> Defining the various properties and their meaning is an exercise for >> another day, but I hope you see the value in defining the URN sub-namespace. >> > > Cant this be done using traditional HTTP keys. The advantage being that > they can be systematically dereferenced using http GET, rather than having > to look it up in a central registry in a non machine readable way. This is > what has been going on for 10+ years, with FOAF, schema.org, open graph > protocol and others. Have I missed something? > > >> >> Thoughts? >> >> Paul >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --f46d04447e2f9e78dd04e8669f34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There irony here is that WebFinger itself was created to s= olve the problem of resolving an otherwise unresolvable URI (originally mai= lto and later acct URIs). =A0URNs have the same problem, and since they hav= e no well-defined host, you can't even use WebFinger to resolve them. = =A0I know there have been some efforts to define URN resolution (rfc2483 et= al), but as far as I know none are very well adopted. =A0Using HTTP URIs m= akes the most sense to me.

But do we really need yet another registry of properties, th= e vast majority of which I'm sure have been defined in a dozen other pl= aces? =A0Is there a reason why reusing one of these existing namespaces wou= ld not work? =A0(and if something WebFinger specific really is desirable, t= hen we can continue using webfinger.net, which has already been used for=A0http://webfinger.net/rel/avatar/ and=A0http://webfinger.net/rel/profile-page/. =A0Th= at was kind of the idea of running it as a static site out of the GitHub &q= uot;webfinger" org; it's very easy to give others access to everyt= hing. =A0That's what we've done with activitystrea.ms for several years now)


On Sun,= Oct 6, 2013 at 8:16 AM, Paul E. Jones <paulej@packetizer.com><= /span> wrote:

Yes, any URI can be used= to identify a property. However, there has to be some agreed scheme and st= ructure for things defined in the IETF. The point of the suggestion was to = specify that.

We could use HTTP, but I've never seen that scheme used = in IETF documents for this type of thing. I've seen URNs, though.

Paul



From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sun Oct 06 09:19:42 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] Registration of a URN for WebFinger Propert= ies




On 5 October 2013 03:22, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:
Folks,
=A0
As you know, properties (both link and subject-specific properties) ar= e identified via a URI.=A0 For applications that are defined outside the IE= TF, those organizations are able to define any URI they wish to use.=A0 For= any we might define within the IETF, however, we need something.
=A0
In anticipation of having such a need, I think we should create a docu= ment along the lines of RFC 6755 for WebFinger.=A0 Specifically, we would d= efine a URN sub-namespace as:
=A0
=A0=A0 urn:ietf:params:webfinger
=A0
One such potentially-useful subject-specific properties are "name= ", which would be the the subject's name intended for human consum= ption.=A0 If you've queried my WebFinger server, you would know I curre= ntly advertise my name in English and Chinese.=A0 For the "default&quo= t; name, the URN might be:
=A0
=A0=A0 urn:ietf:params:webfinger:name
=A0
For language-specific variants, it might be:
=A0
=A0=A0 urn:ietf:params:webfinger:name:zh-CN
=A0
Defining the various properties and their meaning is an exercise for a= nother day, but I hope you see the value in defining the URN sub-namespace.=

=A0
=A0
Thoughts?
=A0
Paul
=A0

__________________= _____________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger



_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--f46d04447e2f9e78dd04e8669f34-- From melvincarvalho@gmail.com Thu Oct 10 10:54:04 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA2421E8116 for ; Thu, 10 Oct 2013 10:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVIn7nz6Fgy8 for ; Thu, 10 Oct 2013 10:53:46 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id BC0D221E811A for ; Thu, 10 Oct 2013 10:53:28 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id x18so2390637lbi.24 for ; Thu, 10 Oct 2013 10:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cbvZMK3/SaBuofXDQNwcaHBuh8ukJ4Cwib0/Rh1tYng=; b=ej6AviW9m8iEL/sJi+TKt7eVdULb9CIUOTsyMvic8yYPTC+w5F9LknC9lmUwRl0a4x 7CkdA7peLgpQQvbrhTwdEZuV1M/qk00YkG9akrY9ezQy3q1XFpZSC1v9aYI7RD9QrLtY GcD7YBBITudEDnrsgFCNpChnCKiSd9ObX936y7CvEh0+2m9nIrBrVxzCvbinCwjiS/ft YSfMmAcPhjzGscGjyhXCiFgviASa4y0QyDBrBRB6DTm/oeFgFlpyoLAF+w2rlqhJ74GY RjMdEiwxCRazUCBWfSCJ7jQ+efa/MxDinqymgbf5Ot4xqUso8UpZ+IiBr+uXjhuePlkS /NLA== MIME-Version: 1.0 X-Received: by 10.112.89.100 with SMTP id bn4mr12993457lbb.16.1381427594972; Thu, 10 Oct 2013 10:53:14 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Thu, 10 Oct 2013 10:53:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Oct 2013 19:53:14 +0200 Message-ID: From: Melvin Carvalho To: Will Norris Content-Type: multipart/alternative; boundary=001a11c379ec14d61e04e866ad55 Cc: "Paul E. Jones" , webfinger Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 17:54:04 -0000 --001a11c379ec14d61e04e866ad55 Content-Type: text/plain; charset=ISO-8859-1 On 10 October 2013 19:48, Will Norris wrote: > There irony here is that WebFinger itself was created to solve the problem > of resolving an otherwise unresolvable URI (originally mailto and later > acct URIs). URNs have the same problem, and since they have no > well-defined host, you can't even use WebFinger to resolve them. I know > there have been some efforts to define URN resolution (rfc2483 et al), but > as far as I know none are very well adopted. Using HTTP URIs makes the > most sense to me. > > But do we really need yet another registry of properties, the vast > majority of which I'm sure have been defined in a dozen other places? Is > there a reason why reusing one of these existing namespaces would not work? > (and if something WebFinger specific really is desirable, then we can > continue using webfinger.net, which has already been used for > http://webfinger.net/rel/avatar/ and > http://webfinger.net/rel/profile-page/. That was kind of the idea of > running it as a static site out of the GitHub "webfinger" org; it's very > easy to give others access to everything. That's what we've done with > activitystrea.ms for several years now) > +1 Yes, that's nice but Id suggest it's better to put all the terms in one single file to reduce multiple HTTP GETs and maintenance. Also I forgot to mention VCard which also covers a lot of terms needed. > > > On Sun, Oct 6, 2013 at 8:16 AM, Paul E. Jones wrote: > >> Yes, any URI can be used to identify a property. However, there has to be >> some agreed scheme and structure for things defined in the IETF. The point >> of the suggestion was to specify that. >> >> We could use HTTP, but I've never seen that scheme used in IETF documents >> for this type of thing. I've seen URNs, though. >> >> Paul >> >> >> ------------------------------ >> *From:* Melvin Carvalho >> *Sent:* Sun Oct 06 09:19:42 EDT 2013 >> *To:* "Paul E. Jones" >> *Cc:* webfinger >> *Subject:* Re: [webfinger] Registration of a URN for WebFinger Properties >> >> >> >> >> On 5 October 2013 03:22, Paul E. Jones wrote: >> >>> Folks, >>> >>> As you know, properties (both link and subject-specific properties) are >>> identified via a URI. For applications that are defined outside the IETF, >>> those organizations are able to define any URI they wish to use. For any >>> we might define within the IETF, however, we need something. >>> >>> In anticipation of having such a need, I think we should create a >>> document along the lines of RFC 6755 for WebFinger. Specifically, we would >>> define a URN sub-namespace as: >>> >>> urn:ietf:params:webfinger >>> >>> One such potentially-useful subject-specific properties are "name", >>> which would be the the subject's name intended for human consumption. If >>> you've queried my WebFinger server, you would know I currently advertise my >>> name in English and Chinese. For the "default" name, the URN might be: >>> >>> urn:ietf:params:webfinger:name >>> >>> For language-specific variants, it might be: >>> >>> urn:ietf:params:webfinger:name:zh-CN >>> >>> Defining the various properties and their meaning is an exercise for >>> another day, but I hope you see the value in defining the URN sub-namespace. >>> >> >> Cant this be done using traditional HTTP keys. The advantage being that >> they can be systematically dereferenced using http GET, rather than having >> to look it up in a central registry in a non machine readable way. This is >> what has been going on for 10+ years, with FOAF, schema.org, open graph >> protocol and others. Have I missed something? >> >> >>> >>> Thoughts? >>> >>> Paul >>> >>> >>> _______________________________________________ >>> webfinger mailing list >>> webfinger@ietf.org >>> https://www.ietf.org/mailman/listinfo/webfinger >>> >>> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> > --001a11c379ec14d61e04e866ad55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 10 October 2013 19:48, Will Norris <will@willnorris.com&g= t; wrote:
There irony here is that We= bFinger itself was created to solve the problem of resolving an otherwise u= nresolvable URI (originally mailto and later acct URIs). =A0URNs have the s= ame problem, and since they have no well-defined host, you can't even u= se WebFinger to resolve them. =A0I know there have been some efforts to def= ine URN resolution (rfc2483 et al), but as far as I know none are very well= adopted. =A0Using HTTP URIs makes the most sense to me.

But do we really need yet another registry of properties, th= e vast majority of which I'm sure have been defined in a dozen other pl= aces? =A0Is there a reason why reusing one of these existing namespaces wou= ld not work? =A0(and if something WebFinger specific really is desirable, t= hen we can continue using webfinger.net, which has already been used for=A0http://webfinger.net/rel/avatar/= and=A0http://webfinger.net/rel/profile-page/. =A0That was kind of the id= ea of running it as a static site out of the GitHub "webfinger" o= rg; it's very easy to give others access to everything. =A0That's w= hat we've done with activitystrea.ms for several years now)

+1

Yes, that's nice but I= d suggest it's better to put all the terms in one single file to reduce= multiple HTTP GETs and maintenance.

Also I forgot to me= ntion VCard which also covers a lot of terms needed.
=A0

On Sun, Oct 6, 2013 at 8:16 AM, Paul E. Jo= nes <paulej@packetizer.com> wrote:

Yes, any URI can be used= to identify a property. However, there has to be some agreed scheme and st= ructure for things defined in the IETF. The point of the suggestion was to = specify that.

We could use HTTP, but I've never seen that scheme used = in IETF documents for this type of thing. I've seen URNs, though.

Paul



From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sun Oct 06 09:19:42 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] Registration of a URN for WebFinger Propert= ies




On 5 October 2013 03:22, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:
Folks,
=A0
As you know, properties (both link and subject-specific properties) ar= e identified via a URI.=A0 For applications that are defined outside the IE= TF, those organizations are able to define any URI they wish to use.=A0 For= any we might define within the IETF, however, we need something.
=A0
In anticipation of having such a need, I think we should create a docu= ment along the lines of RFC 6755 for WebFinger.=A0 Specifically, we would d= efine a URN sub-namespace as:
=A0
=A0=A0 urn:ietf:params:webfinger
=A0
One such potentially-useful subject-specific properties are "name= ", which would be the the subject's name intended for human consum= ption.=A0 If you've queried my WebFinger server, you would know I curre= ntly advertise my name in English and Chinese.=A0 For the "default&quo= t; name, the URN might be:
=A0
=A0=A0 urn:ietf:params:webfinger:name
=A0
For language-specific variants, it might be:
=A0
=A0=A0 urn:ietf:params:webfinger:name:zh-CN
=A0
Defining the various properties and their meaning is an exercise for a= nother day, but I hope you see the value in defining the URN sub-namespace.=

=A0
=A0
Thoughts?
=A0
Paul
=A0

__________________= _____________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger



_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger



--001a11c379ec14d61e04e866ad55-- From wnorris@gmail.com Thu Oct 10 11:04:38 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81D921E8085 for ; Thu, 10 Oct 2013 11:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROq68b0NBavQ for ; Thu, 10 Oct 2013 11:04:34 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E9AD821E8116 for ; Thu, 10 Oct 2013 11:03:57 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq15so10545787wib.0 for ; Thu, 10 Oct 2013 11:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=T7k0eDvF4MUiI5Mp06ubwsZxfChsb+39LHTdml8jZwY=; b=O2uwppytIl6jK3cOO8qB9BaW3t2Aca5a0KGeBHfLFUJJ5ugrWfJKoT0fY415UmosI0 SmcxYAaVd03Djk/TgWGPwJNfzZfU1muEDT2Uex/BdrDsRHsepoM8SDfWn2EwM249uw9+ rb0HdwJ/w5E5rhVZ55ImtzDsEgD+R1KitybeW9TG5MBiYGmYvrRMKs3Cl/b8hwqYn4F0 ewLfjsmg09rKo36p0y4lA1gce0d9ijNkpqKzJbEZPhU6QsJR/A/hY3z/VDvG4hFqeLA0 u6haqQAWGCQi2J6YgdLwodIyGlPoRhXPR5IIDPGsc1IUUF2K2eGjy5+YgWIThubjrR8A f8ng== X-Received: by 10.180.208.2 with SMTP id ma2mr8212872wic.52.1381428236959; Thu, 10 Oct 2013 11:03:56 -0700 (PDT) MIME-Version: 1.0 Sender: wnorris@gmail.com Received: by 10.194.108.233 with HTTP; Thu, 10 Oct 2013 11:03:26 -0700 (PDT) In-Reply-To: References: From: Will Norris Date: Thu, 10 Oct 2013 11:03:26 -0700 X-Google-Sender-Auth: EFxsCRksqBWsGLGW5qEdYEt8HYQ Message-ID: To: Melvin Carvalho Content-Type: multipart/alternative; boundary=001a11c38dfc58ca6e04e866d30b Cc: "Paul E. Jones" , webfinger Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 18:04:38 -0000 --001a11c38dfc58ca6e04e866d30b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 10, 2013 at 10:53 AM, Melvin Carvalho wrote: > > > > On 10 October 2013 19:48, Will Norris wrote: > >> There irony here is that WebFinger itself was created to solve the >> problem of resolving an otherwise unresolvable URI (originally mailto and >> later acct URIs). URNs have the same problem, and since they have no >> well-defined host, you can't even use WebFinger to resolve them. I know >> there have been some efforts to define URN resolution (rfc2483 et al), but >> as far as I know none are very well adopted. Using HTTP URIs makes the >> most sense to me. >> >> But do we really need yet another registry of properties, the vast >> majority of which I'm sure have been defined in a dozen other places? Is >> there a reason why reusing one of these existing namespaces would not work? >> (and if something WebFinger specific really is desirable, then we can >> continue using webfinger.net, which has already been used for >> http://webfinger.net/rel/avatar/ and >> http://webfinger.net/rel/profile-page/. That was kind of the idea of >> running it as a static site out of the GitHub "webfinger" org; it's very >> easy to give others access to everything. That's what we've done with >> activitystrea.ms for several years now) >> > > +1 > > Yes, that's nice but Id suggest it's better to put all the terms in one > single file to reduce multiple HTTP GETs and maintenance. > multiple GETs by whom? I suspect that these will typically resolve to human readable descriptions of the properties... I don't imagine they'd be automatically fetched by anything/anyone. We could of course embed some machine readable version of the property in the pages, but even then I'm not exactly sure what the use-case would be. That said, I don't actually have strong feelings on this. > > Also I forgot to mention VCard which also covers a lot of terms needed. > yep, though I'm not sure if they have URI equivalents for property names. There is a URN for the XML namespace (urn:ietf:params:xml:ns:vcard-4.0), but that's gets us back to where we started. > > >> >> >> On Sun, Oct 6, 2013 at 8:16 AM, Paul E. Jones wrote: >> >>> Yes, any URI can be used to identify a property. However, there has to >>> be some agreed scheme and structure for things defined in the IETF. The >>> point of the suggestion was to specify that. >>> >>> We could use HTTP, but I've never seen that scheme used in IETF >>> documents for this type of thing. I've seen URNs, though. >>> >>> Paul >>> >>> >>> ------------------------------ >>> *From:* Melvin Carvalho >>> *Sent:* Sun Oct 06 09:19:42 EDT 2013 >>> *To:* "Paul E. Jones" >>> *Cc:* webfinger >>> *Subject:* Re: [webfinger] Registration of a URN for WebFinger >>> Properties >>> >>> >>> >>> >>> On 5 October 2013 03:22, Paul E. Jones wrote: >>> >>>> Folks, >>>> >>>> As you know, properties (both link and subject-specific properties) are >>>> identified via a URI. For applications that are defined outside the IETF, >>>> those organizations are able to define any URI they wish to use. For any >>>> we might define within the IETF, however, we need something. >>>> >>>> In anticipation of having such a need, I think we should create a >>>> document along the lines of RFC 6755 for WebFinger. Specifically, we would >>>> define a URN sub-namespace as: >>>> >>>> urn:ietf:params:webfinger >>>> >>>> One such potentially-useful subject-specific properties are "name", >>>> which would be the the subject's name intended for human consumption. If >>>> you've queried my WebFinger server, you would know I currently advertise my >>>> name in English and Chinese. For the "default" name, the URN might be: >>>> >>>> urn:ietf:params:webfinger:name >>>> >>>> For language-specific variants, it might be: >>>> >>>> urn:ietf:params:webfinger:name:zh-CN >>>> >>>> Defining the various properties and their meaning is an exercise for >>>> another day, but I hope you see the value in defining the URN sub-namespace. >>>> >>> >>> Cant this be done using traditional HTTP keys. The advantage being that >>> they can be systematically dereferenced using http GET, rather than having >>> to look it up in a central registry in a non machine readable way. This is >>> what has been going on for 10+ years, with FOAF, schema.org, open graph >>> protocol and others. Have I missed something? >>> >>> >>>> >>>> Thoughts? >>>> >>>> Paul >>>> >>>> >>>> _______________________________________________ >>>> webfinger mailing list >>>> webfinger@ietf.org >>>> https://www.ietf.org/mailman/listinfo/webfinger >>>> >>>> >>> >>> _______________________________________________ >>> webfinger mailing list >>> webfinger@ietf.org >>> https://www.ietf.org/mailman/listinfo/webfinger >>> >>> >> > --001a11c38dfc58ca6e04e866d30b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 10, 2013 at 10:53 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:



On 10 October 2013 19:48, Will Norris &= lt;will@willnorris= .com> wrote:
There irony here is that WebFinger itself= was created to solve the problem of resolving an otherwise unresolvable UR= I (originally mailto and later acct URIs). =A0URNs have the same problem, a= nd since they have no well-defined host, you can't even use WebFinger t= o resolve them. =A0I know there have been some efforts to define URN resolu= tion (rfc2483 et al), but as far as I know none are very well adopted. =A0U= sing HTTP URIs makes the most sense to me.

But do we really need yet another registry of properties, th= e vast majority of which I'm sure have been defined in a dozen other pl= aces? =A0Is there a reason why reusing one of these existing namespaces wou= ld not work? =A0(and if something WebFinger specific really is desirable, t= hen we can continue using webfinger.net, which has already been used for=A0http://webfinger.net/rel/avatar/= and=A0http://webfinger.net/rel/profile-page/. =A0That was kind of the id= ea of running it as a static site out of the GitHub "webfinger" o= rg; it's very easy to give others access to everything. =A0That's w= hat we've done with activitystrea.ms for several years now)

+1

Yes, that's nice= but Id suggest it's better to put all the terms in one single file to = reduce multiple HTTP GETs and maintenance.

multiple GETs by whom? =A0I suspect that t= hese will typically resolve to human readable descriptions of the propertie= s... I don't imagine they'd be automatically fetched by anything/an= yone. =A0We could of course embed some machine readable version of the prop= erty in the pages, but even then I'm not exactly sure what the use-case= would be. =A0That said, I don't actually have strong feelings on this.=
=A0
=

Also I forgot to mention VCard which also covers a lot = of terms needed.

yep, though I'm not sure if they have URI equivalents for property na= mes. =A0There is a URN for the XML namespace (urn:ietf:params:xml:ns:vcard-4.0), but that's gets us= back to where we started.
=A0
=
=A0


On Sun, Oct 6, 2013 at 8:16 AM, Paul E. Jones <paulej@packetizer.co= m> wrote:

Yes, any URI can be used to identify a= property. However, there has to be some agreed scheme and structure for th= ings defined in the IETF. The point of the suggestion was to specify that.<= /p>

We could use HTTP, but I've never seen that scheme used = in IETF documents for this type of thing. I've seen URNs, though.

Paul



From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sun Oct 06 09:19:42 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] Registration of a URN for WebFinger Propert= ies




On 5 October 2013 03:22, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:
Folks,
=A0
As you know, properties (both link and subject-specific properties) ar= e identified via a URI.=A0 For applications that are defined outside the IE= TF, those organizations are able to define any URI they wish to use.=A0 For= any we might define within the IETF, however, we need something.
=A0
In anticipation of having such a need, I think we should create a docu= ment along the lines of RFC 6755 for WebFinger.=A0 Specifically, we would d= efine a URN sub-namespace as:
=A0
=A0=A0 urn:ietf:params:webfinger
=A0
One such potentially-useful subject-specific properties are "name= ", which would be the the subject's name intended for human consum= ption.=A0 If you've queried my WebFinger server, you would know I curre= ntly advertise my name in English and Chinese.=A0 For the "default&quo= t; name, the URN might be:
=A0
=A0=A0 urn:ietf:params:webfinger:name
=A0
For language-specific variants, it might be:
=A0
=A0=A0 urn:ietf:params:webfinger:name:zh-CN
=A0
Defining the various properties and their meaning is an exercise for a= nother day, but I hope you see the value in defining the URN sub-namespace.=

=A0
=A0
Thoughts?
=A0
Paul
=A0

__________________= _____________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger



_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger




--001a11c38dfc58ca6e04e866d30b-- From melvincarvalho@gmail.com Thu Oct 10 11:16:08 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4144021F99F7 for ; Thu, 10 Oct 2013 11:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXgDGgLwFrks for ; Thu, 10 Oct 2013 11:16:05 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3F79E21F999C for ; Thu, 10 Oct 2013 11:13:57 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id q8so2433942lbi.39 for ; Thu, 10 Oct 2013 11:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/pZXwBIiM3GsaEk0PU6/Wrevw3cvnpO3mf6TYYXm35w=; b=Kle5pDpk82FAjeFf+WNj4+JKbLpvCEUUrdoIWr/cdOh0h2qIrISWPfcnMxJWZTChBz i1pO/L2+QAz863m2xvHPTEWS8usf/MuQshSADi76vWUXUzmCnWev+OBiPMCI7GhFR1GY c8ltjD6uXxZ3ZJMC1cIZkYwsRget11E0Ozpqfa2i6jkLHbBz5SoQYUG3w9Tu29+za+eP u/eyPAiWqMAk+IA0xybZsj3zxAJ7XxBfh0Vs4UvM7bh3/8XdxojD54i0s5Cnjb7AXD6G R5C6x/nRTK8qumCOrOZoYMIwEv+4HRaC/NeYq8tsBSqHthLCKf9lPyQ/K3OvK4NCt85u ZfpA== MIME-Version: 1.0 X-Received: by 10.112.158.225 with SMTP id wx1mr2814045lbb.37.1381428833127; Thu, 10 Oct 2013 11:13:53 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Thu, 10 Oct 2013 11:13:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Oct 2013 20:13:53 +0200 Message-ID: From: Melvin Carvalho To: Will Norris Content-Type: multipart/alternative; boundary=001a11c34932e1904504e866f6d5 Cc: "Paul E. Jones" , webfinger Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 18:16:08 -0000 --001a11c34932e1904504e866f6d5 Content-Type: text/plain; charset=ISO-8859-1 On 10 October 2013 20:03, Will Norris wrote: > On Thu, Oct 10, 2013 at 10:53 AM, Melvin Carvalho < > melvincarvalho@gmail.com> wrote: > >> >> >> >> On 10 October 2013 19:48, Will Norris wrote: >> >>> There irony here is that WebFinger itself was created to solve the >>> problem of resolving an otherwise unresolvable URI (originally mailto and >>> later acct URIs). URNs have the same problem, and since they have no >>> well-defined host, you can't even use WebFinger to resolve them. I know >>> there have been some efforts to define URN resolution (rfc2483 et al), but >>> as far as I know none are very well adopted. Using HTTP URIs makes the >>> most sense to me. >>> >>> But do we really need yet another registry of properties, the vast >>> majority of which I'm sure have been defined in a dozen other places? Is >>> there a reason why reusing one of these existing namespaces would not work? >>> (and if something WebFinger specific really is desirable, then we can >>> continue using webfinger.net, which has already been used for >>> http://webfinger.net/rel/avatar/ and >>> http://webfinger.net/rel/profile-page/. That was kind of the idea of >>> running it as a static site out of the GitHub "webfinger" org; it's very >>> easy to give others access to everything. That's what we've done with >>> activitystrea.ms for several years now) >>> >> >> +1 >> >> Yes, that's nice but Id suggest it's better to put all the terms in one >> single file to reduce multiple HTTP GETs and maintenance. >> > > multiple GETs by whom? I suspect that these will typically resolve to > human readable descriptions of the properties... I don't imagine they'd be > automatically fetched by anything/anyone. We could of course embed some > machine readable version of the property in the pages, but even then I'm > not exactly sure what the use-case would be. That said, I don't actually > have strong feelings on this. > > >> >> Also I forgot to mention VCard which also covers a lot of terms needed. >> > > yep, though I'm not sure if they have URI equivalents for property names. > There is a URN for the XML namespace (urn:ietf:params:xml:ns:vcard-4.0), > but that's gets us back to where we started. > http://www.w3.org/TR/2013/WD-vcard-rdf-20130924/ > > >> >> >>> >>> >>> On Sun, Oct 6, 2013 at 8:16 AM, Paul E. Jones wrote: >>> >>>> Yes, any URI can be used to identify a property. However, there has to >>>> be some agreed scheme and structure for things defined in the IETF. The >>>> point of the suggestion was to specify that. >>>> >>>> We could use HTTP, but I've never seen that scheme used in IETF >>>> documents for this type of thing. I've seen URNs, though. >>>> >>>> Paul >>>> >>>> >>>> ------------------------------ >>>> *From:* Melvin Carvalho >>>> *Sent:* Sun Oct 06 09:19:42 EDT 2013 >>>> *To:* "Paul E. Jones" >>>> *Cc:* webfinger >>>> *Subject:* Re: [webfinger] Registration of a URN for WebFinger >>>> Properties >>>> >>>> >>>> >>>> >>>> On 5 October 2013 03:22, Paul E. Jones wrote: >>>> >>>>> Folks, >>>>> >>>>> As you know, properties (both link and subject-specific properties) >>>>> are identified via a URI. For applications that are defined outside the >>>>> IETF, those organizations are able to define any URI they wish to use. For >>>>> any we might define within the IETF, however, we need something. >>>>> >>>>> In anticipation of having such a need, I think we should create a >>>>> document along the lines of RFC 6755 for WebFinger. Specifically, we would >>>>> define a URN sub-namespace as: >>>>> >>>>> urn:ietf:params:webfinger >>>>> >>>>> One such potentially-useful subject-specific properties are "name", >>>>> which would be the the subject's name intended for human consumption. If >>>>> you've queried my WebFinger server, you would know I currently advertise my >>>>> name in English and Chinese. For the "default" name, the URN might be: >>>>> >>>>> urn:ietf:params:webfinger:name >>>>> >>>>> For language-specific variants, it might be: >>>>> >>>>> urn:ietf:params:webfinger:name:zh-CN >>>>> >>>>> Defining the various properties and their meaning is an exercise for >>>>> another day, but I hope you see the value in defining the URN sub-namespace. >>>>> >>>> >>>> Cant this be done using traditional HTTP keys. The advantage being >>>> that they can be systematically dereferenced using http GET, rather than >>>> having to look it up in a central registry in a non machine readable way. >>>> This is what has been going on for 10+ years, with FOAF, schema.org, >>>> open graph protocol and others. Have I missed something? >>>> >>>> >>>>> >>>>> Thoughts? >>>>> >>>>> Paul >>>>> >>>>> >>>>> _______________________________________________ >>>>> webfinger mailing list >>>>> webfinger@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/webfinger >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> webfinger mailing list >>>> webfinger@ietf.org >>>> https://www.ietf.org/mailman/listinfo/webfinger >>>> >>>> >>> >> > --001a11c34932e1904504e866f6d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 10 October 2013 20:03, Will Norris <will@willnorris.com&g= t; wrote:
On Thu, Oct 10, 2013 at 10:53 AM, Melvin Carvalho <melvin= carvalho@gmail.com> wrote:



On 10 October 2013 19:48, Will Norris <will@willnorris.com><= /span> wrote:
There ir= ony here is that WebFinger itself was created to solve the problem of resol= ving an otherwise unresolvable URI (originally mailto and later acct URIs).= =A0URNs have the same problem, and since they have no well-defined host, y= ou can't even use WebFinger to resolve them. =A0I know there have been = some efforts to define URN resolution (rfc2483 et al), but as far as I know= none are very well adopted. =A0Using HTTP URIs makes the most sense to me.=

But do we really need yet another registry of properties, th= e vast majority of which I'm sure have been defined in a dozen other pl= aces? =A0Is there a reason why reusing one of these existing namespaces wou= ld not work? =A0(and if something WebFinger specific really is desirable, t= hen we can continue using webfinger.net, which has already been used for=A0http://webfinger.net/rel/avatar/= and=A0http://webfinger.net/rel/profile-page/. =A0That was kind of the id= ea of running it as a static site out of the GitHub "webfinger" o= rg; it's very easy to give others access to everything. =A0That's w= hat we've done with activitystrea.ms for several years now)

+1

Yes, that's nice= but Id suggest it's better to put all the terms in one single file to = reduce multiple HTTP GETs and maintenance.

multiple GETs by whom? =A0I suspect = that these will typically resolve to human readable descriptions of the pro= perties... I don't imagine they'd be automatically fetched by anyth= ing/anyone. =A0We could of course embed some machine readable version of th= e property in the pages, but even then I'm not exactly sure what the us= e-case would be. =A0That said, I don't actually have strong feelings on= this.
=A0

Also I forgot to mention VCard which also covers a lot = of terms needed.

yep, though I'm not sure if they have URI equivalents for prope= rty names. =A0There is a URN for the XML namespace (urn:ietf:params:xml:ns:vcard-4.0), but that's gets us back to wh= ere we started.
=A0
=A0


On Sun, Oct 6, 2013 at 8:16 AM, Paul E. Jones <paulej@packetizer.co= m> wrote:

Yes, = any URI can be used to identify a property. However, there has to be some a= greed scheme and structure for things defined in the IETF. The point of the= suggestion was to specify that.

We could use HTTP, but I've never seen that scheme used = in IETF documents for this type of thing. I've seen URNs, though.

Paul







On 5 October 2013 03:22, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:
Folks,
=A0
As you know, properties (both link and subject-specific properties) ar= e identified via a URI.=A0 For applications that are defined outside the IE= TF, those organizations are able to define any URI they wish to use.=A0 For= any we might define within the IETF, however, we need something.
=A0
In anticipation of having such a need, I think we should create a docu= ment along the lines of RFC 6755 for WebFinger.=A0 Specifically, we would d= efine a URN sub-namespace as:
=A0
=A0=A0 urn:ietf:params:webfinger
=A0
One such potentially-useful subject-specific properties are "name= ", which would be the the subject's name intended for human consum= ption.=A0 If you've queried my WebFinger server, you would know I curre= ntly advertise my name in English and Chinese.=A0 For the "default&quo= t; name, the URN might be:
=A0
=A0=A0 urn:ietf:params:webfinger:name
=A0
For language-specific variants, it might be:
=A0
=A0=A0 urn:ietf:params:webfinger:name:zh-CN
=A0
Defining the various properties and their meaning is an exercise for a= nother day, but I hope you see the value in defining the URN sub-namespace.=

=A0
=
=A0
Thoughts?
=A0
Paul
=A0

__________________= _____________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger



_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger





--001a11c34932e1904504e866f6d5-- From paulej@packetizer.com Thu Oct 10 15:34:14 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38DA21E8084 for ; Thu, 10 Oct 2013 15:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDgvuq4IPWif for ; Thu, 10 Oct 2013 15:34:10 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2E41621E8132 for ; Thu, 10 Oct 2013 15:34:07 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r9AMY4jV007235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Oct 2013 18:34:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1381444445; bh=j9trCzF0f1zynafJBAZn1zd/JtEuzP5hbWHGcSmJh9Q=; h=From:To:Subject:Cc:Date:Content-Type:In-Reply-To:Message-Id: Mime-Version:Reply-To; b=rdSppE3ym71KWrFCQVIAMicMohbmtvuz0pV3v9Y3yKeuDJ8/NYgH1ILNja8IRiwIO r1EsQXBcRsZITTWHldv523TBo1ose3IK5S4+GrSCXQYShKTADr4DCMn81uMuwzgf8N I8aS/Zov4QzRYYY8JdAjaUf4dZJNdhP9MNDAGsz8= From: "Paul E. Jones" To: "Will Norris" Date: Thu, 10 Oct 2013 22:34:17 +0000 Content-Type: multipart/alternative; boundary="------=_MB78F8CBF5-659F-47B9-B8B6-6C625B1048EC" In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.18661.0 Cc: webfinger , Melvin Carvalho Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Paul E. Jones" List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 22:34:14 -0000 --------=_MB78F8CBF5-659F-47B9-B8B6-6C625B1048EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Will, The reason is to have one set of identifiers that people can agree to=20 use. There are two types of identifiers, too: * Link relations types * Properties As you point out, there are several link relations already defined. =20 I've cataloged some of them: http://www.packetizer.com/webfinger/link_relations.html Some that are interesting to me did not exist, so I made up values. There are also properties, and I've not seen any described formally=20 anywhere. I've defined a ones I find useful: http://www.packetizer.com/webfinger/properties.html There are more defined out there, I'm sure. And it's perfectly OK for=20 applications to define whatever they want. However, there are a few that I think really should be defined by the=20 IETF. If we don't do that, then we at least need to have an informal=20 agreement on, for example, how to get a person's name. Otherwise, some=20 link relation types or property identifiers are likely to get defined=20 with 10 different identifiers, yet carry the same semantics. Paul ------ Original Message ------ From: "Will Norris" To: "Paul E. Jones" Cc: "Melvin Carvalho" ; "webfinger"=20 Sent: 10/10/2013 1:48:59 PM Subject: Re: [webfinger] Registration of a URN for WebFinger Properties >There irony here is that WebFinger itself was created to solve the=20 >problem of resolving an otherwise unresolvable URI (originally mailto=20 >and later acct URIs). URNs have the same problem, and since they have=20 >no well-defined host, you can't even use WebFinger to resolve them. I=20 >know there have been some efforts to define URN resolution (rfc2483 et=20 >al), but as far as I know none are very well adopted. Using HTTP URIs=20 >makes the most sense to me. > >But do we really need yet another registry of properties, the vast=20 >majority of which I'm sure have been defined in a dozen other places? =20 >Is there a reason why reusing one of these existing namespaces would=20 >not work? (and if something WebFinger specific really is desirable,=20 >then we can continue using webfinger.net, which has already been used=20 >for http://webfinger.net/rel/avatar/ and=20 >http://webfinger.net/rel/profile-page/. That was kind of the idea of=20 >running it as a static site out of the GitHub "webfinger" org; it's=20 >very easy to give others access to everything. That's what we've done=20 >with activitystrea.ms for several years now) > > >On Sun, Oct 6, 2013 at 8:16 AM, Paul E. Jones =20 >wrote: >>Yes, any URI can be used to identify a property. However, there has to= =20 >>be some agreed scheme and structure for things defined in the IETF.=20 >>The point of the suggestion was to specify that. >> >>We could use HTTP, but I've never seen that scheme used in IETF=20 >>documents for this type of thing. I've seen URNs, though. >> >>Paul >> >> >> >>-------------------------------------------------------------------------= ------- >>From: Melvin Carvalho >>Sent: Sun Oct 06 09:19:42 EDT 2013 >>To: "Paul E. Jones" >>Cc: webfinger >>Subject: Re: [webfinger] Registration of a URN for WebFinger=20 >>Properties >> >> >> >> >>On 5 October 2013 03:22, Paul E. Jones wrote: >>>Folks, >>> >>>As you know, properties (both link and subject-specific properties)=20 >>>are identified via a URI. For applications that are defined outside=20 >>>the IETF, those organizations are able to define any URI they wish to= =20 >>>use. For any we might define within the IETF, however, we need=20 >>>something. >>> >>>In anticipation of having such a need, I think we should create a=20 >>>document along the lines of RFC 6755 for WebFinger. Specifically, we= =20 >>>would define a URN sub-namespace as: >>> >>> urn:ietf:params:webfinger >>> >>>One such potentially-useful subject-specific properties are "name",=20 >>>which would be the the subject's name intended for human consumption.= =20 >>> If you've queried my WebFinger server, you would know I currently=20 >>>advertise my name in English and Chinese. For the "default" name,=20 >>>the URN might be: >>> >>> urn:ietf:params:webfinger:name >>> >>>For language-specific variants, it might be: >>> >>> urn:ietf:params:webfinger:name:zh-CN >>> >>>Defining the various properties and their meaning is an exercise for=20 >>>another day, but I hope you see the value in defining the URN=20 >>>sub-namespace. >> >>Cant this be done using traditional HTTP keys. The advantage being=20 >>that they can be systematically dereferenced using http GET, rather=20 >>than having to look it up in a central registry in a non machine=20 >>readable way. This is what has been going on for 10+ years, with=20 >>FOAF, schema.org, open graph protocol and others. Have I missed=20 >>something? >> >>> >>>Thoughts? >>> >>>Paul >>> >>> >>>_______________________________________________ >>>webfinger mailing list >>>webfinger@ietf.org >>>https://www.ietf.org/mailman/listinfo/webfinger >>> >> >> >>_______________________________________________ >>webfinger mailing list >>webfinger@ietf.org >>https://www.ietf.org/mailman/listinfo/webfinger >> > --------=_MB78F8CBF5-659F-47B9-B8B6-6C625B1048EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Will,
 
The reason is to have one set of identifiers that people can agree = to use.  There are two types of identifiers, too:
    * Link relations types
    * Properties
 
As you point out, there are several link relations already defined.&nb= sp; I've cataloged some of them:
 
Some that are interesting to me did not exist,  so I made up valu= es.
 
There are also properties, and I've not seen any described formally= anywhere.  I've defined a ones I find useful:
 
There are more defined out there, I'm sure.  And it's perfectly= OK for applications to define whatever they want.
 
However, there are a few that I think really should be defined by the= IETF.  If we don't do that, then we at least need to have an informal= agreement on, for example, how to get a person's name.  Otherwise,= some link relation types or property identifiers are likely to get defined= with 10 different identifiers, yet carry the same semantics.
 
Paul
 
------ Original Message ------
From: "Will Norris" <will@wi= llnorris.com>
To: "Paul E. Jones" <paule= j@packetizer.com>
Cc: "Melvin Carvalho" <= melvincarvalho@gmail.com>; "webfinger" <webfinger@ietf.org>
Sent: 10/10/2013 1:48:59 PM
Subject: Re: [webfinger] Registration of a URN for WebFinger Propertie= s
There irony here is that WebFinger itself was created to = solve the problem of resolving an otherwise unresolvable URI (originally= mailto and later acct URIs).  URNs have the same problem, and since= they have no well-defined host, you can't even use WebFinger to resolve= them.  I know there have been some efforts to define URN resolution= (rfc2483 et al), but as far as I know none are very well adopted.  Us= ing HTTP URIs makes the most sense to me.=20

But do we really need yet another registry of properties, the vast = majority of which I'm sure have been defined in a dozen other places?  = ;Is there a reason why reusing one of these existing namespaces would not= work?  (and if something WebFinger specific really is desirable, then= we can continue using webfinger.net,= which has already been used for http://webfinger.net/rel/avatar/ and http://webfinger.net/rel/profile-page/.=  That was kind of the idea of running it as a static site out of the= GitHub "webfinger" org; it's very easy to give others access to everything= .  That's what we've done with act= ivitystrea.ms for several years now)


On Sun, Oct 6, 2013 at 8:16 AM, Paul E. Jones <paulej@packetizer.= com> wrote:

Yes, any URI can be used to identify a property. However, ther= e has to be some agreed scheme and structure for things defined in the IETF= . The point of the suggestion was to specify that.

We could use HTTP, but I've never seen that scheme used in = IETF documents for this type of thing. I've seen URNs, though.

Paul



From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sun Oct 06 09:19:4= 2 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject= : Re: [webfinger] Registration of a URN for WebFinger Properties




On 5 October 2013 03:22, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,
 
As you know, properties (both link and subject-specific properties)= are identified via a URI.  For applications that are defined outside= the IETF, those organizations are able to define any URI they wish to use.=   For any we might define within the IETF, however, we need something.=
 
In anticipation of having such a need, I think we should create a docu= ment along the lines of RFC 6755 for WebFinger.  Specifically, we woul= d define a URN sub-namespace as:
 
   urn:ietf:params:webfinger
 
One such potentially-useful subject-specific properties are "name",= which would be the the subject's name intended for human consumption. = ; If you've queried my WebFinger server, you would know I currently adverti= se my name in English and Chinese.  For the "default" name, the URN= might be:
 
   urn:ietf:params:webfinger:name
 
For language-specific variants, it might be:
 
   urn:ietf:params:webfinger:name:zh-CN
 
Defining the various properties and their meaning is an exercise for= another day, but I hope you see the value in defining the URN sub-namespac= e.
 
 
Thoughts?
 
Paul
 

_______________= ________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinf= o/webfinger



_______________________________________________
webfinger mailing= list
webfinger@ietf.org
https://www.ietf.= org/mailman/listinfo/webfinger


--------=_MB78F8CBF5-659F-47B9-B8B6-6C625B1048EC-- From melvincarvalho@gmail.com Thu Oct 10 15:56:58 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5F921E8167 for ; Thu, 10 Oct 2013 15:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyH3PfX5y7gD for ; Thu, 10 Oct 2013 15:56:57 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id BA2DE21F8F2A for ; Thu, 10 Oct 2013 15:56:56 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id gx14so2713760lab.37 for ; Thu, 10 Oct 2013 15:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eAVCWJSaWujWQhqC1+SqMU91fTsBipZc51UF9VIqzaY=; b=BXvwtjOAV7w1ys2mKyeILDnfhC58NRKjR8hLpumPlpc0cRawABj3mqyBhrxoVwxDy7 D+XoO6m/QojKtsyrA0r+FJPcl84OSq0uHTWhAFeiThuqCMnEaQyHjy2qsSkNr+nGJ7Gl oq/yn30elaP1ILiiDtbJ8ciBP+z3lBhtNQOqSV1i5E2rLfv88/QsC3YejvOw46hrHyWa 7m8FtiV3ty7aOMQdEYgFxE0lQgCDTWAFdo6mOn70E+Nk0lo+/QuSz0Eo1cO/gdNBoLAt g37BQ+R2eVcl/v+I9DYAN5BGRfDaZa55jzjp+A8n335yBLY8OYaRYk6a4wJu/rOKsQGd lMFg== MIME-Version: 1.0 X-Received: by 10.152.3.42 with SMTP id 10mr13608424laz.22.1381445815287; Thu, 10 Oct 2013 15:56:55 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Thu, 10 Oct 2013 15:56:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Oct 2013 00:56:55 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e013d14b218c66404e86aebd9 Cc: webfinger , Will Norris Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 22:56:58 -0000 --089e013d14b218c66404e86aebd9 Content-Type: text/plain; charset=ISO-8859-1 On 11 October 2013 00:34, Paul E. Jones wrote: > Will, > > The reason is to have one set of identifiers that people can agree to > use. There are two types of identifiers, too: > * Link relations types > * Properties > > As you point out, there are several link relations already defined. I've > cataloged some of them: > http://www.packetizer.com/webfinger/link_relations.html > > Some that are interesting to me did not exist, so I made up values. > > There are also properties, and I've not seen any described formally > anywhere. I've defined a ones I find useful: > http://www.packetizer.com/webfinger/properties.html > Regarding name, just from the top of my head (I didnt include PoCo, OpenSocial, PIM, DOAP, but you could search for them) http://xmlns.com/foaf/spec/#term_name https://schema.org/name http://graph.facebook.com/schema/user#name http://www.w3.org/TR/vcard-rdf/#d4e1731 Remember that link relations predate webfinger by over 5 years. It's often better to reuse than to reinvent. > > There are more defined out there, I'm sure. And it's perfectly OK for > applications to define whatever they want. > > However, there are a few that I think really should be defined by the > IETF. If we don't do that, then we at least need to have an informal > agreement on, for example, how to get a person's name. Otherwise, some > link relation types or property identifiers are likely to get defined with > 10 different identifiers, yet carry the same semantics. > > Paul > > ------ Original Message ------ > From: "Will Norris" > To: "Paul E. Jones" > Cc: "Melvin Carvalho" ; "webfinger" < > webfinger@ietf.org> > Sent: 10/10/2013 1:48:59 PM > Subject: Re: [webfinger] Registration of a URN for WebFinger Properties > > There irony here is that WebFinger itself was created to solve the > problem of resolving an otherwise unresolvable URI (originally mailto and > later acct URIs). URNs have the same problem, and since they have no > well-defined host, you can't even use WebFinger to resolve them. I know > there have been some efforts to define URN resolution (rfc2483 et al), but > as far as I know none are very well adopted. Using HTTP URIs makes the > most sense to me. > > But do we really need yet another registry of properties, the vast > majority of which I'm sure have been defined in a dozen other places? Is > there a reason why reusing one of these existing namespaces would not work? > (and if something WebFinger specific really is desirable, then we can > continue using webfinger.net, which has already been used for > http://webfinger.net/rel/avatar/ and > http://webfinger.net/rel/profile-page/. That was kind of the idea of > running it as a static site out of the GitHub "webfinger" org; it's very > easy to give others access to everything. That's what we've done with > activitystrea.ms for several years now) > > > On Sun, Oct 6, 2013 at 8:16 AM, Paul E. Jones wrote: > >> Yes, any URI can be used to identify a property. However, there has to >> be some agreed scheme and structure for things defined in the IETF. The >> point of the suggestion was to specify that. >> >> We could use HTTP, but I've never seen that scheme used in IETF documents >> for this type of thing. I've seen URNs, though. >> >> Paul >> >> >> ------------------------------ >> *From:* Melvin Carvalho >> *Sent:* Sun Oct 06 09:19:42 EDT 2013 >> *To:* "Paul E. Jones" >> *Cc:* webfinger >> *Subject:* Re: [webfinger] Registration of a URN for WebFinger Properties >> >> >> >> >> On 5 October 2013 03:22, Paul E. Jones wrote: >> >>> Folks, >>> >>> As you know, properties (both link and subject-specific properties) are >>> identified via a URI. For applications that are defined outside the IETF, >>> those organizations are able to define any URI they wish to use. For any >>> we might define within the IETF, however, we need something. >>> >>> In anticipation of having such a need, I think we should create a >>> document along the lines of RFC 6755 for WebFinger. Specifically, we would >>> define a URN sub-namespace as: >>> >>> urn:ietf:params:webfinger >>> >>> One such potentially-useful subject-specific properties are "name", >>> which would be the the subject's name intended for human consumption. If >>> you've queried my WebFinger server, you would know I currently advertise my >>> name in English and Chinese. For the "default" name, the URN might be: >>> >>> urn:ietf:params:webfinger:name >>> >>> For language-specific variants, it might be: >>> >>> urn:ietf:params:webfinger:name:zh-CN >>> >>> Defining the various properties and their meaning is an exercise for >>> another day, but I hope you see the value in defining the URN sub-namespace. >>> >> >> Cant this be done using traditional HTTP keys. The advantage being that >> they can be systematically dereferenced using http GET, rather than having >> to look it up in a central registry in a non machine readable way. This is >> what has been going on for 10+ years, with FOAF, schema.org, open graph >> protocol and others. Have I missed something? >> >> >>> >>> Thoughts? >>> >>> Paul >>> >>> >>> _______________________________________________ >>> webfinger mailing list >>> webfinger@ietf.org >>> https://www.ietf.org/mailman/listinfo/webfinger >>> >>> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> > --089e013d14b218c66404e86aebd9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 11 October 2013 00:34, Paul E. Jones <paulej@packetizer.com= > wrote:
Will,
=A0
The reason is to have one set of identifiers that people can agree to = use.=A0 There are two types of identifiers, too:
=A0=A0=A0 * Link relations types
=A0=A0=A0 * Properties
=A0
As you point out, there are several link relations already defined.=A0= I've cataloged some of them:
=A0
Some that are interesting to me did not exist,=A0 so I made up values.=
=A0
There are also properties, and I've not seen any described formall= y anywhere.=A0 I've defined a ones I find useful:

Regarding name, just from the top of m= y head (I didnt include PoCo, OpenSocial, PIM, DOAP, but you could search f= or them)
Remember that link relations predate= webfinger by over 5 years.=A0 It's often better to reuse than to reinv= ent.
=A0
=A0
There are more defined out there, I'm sure.=A0 And it's perfec= tly OK for applications to define whatever they want.
=A0
However, there are a few that I think really should be defined by the = IETF.=A0 If we don't do that, then we at least need to have an informal= agreement on, for example, how to get a person's name.=A0 Otherwise, s= ome link relation types or property identifiers are likely to get defined w= ith 10=A0different identifiers, yet carry the same semantics.
=A0
Paul
=A0
------ Original Message ------
From: "Will Norris" <will@willnorris.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: "Melvin Carvalho" <melvincarvalho@gma= il.com>; "webfinger" <webfinger@ietf.org>
Sent: 10/10/2013 1:48:59 PM
Subject: Re: [webfinger] Registration of a URN for WebFinger Propertie= s
There irony here is that WebFinger itself was created to s= olve the problem of resolving an otherwise unresolvable URI (originally mai= lto and later acct URIs). =A0URNs have the same problem, and since they hav= e no well-defined host, you can't even use WebFinger to resolve them. = =A0I know there have been some efforts to define URN resolution (rfc2483 et= al), but as far as I know none are very well adopted. =A0Using HTTP URIs m= akes the most sense to me.=20

But do we really need yet another registry of properties, the vast maj= ority of which I'm sure have been defined in a dozen other places? =A0I= s there a reason why reusing one of these existing namespaces would not wor= k? =A0(and if something WebFinger specific really is desirable, then we can= continue using webfinge= r.net, which has already been used for=A0http://webfinger.net/rel/avatar/ and= =A0htt= p://webfinger.net/rel/profile-page/. =A0That was kind of the idea of ru= nning it as a static site out of the GitHub "webfinger" org; it&#= 39;s very easy to give others access to everything. =A0That's what we&#= 39;ve done with activ= itystrea.ms for several years now)


On Sun, Oct 6, 2013 at 8:16 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Yes, any URI can be used to identify a property. However, th= ere has to be some agreed scheme and structure for things defined in the IE= TF. The point of the suggestion was to specify that.

We could use HTTP, but I've never seen that scheme used = in IETF documents for this type of thing. I've seen URNs, though.

Paul



From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: = Sun Oct 06 09:19:42 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.= com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] Registr= ation of a URN for WebFinger Properties




On 5 October 2013 03:22, Paul E. Jones <pau= lej@packetizer.com> wrote:
Folks,
=A0
As you know, properties (both link and subject-specific properties) ar= e identified via a URI.=A0 For applications that are defined outside the IE= TF, those organizations are able to define any URI they wish to use.=A0 For= any we might define within the IETF, however, we need something.
=A0
In anticipation of having such a need, I think we should create a docu= ment along the lines of RFC 6755 for WebFinger.=A0 Specifically, we would d= efine a URN sub-namespace as:
=A0
=A0=A0 urn:ietf:params:webfinger
=A0
One such potentially-useful subject-specific properties are "name= ", which would be the the subject's name intended for human consum= ption.=A0 If you've queried my WebFinger server, you would know I curre= ntly advertise my name in English and Chinese.=A0 For the "default&quo= t; name, the URN might be:
=A0
=A0=A0 urn:ietf:params:webfinger:name
=A0
For language-specific variants, it might be:
=A0
=A0=A0 urn:ietf:params:webfinger:name:zh-CN
=A0
Defining the various properties and their meaning is an exercise for a= nother day, but I hope you see the value in defining the URN sub-namespace.=

Cant this be done using traditional HTTP keys.=A0 The advantage being = that they can be systematically dereferenced using http GET, rather than ha= ving to look it up in a central registry in a non machine readable way.=A0 = This is what has been going on for 10+ years, with FOAF, schema.org, open graph protocol and other= s.=A0 Have I missed something?
=A0
=A0
Thoughts?
=A0
Paul
=A0

__________________= _____________________________
webfinger mailing list
webfinger@ietf.org
http= s://www.ietf.org/mailman/listinfo/webfinger



______________= _________________________________
webfinger mailing list
webfinger@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/webfinger



--089e013d14b218c66404e86aebd9-- From paulej@packetizer.com Thu Oct 10 16:41:07 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9136F11E8193 for ; Thu, 10 Oct 2013 16:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0kMtVa1dDGX for ; Thu, 10 Oct 2013 16:41:03 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 45CB211E8162 for ; Thu, 10 Oct 2013 16:41:02 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r9ANf0hV011934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Oct 2013 19:41:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1381448461; bh=XEcSGIlcbXDTu6LGcBaPFExhxGTqW2mTybwNK2EO9qw=; h=From:To:Subject:Cc:Date:Content-Type:In-Reply-To:Message-Id: Mime-Version:Reply-To; b=Bwzr/+2TsFQOrPYzM6NW8tjZpp1fEZw5U2kH07SqQTa942St35uhXN9loPqKMegTl heqh7bX96vK+GExW8lqlkN/qAhKZMlGCH1x+qjX6sq3Qn0TCNJAw1DuM6zGHJ66ri8 gz4A9QrhkAHO2r5R2hUWF7HwHasTqG7XC/E2ilP8= From: "Paul E. Jones" To: "Melvin Carvalho" Date: Thu, 10 Oct 2013 23:41:13 +0000 Content-Type: multipart/alternative; boundary="------=_MB602F051C-ECA7-4A5D-955A-433ED7945EC7" In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.18661.0 Cc: webfinger , Will Norris Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Paul E. Jones" List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 23:41:07 -0000 --------=_MB602F051C-ECA7-4A5D-955A-433ED7945EC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Melvin, >>There are also properties, and I've not seen any described formally=20 >>anywhere. I've defined a ones I find useful: >>http://www.packetizer.com/webfinger/properties.html > >Regarding name, just from the top of my head (I didnt include PoCo,=20 >OpenSocial, PIM, DOAP, but you could search for them) > >http://xmlns.com/foaf/spec/#term_name >https://schema.org/name >http://graph.facebook.com/schema/user#name >http://www.w3.org/TR/vcard-rdf/#d4e1731 > >Remember that link relations predate webfinger by over 5 years. It's=20 >often better to reuse than to reinvent. I agree, though none of these are designed for use in WebFinger. So, I=20 created my own. You can't point to something 5 years old and declare=20 I'm reproducing it because there is some syntax scribbling that has the=20 word "name" associated with it. What I defined in the link above for "name", for example, is somewhere=20 between foaf:name and the one related to vcard. WebFinger has a=20 registry for identifiers now. It would be good to see that get=20 populated with useful items, though I would not recommend putting=20 everything one might possibly put into a vcard in there. If a vcard is=20 essential, the vcard link relation should be published in a WF JRD and a= =20 client query that. However, there are basic things like "name" that are= =20 very useful, such as when you log into a web site and that site would=20 like to display your avatar and name. The avatar already has a defined=20 LR value under webfinger.org. The person's name does not have a defined= =20 property identifier anywhere, except the one I specified under=20 packetizer.com. Paul --------=_MB602F051C-ECA7-4A5D-955A-433ED7945EC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Melvin,
There are also properties, and I've not seen any described formally= anywhere.  I've defined a ones I find useful:

Regarding name, just from the top of my head (I didnt include PoCo,= OpenSocial, PIM, DOAP, but you could search for them)
Remember that link relations predate webfinger by over 5 years. = It's often better to reuse than to reinvent.
=
I agree, though none of these are designed for use in WebFinger. = So, I created my own.  You can't point to something 5 years old= and declare I'm reproducing it because there is some syntax scribbling = that has the word "name" associated with it.
 
What I defined in the link above for "name", for example, is somewhere= between foaf:name and the one related to vcard.  WebFinger has a regi= stry for identifiers now.  It would be good to see that get populated= with useful items, though I would not recommend putting everything one = might possibly put into a vcard in there.  If a vcard is essential,= the vcard link relation should be published in a WF JRD and a client query= that.  However, there are basic things like "name" that are very usef= ul, such as when you log into a web site and that site would like to displa= y your avatar and name.  The avatar already has a defined LR valu= e under webfinger.org.  The person's name does not have a defined prop= erty identifier anywhere, except the one I specified under packetizer.com.<= /DIV>
 
Paul
 
--------=_MB602F051C-ECA7-4A5D-955A-433ED7945EC7-- From melvincarvalho@gmail.com Fri Oct 11 08:01:31 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1ED21F9808 for ; Fri, 11 Oct 2013 08:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2e0boaf07FK for ; Fri, 11 Oct 2013 08:01:28 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2250311E80E3 for ; Fri, 11 Oct 2013 08:01:27 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ev20so3520181lab.36 for ; Fri, 11 Oct 2013 08:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WkJHjxiwWNK7Uravcebvd8/cUel7nhbF+OD6QqaOgSs=; b=jaBpSOe9ksgcO2NCPtKIPAjUkV8HoQFy+GqRBE4lCM0JAMOlXETY+vRq/XN4KWP/1r YpEaWGjn3JaMUotcjxRLqGNke6V5VEnVkhi9uLiwZc3Tnj2Cuu4RlrRrhIMlXGwRDNxi ruwuEL+Sawtpk1ED7iNAgwBzOKXb4cgAmxWAGH4DYoEiGHBiIBPF3Bp0UKIP3UDTGyan TtxnldGnS3yDpvUtLjneZZtOeMvVrRU20sNLF48pyZlWSkLahc4riGoxEjfGyui3v4lK dyLuIpuOSYIiV6OKf7Ou4wNBKrLwdgJXCrXkc2jxFpbvWOIZyu28txoC84TnKrvqDAwn lJPg== MIME-Version: 1.0 X-Received: by 10.152.29.201 with SMTP id m9mr16793016lah.6.1381503686902; Fri, 11 Oct 2013 08:01:26 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Fri, 11 Oct 2013 08:01:26 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Oct 2013 17:01:26 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e0158cb9283899604e8786410 Cc: webfinger , Will Norris Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 15:01:31 -0000 --089e0158cb9283899604e8786410 Content-Type: text/plain; charset=ISO-8859-1 On 11 October 2013 01:41, Paul E. Jones wrote: > Melvin, > > There are also properties, and I've not seen any described formally >> anywhere. I've defined a ones I find useful: >> http://www.packetizer.com/webfinger/properties.html >> > > Regarding name, just from the top of my head (I didnt include PoCo, > OpenSocial, PIM, DOAP, but you could search for them) > > http://xmlns.com/foaf/spec/#term_name > https://schema.org/name > http://graph.facebook.com/schema/user#name > http://www.w3.org/TR/vcard-rdf/#d4e1731 > > Remember that link relations predate webfinger by over 5 years. It's > often better to reuse than to reinvent. > > I agree, though none of these are designed for use in WebFinger. So, I > created my own. You can't point to something 5 years old and declare I'm > reproducing it because there is some syntax scribbling that has the word > "name" associated with it. > > What I defined in the link above for "name", for example, is somewhere > between foaf:name and the one related to vcard. WebFinger has a registry > for identifiers now. It would be good to see that get populated with > useful items, though I would not recommend putting everything one might > possibly put into a vcard in there. If a vcard is essential, the vcard > link relation should be published in a WF JRD and a client query that. > However, there are basic things like "name" that are very useful, such as > when you log into a web site and that site would like to display > your avatar and name. The avatar already has a defined LR value under > webfinger.org. The person's name does not have a defined property > identifier anywhere, except the one I specified under packetizer.com. > Ah I see what you've done, you've added some internationalization, ie one URI for each language? Apart from that are there any differences to FOAF (by the way FOAF already has standards for internationalization) Wouldnt this lead to potentially dozens of new URIs, per term, for example, for a different one for every language supported? > > Paul > > --089e0158cb9283899604e8786410 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 11 October 2013 01:41, Paul E. Jones <paulej@packetizer.com= > wrote:
Melvin,
There are also properties, and I've not seen any described formall= y anywhere.=A0 I've defined a ones I find useful:

Regarding name, just from the top of my head (I didnt include PoCo, Op= enSocial, PIM, DOAP, but you could search for them)
Remember that link relations predate webfinger by over 5 years.=A0 It&= #39;s often better to reuse than to reinvent.
=
I agree, though none of these are designed for use in WebFinger.= =A0 So, I created my own.=A0 You can't point to something=A05 years old= and declare I'm reproducing it because there is some syntax scribbling= that has the word "name" associated with it.
=A0
What I defined in the link above for "name", for example, is= somewhere between foaf:name and the one related to vcard.=A0 WebFinger has= a registry for identifiers now.=A0 It would be good to see that get popula= ted with useful items, though I would not recommend putting everything one = might possibly put into a vcard in there.=A0 If a vcard is essential, the v= card link relation should be published in a WF JRD and a client query that.= =A0 However, there are basic things like "name" that are very use= ful, such as when you log into a web site and that site would like to displ= ay your=A0avatar and name.=A0 The avatar already has a defined LR value und= er webfinger.org.=A0= The person's name does not have a defined property identifier anywhere= , except the one I specified under packetizer.com.

Ah I see what you've done, you&#= 39;ve added some internationalization, ie one URI for each language?=A0 Apa= rt from that are there any differences to FOAF (by the way FOAF already has= standards for internationalization)

Wouldnt this lead to potentially dozens of new URIs, per ter= m, for example, for a different one for every language supported?
=
=A0
=A0
Paul
=A0

--089e0158cb9283899604e8786410-- From paulej@packetizer.com Fri Oct 11 10:07:10 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0984A21E81B9 for ; Fri, 11 Oct 2013 10:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puiks4C971n6 for ; Fri, 11 Oct 2013 10:07:05 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 97D9121E8137 for ; Fri, 11 Oct 2013 10:07:04 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r9BH6x9h021063 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 11 Oct 2013 13:06:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1381511220; bh=JXfYuLleGtSr8t7HVMWRDZBQbQUJcP6SfazmlLicZkg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=p+N7WQjl1oyhM0ZEG/lVDf1cTGsyiQmKIg2mfgiGDxgWRBYW6i3N3rFrlguxwjCBu QA9OubrAK73sOXCfpsP7+v9+2gXST8B1jVfHjxHMgPBB95//2yPepme2nQovfkZjXD o901jQOWHi1OOIpaACZcUSkPHF04UXf1A4RaIDmw= Message-ID: <52583040.1060405@packetizer.com> Date: Fri, 11 Oct 2013 13:07:12 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Melvin Carvalho References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050809040609080805030607" Cc: webfinger , Will Norris Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 17:07:10 -0000 This is a multi-part message in MIME format. --------------050809040609080805030607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Melvin, See comments below: On 10/11/2013 11:01 AM, Melvin Carvalho wrote: > > I agree, though none of these are designed for use in WebFinger. > So, I created my own. You can't point to something 5 years old > and declare I'm reproducing it because there is some syntax > scribbling that has the word "name" associated with it. > What I defined in the link above for "name", for example, is > somewhere between foaf:name and the one related to vcard. > WebFinger has a registry for identifiers now. It would be good to > see that get populated with useful items, though I would not > recommend putting everything one might possibly put into a vcard > in there. If a vcard is essential, the vcard link relation should > be published in a WF JRD and a client query that. However, there > are basic things like "name" that are very useful, such as when > you log into a web site and that site would like to display > your avatar and name. The avatar already has a defined LR value > under webfinger.org . The person's name does > not have a defined property identifier anywhere, except the one I > specified under packetizer.com . > > > Ah I see what you've done, you've added some internationalization, ie > one URI for each language? Apart from that are there any differences > to FOAF (by the way FOAF already has standards for internationalization) > > Wouldnt this lead to potentially dozens of new URIs, per term, for > example, for a different one for every language supported? FOAF does not define a set of URI. Rather, it's XML-based markup. WebFinger uses URIs as identifiers. I don't really care where those identifiers are defined, but at present there is no standard property identifer in URI form that means "name". Using the URI fragment to indicate the language does introduce a number of distinct URIs, but having the language tag would need to be /somewhere/ if we want to allow the language to be specified as part of the property. Unlike XML, we do not have additional attributes we can apply. Arguably, we do not need to specify the language and we allow a user to advertise just a single name. However, I've found it beneficial to allow people to advertise names in at least two different character sets. I can't read Chinese, Japanese, or Korean, for example, so allowing a western alphabet is helpful to be used in parallel with the native alphabet is nice. Paul --------------050809040609080805030607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Melvin,

See comments below:

On 10/11/2013 11:01 AM, Melvin Carvalho wrote:
I agree, though none of these are designed for use in WebFinger.  So, I created my own.  You can't point to something 5 years old and declare I'm reproducing it because there is some syntax scribbling that has the word "name" associated with it.
 
What I defined in the link above for "name", for example, is somewhere between foaf:name and the one related to vcard.  WebFinger has a registry for identifiers now.  It would be good to see that get populated with useful items, though I would not recommend putting everything one might possibly put into a vcard in there.  If a vcard is essential, the vcard link relation should be published in a WF JRD and a client query that.  However, there are basic things like "name" that are very useful, such as when you log into a web site and that site would like to display your avatar and name.  The avatar already has a defined LR value under webfinger.org.  The person's name does not have a defined property identifier anywhere, except the one I specified under packetizer.com.

Ah I see what you've done, you've added some internationalization, ie one URI for each language?  Apart from that are there any differences to FOAF (by the way FOAF already has standards for internationalization)

Wouldnt this lead to potentially dozens of new URIs, per term, for example, for a different one for every language supported?

FOAF does not define a set of URI.  Rather, it's XML-based markup.  WebFinger uses URIs as identifiers.  I don't really care where those identifiers are defined, but at present there is no standard property identifer in URI form that means "name".

Using the URI fragment to indicate the language does introduce a number of distinct URIs, but having the language tag would need to be somewhere if we want to allow the language to be specified as part of the property.  Unlike XML, we do not have additional attributes we can apply.  Arguably, we do not need to specify the language and we allow a user to advertise just a single name.  However, I've found it beneficial to allow people to advertise names in at least two different character sets.  I can't read Chinese, Japanese, or Korean, for example, so allowing a western alphabet is helpful to be used in parallel with the native alphabet is nice.

Paul 

--------------050809040609080805030607-- From wnorris@gmail.com Fri Oct 11 11:58:13 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39DA21F9DE1 for ; Fri, 11 Oct 2013 11:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jb0egbHkIoC for ; Fri, 11 Oct 2013 11:58:04 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 34FF311E819F for ; Fri, 11 Oct 2013 11:57:39 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id m15so4713215wgh.7 for ; Fri, 11 Oct 2013 11:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=P3pgsJA9XuGZe5TnIU9gSob7fl2agRgQU43Z1mfafqo=; b=PXcs3AfaKWHCN38hHhIMlRGgimUv7LYyh8JP45nidtdZ/OmQ89xxPOu9aE/PvPaz7Q b3cwrQPdFDDfQKn8+zdw/cLWMSumleF3KWP5JqshShZyUyJ0izpyZGfc5oONSUJBbGnp zr5maJ2uJuu0lqcwxh0Tm9UFX4D5Pply2AmqQ+rw6zIfnzpoDMEuESMdMXpbJEQRaH3Z RwFdQZFQv8x0Dz5jYJwWEr0AaADsVXLo6I9kPLvnQLw/NGjzSxplxEeGIuXgj4ZZuqjD 7uRbnpxK/aN+15V32VgSxVyDWld01HjIUFPUOdx5q7p5fVRE32mnHBR7akOSTIaxj0ik 5qBg== X-Received: by 10.180.208.2 with SMTP id ma2mr4428236wic.52.1381517859104; Fri, 11 Oct 2013 11:57:39 -0700 (PDT) MIME-Version: 1.0 Sender: wnorris@gmail.com Received: by 10.194.108.233 with HTTP; Fri, 11 Oct 2013 11:57:09 -0700 (PDT) In-Reply-To: <52583040.1060405@packetizer.com> References: <52583040.1060405@packetizer.com> From: Will Norris Date: Fri, 11 Oct 2013 11:57:09 -0700 X-Google-Sender-Auth: XTEFeqWdWGf0dWiGq39NxpqzDRQ Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a11c38dfc3e33e704e87bb1ea Cc: webfinger , Melvin Carvalho Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 18:58:13 -0000 --001a11c38dfc3e33e704e87bb1ea Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 11, 2013 at 10:07 AM, Paul E. Jones wrote: > Melvin, > > See comments below: > > > On 10/11/2013 11:01 AM, Melvin Carvalho wrote: > > I agree, though none of these are designed for use in WebFinger. So, I >> created my own. You can't point to something 5 years old and declare I'm >> reproducing it because there is some syntax scribbling that has the word >> "name" associated with it. >> >> What I defined in the link above for "name", for example, is somewhere >> between foaf:name and the one related to vcard. WebFinger has a registry >> for identifiers now. It would be good to see that get populated with >> useful items, though I would not recommend putting everything one might >> possibly put into a vcard in there. If a vcard is essential, the vcard >> link relation should be published in a WF JRD and a client query that. >> However, there are basic things like "name" that are very useful, such as >> when you log into a web site and that site would like to display >> your avatar and name. The avatar already has a defined LR value under >> webfinger.org. The person's name does not have a defined property >> identifier anywhere, except the one I specified under packetizer.com. >> > > Ah I see what you've done, you've added some internationalization, ie > one URI for each language? Apart from that are there any differences to > FOAF (by the way FOAF already has standards for internationalization) > > Wouldnt this lead to potentially dozens of new URIs, per term, for > example, for a different one for every language supported? > > > FOAF does not define a set of URI. Rather, it's XML-based markup. > WebFinger uses URIs as identifiers. I don't really care where those > identifiers are defined, but at present there is no standard property > identifer in URI form that means "name". > http://schema.org/name ? Of course that doesn't have the language fragment, though as you point out below, there's an argument it may not be needed anyway. /shrug > > Using the URI fragment to indicate the language does introduce a number of > distinct URIs, but having the language tag would need to be *somewhere*if we want to allow the language to be specified as part of the property. > Unlike XML, we do not have additional attributes we can apply. Arguably, > we do not need to specify the language and we allow a user to advertise > just a single name. However, I've found it beneficial to allow people to > advertise names in at least two different character sets. I can't read > Chinese, Japanese, or Korean, for example, so allowing a western alphabet > is helpful to be used in parallel with the native alphabet is nice. > > Paul > > --001a11c38dfc3e33e704e87bb1ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 11, 2013 at 10:07 AM, Paul E. Jones <pau= lej@packetizer.com> wrote:
=20 =20 =20
Melvin,

See comments below:


On 10/11/2013 11:01 AM, Melvin Carvalho wrote:
I agree, though none of these are designed for use in WebFinger.=A0 So, I created my own.=A0 You can't point to something=A05 years old and declare I'm reproducing it beca= use there is some syntax scribbling that has the word "name&qu= ot; associated with it.
=A0
What I defined in the link above for "name", for e= xample, is somewhere between foaf:name and the one related to vcard.=A0 WebFinger has a registry for identifiers now.=A0 It would be good to see that get populated with useful items, though I would not recommend putting everything one might possibly put into a vcard in there.=A0 If a vcard is essential, the vcard link relation should be published in a WF JRD and a client query that.=A0 However, there are basic things like "name" that are very useful, such as when= you log into a web site and that site would like to display your=A0avatar and name.=A0 The avatar already has a defined LR value under = webfinger.org.=A0 The person's name does not have a defined property identifier anywhere, except the one I specified under packetizer.com.

Ah I see what you've done, you've added some internationalization, ie one URI for each language?=A0 Apart from that are there any differences to FOAF (by the way FOAF already has standards for internationalization)

Wouldnt this lead to potentially dozens of new URIs, per term, for example, for a different one for every language supported?

FOAF does not define a set of URI.=A0 Rather, it's XML-based markup= .=A0 WebFinger uses URIs as identifiers.=A0 I don't really care where th= ose identifiers are defined, but at present there is no standard property identifer in URI form that means "name".

http://sc= hema.org/name ? =A0Of course that doesn't have the language fragmen= t, though as you point out below, there's an argument it may not be nee= ded anyway. =A0/shrug
=A0

Using the URI fragment to indicate the language does introduce a number of distinct URIs, but having the language tag would need to be somewhere if we want to allow the language to be specified as part of the property.=A0 Unlike XML, we do not have additional attributes we can apply.=A0 Arguably, we do not need to specify the language and we allow a user to advertise just a single name.=A0 However, I've found it beneficial to allow people to advertise names in at least two different character sets.=A0 I can'= t read Chinese, Japanese, or Korean, for example, so allowing a western alphabet is helpful to be used in parallel with the native alphabet is nice.

Paul=A0


--001a11c38dfc3e33e704e87bb1ea-- From paulej@packetizer.com Fri Oct 11 12:16:17 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA7021E80FA for ; Fri, 11 Oct 2013 12:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqpfYx9ytAoG for ; Fri, 11 Oct 2013 12:16:12 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8535A21E8106 for ; Fri, 11 Oct 2013 12:16:02 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r9BJFxFU029756 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 11 Oct 2013 15:16:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1381518960; bh=/t9mF5zIT3Vz6t5FL6FxynPzTVUc9eFS6FzNPtDEf6U=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=Ordjg97mu18scuckKKkdjkECcElNN4kUIHwxLFeWCVcwmYIboK4a9ZaGrjA2nGpmb NRGn4TqWFMpHgNq5OuZA8lD+OfeZnAtvC4Yny22aneI0mD4Ek31Q0po5tA5ytroMUJ itE2WVewwXMVEd5keZbkgZUmAyCs8JhqY0KjBsYY= Message-ID: <52584B25.3060804@packetizer.com> Date: Fri, 11 Oct 2013 15:01:57 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Will Norris References: <52583040.1060405@packetizer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040200000503060905010200" Cc: webfinger , Melvin Carvalho Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 19:16:17 -0000 This is a multi-part message in MIME format. --------------040200000503060905010200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/11/2013 2:57 PM, Will Norris wrote: > > FOAF does not define a set of URI. Rather, it's XML-based > markup. WebFinger uses URIs as identifiers. I don't really care > where those identifiers are defined, but at present there is no > standard property identifer in URI form that means "name". > > > http://schema.org/name ? Of course that doesn't have the language > fragment, though as you point out below, there's an argument it may > not be needed anyway. /shrug Yeah, that would work. And one cold add a URI fragment to that definition easily enough. These are all too easy to create. Who will put a stake in the ground and declare one property ID is the standard? Paul --------------040200000503060905010200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/11/2013 2:57 PM, Will Norris wrote:
FOAF does not define a set of URI.  Rather, it's XML-based markup.  WebFinger uses URIs as identifiers.  I don't really care where those identifiers are defined, but at present there is no standard property identifer in URI form that means "name".

http://schema.org/name ?  Of course that doesn't have the language fragment, though as you point out below, there's an argument it may not be needed anyway.  /shrug
 

Yeah, that would work.  And one cold add a URI fragment to that definition easily enough.

These are all too easy to create.  Who will put a stake in the ground and declare one property ID is the standard?

Paul

--------------040200000503060905010200-- From Michael.Jones@microsoft.com Fri Oct 11 12:24:28 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE33411E8182 for ; Fri, 11 Oct 2013 12:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoEQ3tv2j+Bk for ; Fri, 11 Oct 2013 12:24:22 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0F33D11E80E8 for ; Fri, 11 Oct 2013 12:23:59 -0700 (PDT) Received: from DM2PR03CA007.namprd03.prod.outlook.com (10.141.52.155) by BN1PR03MB252.namprd03.prod.outlook.com (10.255.200.24) with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 11 Oct 2013 19:23:52 +0000 Received: from BN1BFFO11FD015.protection.gbl (2a01:111:f400:7c10::117) by DM2PR03CA007.outlook.office365.com (2a01:111:e400:2414::27) with Microsoft SMTP Server (TLS) id 15.0.785.10 via Frontend Transport; Fri, 11 Oct 2013 19:23:52 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD015.mail.protection.outlook.com (10.58.53.75) with Microsoft SMTP Server (TLS) id 15.0.795.6 via Frontend Transport; Fri, 11 Oct 2013 19:23:51 +0000 Received: from TK5EX14MBXC287.redmond.corp.microsoft.com ([169.254.2.182]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0136.001; Fri, 11 Oct 2013 19:23:02 +0000 From: Mike Jones To: "Paul E. Jones" , Will Norris Thread-Topic: [webfinger] Registration of a URN for WebFinger Properties Thread-Index: AQHOwWl9ybDUqupBPkahXG+1R0HWjpnnqpwAgAAgqwCABnPkgIAAT7eAgAAGU4CAAAxggIABARsAgAAjJACAAB64gIAAAVeAgAAFnLA= Date: Fri, 11 Oct 2013 19:23:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394377DEC284@TK5EX14MBXC287.redmond.corp.microsoft.com> References: <52583040.1060405@packetizer.com> <52584B25.3060804@packetizer.com> In-Reply-To: <52584B25.3060804@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394377DEC284TK5EX14MBXC287r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(24454002)(479174003)(377454003)(51856001)(53806001)(54356001)(74366001)(19300405004)(84326002)(15975445006)(47446002)(74502001)(46102001)(50986001)(4396001)(74662001)(59766001)(77982001)(47976001)(83072001)(16236675002)(49866001)(47736001)(80976001)(15202345003)(19580405001)(83322001)(19580395003)(44976005)(6806004)(56776001)(54316002)(55846006)(76786001)(76796001)(56816003)(512954002)(66066001)(81342001)(71186001)(76482001)(74876001)(33656001)(20776003)(63696002)(79102001)(81686001)(65816001)(80022001)(74706001)(81542001)(77096001)(31966008)(85306002)(15395725003)(81816001)(69226001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB252; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0996D1900D X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: webfinger , Melvin Carvalho Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 19:24:29 -0000 --_000_4E1F6AAD24975D4BA5B168042967394377DEC284TK5EX14MBXC287r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please permit me to weigh in in favor of re-using existing URIs whenever po= ssible. -- Mike From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Paul E. Jones Sent: Friday, October 11, 2013 12:02 PM To: Will Norris Cc: webfinger; Melvin Carvalho Subject: Re: [webfinger] Registration of a URN for WebFinger Properties On 10/11/2013 2:57 PM, Will Norris wrote: FOAF does not define a set of URI. Rather, it's XML-based markup. WebFing= er uses URIs as identifiers. I don't really care where those identifiers a= re defined, but at present there is no standard property identifer in URI f= orm that means "name". http://schema.org/name ? Of course that doesn't have the language fragment= , though as you point out below, there's an argument it may not be needed a= nyway. /shrug Yeah, that would work. And one cold add a URI fragment to that definition = easily enough. These are all too easy to create. Who will put a stake in the ground and d= eclare one property ID is the standard? Paul --_000_4E1F6AAD24975D4BA5B168042967394377DEC284TK5EX14MBXC287r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please permit me to weigh= in in favor of re-using existing URIs whenever possible.=

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: webfinger-bounces@ietf.org [mailto:webfinger-boun= ces@ietf.org] On Behalf Of Paul E. Jones
Sent: Friday, October 11, 2013 12:02 PM
To: Will Norris
Cc: webfinger; Melvin Carvalho
Subject: Re: [webfinger] Registration of a URN for WebFinger Propert= ies

 

On 10/11/2013 2:57 PM, Will Norris wrote:

FOAF does not define a set of URI.  Rather, it'= s XML-based markup.  WebFinger uses URIs as identifiers.  I don't= really care where those identifiers are defined, but at present there is n= o standard property identifer in URI form that means "name".

 

http://schema.org= /name ?  Of course that doesn't have the language fragment, though= as you point out below, there's an argument it may not be needed anyway. &= nbsp;/shrug

 


Yeah, that would work.  And one cold add a URI fragment to that defini= tion easily enough.

These are all too easy to create.  Who will put a stake in the ground = and declare one property ID is the standard?

Paul

--_000_4E1F6AAD24975D4BA5B168042967394377DEC284TK5EX14MBXC287r_-- From kidehen@openlinksw.com Fri Oct 11 13:02:23 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50DE21E80AA for ; Fri, 11 Oct 2013 13:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAirB7NJfikp for ; Fri, 11 Oct 2013 13:02:20 -0700 (PDT) Received: from mail.openlinksw.com (mail.openlinksw.com [63.119.36.38]) by ietfa.amsl.com (Postfix) with ESMTP id 9B18D21F9ACA for ; Fri, 11 Oct 2013 13:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openlinksw.com; s=x; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=+MST+xtgzuKvrkjLRsAna/M6ByWQpz5McfW/H6Og/+Q=; b=qYa0vLDyRPauH4mBuu+KWXopvgKSkRNIL3EiR++97/X1tn06mUJeKpNrpELy8wgYqdhMq9XAVUK65fgewX1CA92H76ZbMkKelytCvYmnC+ak6THmOGGNq/NvwDA7M4cd; Received: from dyn226.usnet.private ([192.168.11.226]) by mail.openlinksw.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1VUiuc-0002ti-A7 for webfinger@ietf.org; Fri, 11 Oct 2013 16:02:14 -0400 Message-ID: <52585946.10502@openlinksw.com> Date: Fri, 11 Oct 2013 16:02:14 -0400 From: Kingsley Idehen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: webfinger@ietf.org References: <52583040.1060405@packetizer.com> In-Reply-To: <52583040.1060405@packetizer.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020509050106050502020907" Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 20:02:23 -0000 This is a cryptographically signed message in MIME format. --------------ms020509050106050502020907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/11/13 1:07 PM, Paul E. Jones wrote: > > FOAF does not define a set of URI. Rather, it's XML-based markup. =20 > WebFinger uses URIs as identifiers. I don't really care where those=20 > identifiers are defined, but at present there is no standard property=20 > identifer in URI form that means "name". FOAF [1] isn't XML-based markup. It is an RDF model oriented vocabulary=20 that's accessible in a variety of formats. Basically, FOAF provides=20 modelling for entities and entity relationships in domains such as=20 social networks. URIs are Names. An HTTP URI can also be used to Name (or Denote) anything, and that=20 includes Relations. An HTTP URL is a type of HTTP URI that Names (or Denotes) a Web Document.= A WebID is a type of HTTP URI that Names (or Denotes) an entity of type=20 Agent (Person, Organization, Software, Machine etc..) . Webfinger enables the use of acct: scheme URIs to Name (or Denote)=20 entities of type Person (and possibly other Agent types). Name->Address Indirection: When I look-up an HTTP URL that denotes a Document or WebID that denotes = an Agent my request resolves to data that describes the URI's referent. The Webfinger protocol enables me look-up an acct: scheme URI such that = it resolves to data that describes the URI's referent. Data Formats: When I look-up an HTTP URL I more than likely get an HTML representation = of data. When I look-up a WebID I will get RDF model based Linked Data in formats = such as Turtle, JSON-LD, RDFa, RDF/XML etc.. When I lookup an acct: scheme URI (via Webfinger protocol) I will get=20 EAV model structured data in JRD or XRD format. Ultimately, I think its time we all coalesce around the same thing=20 (webby structured data), since the host OS (World Wide Web) already has=20 all the thorny issues addressed in its core architecture :-) Links: 1. http://xmlns.com/foaf/spec/ 2. http://bit.ly/10Y9FL1 -- HTTP URIs as Names for anything has been=20 part of the Web's architecture since inception . --=20 Regards, Kingsley Idehen=09 Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen --------------ms020509050106050502020907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEtTCC BLEwggOZoAMCAQICAgYRMA0GCSqGSIb3DQEBDQUAMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNv ZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZTAeFw0xMzEwMDEy MDA4NDNaFw0xMzEwMzEyMDA4NDNaMH4xHDAaBgNVBAMUE0BraWRlaGVuIChMaW5rZWRJbikx HTAbBgNVBAoTFFBlcnNvbmFsIERhdGEgU3BhY2UgMQswCQYDVQQGEwJVUzELMAkGA1UECBMC TUExJTAjBgkqhkiG9w0BCQEWFmtpZGVoZW5Ab3Blbmxpbmtzdy5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCgJjN1Vxir8JqQPULDoKLzVrF2ysXT+esccgHmqC5pgHIV sgE3DXOoHh9ANI4WQ75QJF+ZZBSSgwraf4wwtWBaWApb3tQCipcluLYFgBXeoHDwnKA70cPD HoDa5Ijs/1e1EzriEi7FwIn3X9MPOTMWpYAfzm4wD5Tdod3lsiWXzo5EJa8mITyqOkNkuLyZ ZQx6pHFMctby3+7bZZkIEa9SmNamRyQAYpY7TfnTHbL25AMCsnIs2QQvQtYyrd/Y97af4/yL /dJdMQcgQ/SIz1rLDIx+vSmKnq2lhCGLIvt+HzvvQE2UnDwW4ORfuGUPRN+F/EzrP+VlsXv5 74gNB9q9AgMBAAGjggF0MIIBcDAdBgNVHQ4EFgQU6O4BGpchUYb4mfp+6Q88Mr1WupMwbAYD VR0RBGUwY4ZJaHR0cDovL2lkLm15b3BlbmxpbmsubmV0L2Fib3V0L2lkL2VudGl0eS9odHRw L3d3dy5saW5rZWRpbi5jb20vaW4va2lkZWhlboEWa2lkZWhlbkBvcGVubGlua3N3LmNvbTA+ BgNVHRIENzA1hjNodHRwOi8vaWQubXlvcGVubGluay5uZXQvaXNzdWVyL2tleS9kYmEvaWRf cnNhI3RoaXMwNgYJYIZIAYb4QgENBCkWJ0NlcnRpZmljYXRlIEdlbmVyYXRlZCBieSBPcGVu TGluayBZb3VJRDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwNwYIYIZIAbaf SQEEKxYpaHR0cDovL2lkLm15b3BlbmxpbmsubmV0L2NlcnRnZW4va2V5Lzk4NzgwDgYDVR0P AQH/BAQDAgWgMA0GCSqGSIb3DQEBDQUAA4IBAQAVCV8iBywpe8sCzleVJI+euKU4c1Wa/6Bh A/JO4S5TT+iVIHSK1I9BrBHPC0nO9AFN738h2i3kEMtPnHTgSwot2MuceJMYEwrxTalAc1bb gJ+7IQughgtTMnjPLPBU2a/gUI2DHeTYK8sFyfQgqOSmed9bvqT8F5s8eNd7Q9liiMC7T0vf uYUYXMOWracYvVHCS77TUHhKD/sd/owpE6q9MUrpqOKU+PvH549KYhQFIt+8ESgsnBOfa/G1 wIO/TaZxt0JqX+qIg0SCJxiWO64Yfz1ALNQlcGch9gEpHEKrwUTvf/QIR2u7Db5IdXv/Eb29 pNbShthpjHTMyVL+e9fvMYIC7zCCAusCAQEwRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0 d2FyZSBMb2NhbCBDQTEaMBgGA1UECgwRT3BlbkxpbmsgU29mdHdhcmUCAgYRMAkGBSsOAwIa BQCgggF9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTAx MTIwMDIxNFowIwYJKoZIhvcNAQkEMRYEFJxFd5jLK5+XMxwkRMlq83v9jfcXMFYGCSsGAQQB gjcQBDFJMEcwQTEjMCEGA1UEAwwaT3BlbkxpbmsgU29mdHdhcmUgTG9jYWwgQ0ExGjAYBgNV BAoMEU9wZW5MaW5rIFNvZnR3YXJlAgIGETBYBgsqhkiG9w0BCRACCzFJoEcwQTEjMCEGA1UE AwwaT3BlbkxpbmsgU29mdHdhcmUgTG9jYWwgQ0ExGjAYBgNVBAoMEU9wZW5MaW5rIFNvZnR3 YXJlAgIGETBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAF8HzvzVMNZWE72BUNV8fcRugjTXPoKLMFq+ pwGozX+VVQmmzBIaq1HugpSOLOxkHJzPOIlsSQ8HtyJ32aXFYyu4ibg3ukUh+XoZSvB1149B Zntc8HodZBq8jrawxc2bu46BG6/Mw+EHqgrUIZNd8QsLTFReFObvTj4itRJU07+Zc5NO09KU 9yy0+ROjVt8p4dijNnw08+5oG3djrdz0cGvmIHdx17SyHPacbtZZZAbfKRw5kzq4UWBYVyKS W7sGBF4cu2HqsKNi3PfmKDhCBEBp+4VehVgVipratpwP0zHkjx8Vg1bwNZWVmo8NK/kn15c2 FKI4pyEzEg8VO6oSMd4AAAAAAAA= --------------ms020509050106050502020907-- From melvincarvalho@gmail.com Fri Oct 11 13:18:02 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCA521F9A70 for ; Fri, 11 Oct 2013 13:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id We8uZPVDyLDO for ; Fri, 11 Oct 2013 13:18:01 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1410E21F9A6D for ; Fri, 11 Oct 2013 13:17:56 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ep20so3882036lab.16 for ; Fri, 11 Oct 2013 13:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BxdqWBcojUJjMCppireIzuL0T1AhFYqLcNc/AmIv4fE=; b=G6lQcI9buV9Hf+et9gelnf935q83wIj2j8p+LlASRGj2eoLrruKqEiL0KQY0+yWDSx q4z2OGc1xjzVIh8PIKjS7tKp/7M5PXdU8zl54Xj94d0FNHz0bW+NGzB9FZChuMhhvM4Q 7raK9YAhtJBpoqQ5ndUJK5WIFzkcpyy9g12Pl5ly3oYqQRJ0F/Offf7oEssi4wFt1qmz cZ9QxtkFxRqPjM89cbWwDlBctPJASJKp2SDB1OhA6ZPPEf2RpMQfOBOx60oF+nKAuIv2 xJIurZNJoydcsiYPTKfoiReb5p5+TRiFzwa6qZ+whzILUWj716hVCSFmasLQoObtG5At +aNA== MIME-Version: 1.0 X-Received: by 10.112.42.68 with SMTP id m4mr18264005lbl.4.1381522675518; Fri, 11 Oct 2013 13:17:55 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Fri, 11 Oct 2013 13:17:55 -0700 (PDT) In-Reply-To: <52585946.10502@openlinksw.com> References: <52583040.1060405@packetizer.com> <52585946.10502@openlinksw.com> Date: Fri, 11 Oct 2013 22:17:55 +0200 Message-ID: From: Melvin Carvalho To: Kingsley Idehen Content-Type: multipart/alternative; boundary=001a1133687652d3ce04e87cd08a Cc: webfinger Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 20:18:02 -0000 --001a1133687652d3ce04e87cd08a Content-Type: text/plain; charset=ISO-8859-1 On 11 October 2013 22:02, Kingsley Idehen wrote: > On 10/11/13 1:07 PM, Paul E. Jones wrote: > >> >> FOAF does not define a set of URI. Rather, it's XML-based markup. >> WebFinger uses URIs as identifiers. I don't really care where those >> identifiers are defined, but at present there is no standard property >> identifer in URI form that means "name". >> > > FOAF [1] isn't XML-based markup. It is an RDF model oriented vocabulary > that's accessible in a variety of formats. Basically, FOAF provides > modelling for entities and entity relationships in domains such as social > networks. > > URIs are Names. > > An HTTP URI can also be used to Name (or Denote) anything, and that > includes Relations. > > An HTTP URL is a type of HTTP URI that Names (or Denotes) a Web Document. > > A WebID is a type of HTTP URI that Names (or Denotes) an entity of type > Agent (Person, Organization, Software, Machine etc..) . > > Webfinger enables the use of acct: scheme URIs to Name (or Denote) > entities of type Person (and possibly other Agent types). > > Name->Address Indirection: > > When I look-up an HTTP URL that denotes a Document or WebID that denotes > an Agent my request resolves to data that describes the URI's referent. > > The Webfinger protocol enables me look-up an acct: scheme URI such that > it resolves to data that describes the URI's referent. > > Data Formats: > > When I look-up an HTTP URL I more than likely get an HTML representation > of data. > When I look-up a WebID I will get RDF model based Linked Data in formats > such as Turtle, JSON-LD, RDFa, RDF/XML etc.. > When I lookup an acct: scheme URI (via Webfinger protocol) I will get EAV > model structured data in JRD or XRD format. > > Ultimately, I think its time we all coalesce around the same thing (webby > structured data), since the host OS (World Wide Web) already has all the > thorny issues addressed in its core architecture :-) > +1 > > > Links: > > 1. http://xmlns.com/foaf/spec/ > 2. http://bit.ly/10Y9FL1 -- HTTP URIs as Names for anything has been part > of the Web's architecture since inception . > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/**blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/**112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/**kidehen > > > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --001a1133687652d3ce04e87cd08a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 11 October 2013 22:02, Kingsley Idehen <kidehen@openlinksw= .com> wrote:
On 10/11/13 1:07 PM, Paul = E. Jones wrote:

FOAF does not define a set of URI. =A0Rather, it's XML-based markup. = =A0WebFinger uses URIs as identifiers. =A0I don't really care where tho= se identifiers are defined, but at present there is no standard property id= entifer in URI form that means "name".

FOAF [1] isn't XML-based markup. It is an RDF model oriented vocabulary= that's accessible in a variety of formats. Basically, FOAF provides mo= delling for entities and entity relationships in domains such as social net= works.

URIs are Names.

An HTTP URI can also be used to Name (or Denote) anything, and that include= s Relations.

An HTTP URL is a type of HTTP URI that Names (or Denotes) a Web Document.
A WebID is a type of HTTP URI that Names (or Denotes) an entity of type Age= nt (Person, Organization, Software, Machine etc..) .

Webfinger enables the use of acct: scheme URIs to Name (or Denote) entities= of type Person (and possibly other Agent types).

Name->Address Indirection:

When I look-up an HTTP URL that denotes a Document or WebID that denotes an= Agent my request resolves to data that describes the URI's referent.
The Webfinger protocol enables me =A0look-up an acct: scheme URI such that = it resolves to data that describes the URI's referent.

Data Formats:

When I look-up an HTTP URL I more than likely get an HTML representation of= data.
When I look-up a WebID I will get RDF model based Linked Data in formats su= ch as Turtle, JSON-LD, RDFa, RDF/XML etc..
When I lookup an acct: scheme URI (via Webfinger protocol) I will get EAV m= odel structured data in JRD or XRD format.

Ultimately, I think its time we all coalesce around the same thing (webby s= tructured data), since the host OS (World Wide Web) already has all the tho= rny issues addressed in its core architecture :-)

+1
=A0


Links:

1. http://xmlns.c= om/foaf/spec/
2. http://bit.ly/10Y9FL= 1 -- HTTP URIs as Names for anything has been part of the Web's arc= hitecture since inception .<= br>
--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http:/= /www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/11239976774050861835= 0/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen






_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--001a1133687652d3ce04e87cd08a-- From melvincarvalho@gmail.com Sat Oct 12 07:42:21 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E2D21E80F4 for ; Sat, 12 Oct 2013 07:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Grzb1S-OTxCs for ; Sat, 12 Oct 2013 07:42:20 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAA921E8176 for ; Sat, 12 Oct 2013 07:42:19 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id o14so4316372lbi.4 for ; Sat, 12 Oct 2013 07:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J+jB0mPWo1n/dFsOXw5aINIlaToNypsBvzKEQbn5zQE=; b=1D3BHC1s8JwKFVa9wLcrpngl1jeUfejXK3Z5ld+PaM2foR3E8GrkepgWCM+9tU7OJf cRfjcOmd15WjYD/Rw1kaVWjF1pcUJv7roRjSF8UoZGZtgBTBOiLOB/4bVNXHn4n97e3w Dy6Hc1ux/BNL1LFd3TnqD9k8ezaQw8B8rf0qXhXpaa/wR3d6479BEcIU/izcvzQTfr6v PBGwvs3KoVM7wshQesmeQGTuY514osSgCsKoJhF0XMFNsoXKnrmNGKtyDYt6uyYrTpz1 lkj+1kQ1hAiZgIO4ntcbnnWV+T/YY1CrRchebljH/5sHbN1PierqB9mLjKnc7p3yCJkX l8QA== MIME-Version: 1.0 X-Received: by 10.152.88.74 with SMTP id be10mr21644217lab.4.1381588939050; Sat, 12 Oct 2013 07:42:19 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Sat, 12 Oct 2013 07:42:18 -0700 (PDT) In-Reply-To: <52584B25.3060804@packetizer.com> References: <52583040.1060405@packetizer.com> <52584B25.3060804@packetizer.com> Date: Sat, 12 Oct 2013 16:42:18 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a11c34e6cf0144a04e88c3d2b Cc: webfinger , Will Norris Subject: Re: [webfinger] Registration of a URN for WebFinger Properties X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 14:42:21 -0000 --001a11c34e6cf0144a04e88c3d2b Content-Type: text/plain; charset=ISO-8859-1 On 11 October 2013 21:01, Paul E. Jones wrote: > On 10/11/2013 2:57 PM, Will Norris wrote: > > FOAF does not define a set of URI. Rather, it's XML-based markup. >> WebFinger uses URIs as identifiers. I don't really care where those >> identifiers are defined, but at present there is no standard property >> identifer in URI form that means "name". >> > > http://schema.org/name ? Of course that doesn't have the language > fragment, though as you point out below, there's an argument it may not be > needed anyway. /shrug > > > > Yeah, that would work. And one cold add a URI fragment to that definition > easily enough. > > These are all too easy to create. Who will put a stake in the ground and > declare one property ID is the standard? > It would be nice if everyone could settle on one term, but the urge to reinvent is just too strong for many to resist. Properties on the web are bottom-up by nature. There is no "one" standard, and the web is too big for there ever to be one, in truth there's some overlap between all vocabs. WRT to webfinger, as a common pattern, I'd suggest reusing foaf:name as it's the longest used relation of this type on the web, there must be around 10-100 million examples of them out there by now. "http://xmlns.com/foaf/0.1/name" Of course there's something of a problem in webfinger if you have two names (eg Bono and Paul Hewson), that's not allowed. > > Paul > > --001a11c34e6cf0144a04e88c3d2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 11 October 2013 21:01, Paul E. Jones <paulej@packetizer.com= > wrote:
=20 =20 =20
On 10/11/2013 2:57 PM, Will Norris wrote:
FOAF does not define a se= t of URI.=A0 Rather, it's XML-based markup.=A0 WebFinger uses U= RIs as identifiers.=A0 I don't really care where those identifier= s are defined, but at present there is no standard property identifer in URI form that means "name".

http://sche= ma.org/name ? =A0Of course that doesn't have the language fragment, though = as you point out below, there's an argument it may not be needed anyway. =A0/shrug
=A0

Yeah, that would work.=A0 And one cold add a URI fragment to that definition easily enough.

These are all too easy to create.=A0 Who will put a stake in the ground and declare one property ID is the standard?

It would be nice if everyone could settle on one term, but the urge to r= einvent is just too strong for many to resist.=A0 Properties on the web are= bottom-up by nature.=A0 There is no "one" standard, and the web = is too big for there ever to be one, in truth there's some overlap betw= een all vocabs.=A0

WRT to webfinger, as a common pattern, I'd suggest reusi= ng foaf:name as it's the longest used relation of this type on the web,= there must be around 10-100 million examples of them out there by now.

"http://xmlns.com/foaf/= 0.1/name"

Of course there's something of a p= roblem in webfinger if you have two names (eg Bono and Paul Hewson), that&#= 39;s not allowed.
=A0

Paul


--001a11c34e6cf0144a04e88c3d2b-- From konklone@gmail.com Sat Oct 12 15:29:35 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E0111E8155 for ; Sat, 12 Oct 2013 15:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEUasZ8RiEUq for ; Sat, 12 Oct 2013 15:29:34 -0700 (PDT) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 24E1811E80F7 for ; Sat, 12 Oct 2013 15:29:33 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id f15so2599304eak.36 for ; Sat, 12 Oct 2013 15:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=ZMLpu82YCE1g7M3ezRtxU83sVL8nmFLfB0+GMktaC6w=; b=G+eMdfog9JSg6WUPJ2Hi08PSeoDhZQARCAsCnaeo9yt98LyP1Yzr+42wFDAAq4NMEi TzCTrGJme/+oCo6LFCBh8qh5hhtD2S9LINmBbf0y8dZWfC1YRooqwXqJ3+jeU8WIxhg+ wZTD3tU45gB1IXrO2FYmaHIOLIZQBEUxfS62fZFxOsHSbTaXeEEeeZh/5Ph9Z52bvhJp Q/RTx+Qvhv5swC0stAWlNE1HNQxXXw8+1q/oy1j9Gbn/FqakhM3hftxy4abikQDZyKfD deIFBi7ghy0WQt2AQF3kbBhsa57ZuckAO8fq1VgFsca217W7bk0Ya9Zheo/VRBu90LPC UaQg== X-Received: by 10.14.107.68 with SMTP id n44mr42134743eeg.26.1381616972154; Sat, 12 Oct 2013 15:29:32 -0700 (PDT) MIME-Version: 1.0 Sender: konklone@gmail.com Received: by 10.223.167.69 with HTTP; Sat, 12 Oct 2013 15:28:50 -0700 (PDT) From: Eric Mill Date: Sat, 12 Oct 2013 18:28:50 -0400 X-Google-Sender-Auth: xzTzcQBMGR3iisunHQgibSn2WNY Message-ID: To: "webfinger@ietf.org" , webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=001a11c29ad2d74d9c04e892c44d Subject: [webfinger] Is application/json an acceptable content type for JRDs? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 22:29:35 -0000 --001a11c29ad2d74d9c04e892c44d Content-Type: text/plain; charset=ISO-8859-1 I've been reading through the Webfinger spec, and it uses application/jrd+json in all the examples, and describes the media type it's registering -- but it never says whether or not a server using application/json as a content type should fail or not. I could potentially see some servers wishing to use application/json, so that applications that are used for all kinds of JSON manipulation, like JSONView, could properly pick up on it. -- Eric -- konklone.com | @konklone --001a11c29ad2d74d9c04e892c44d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've been reading through the Webfinger spec, and it u= ses application/jrd+json in all the examples, and describes the media type = it's registering -- but it never says whether or not a server using app= lication/json as a content type should fail or not.

I could potentially see some servers wishing to use applicat= ion/json, so that applications that are used for all kinds of JSON manipula= tion, like JSONView, could properly pick up on it.

-- Eric

--
<= a href=3D"http://konklone.com" target=3D"_blank">konklone.com | @konklone
=
--001a11c29ad2d74d9c04e892c44d-- From melvincarvalho@gmail.com Sat Oct 12 15:40:42 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AE111E80FB for ; Sat, 12 Oct 2013 15:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVm8Y23cyrBj for ; Sat, 12 Oct 2013 15:40:42 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id CA97E21F9609 for ; Sat, 12 Oct 2013 15:40:41 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ea20so4584894lab.13 for ; Sat, 12 Oct 2013 15:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1cCHwXNRmrzhzgAXTGemXK6Nif65lRL4TFMqYOw49yk=; b=d2IstJt+kpYfj/VV2jD2p8Pdx8W/u6OArJo0/o8tGKC/y/GW58IsLV3zgBDVgCsOyi xiVWCQR3AQQWVWAdBGNclff8jpu4zLK5dBnTT54q+DdGHRaTmYXcHV7AXfTH3FkZJ6EP YItY5G6cj/LHga3HC+SjiqkVxuhSRqGo45r4Pn4vBfwWg4dpRBsWGkQanE0ccz5q0kzb Le2BMlcAtD1XQod5llY/MOr/fBeF7Qzz6wXYPG52fUlNarCQNCJ6WXzJiEzdjPVxUvBX UGMnjygRiLJI8Z+JXrC/c16+uDzzyoUvhlmdZOOVvdeq7z2edk7FjlD626CW7cLtzFUI 5wjw== MIME-Version: 1.0 X-Received: by 10.112.57.49 with SMTP id f17mr23327321lbq.26.1381617640401; Sat, 12 Oct 2013 15:40:40 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Sat, 12 Oct 2013 15:40:40 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 Oct 2013 00:40:40 +0200 Message-ID: From: Melvin Carvalho To: Eric Mill Content-Type: multipart/alternative; boundary=001a1133eacaabf27004e892ecca Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" Subject: Re: [webfinger] Is application/json an acceptable content type for JRDs? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 22:40:42 -0000 --001a1133eacaabf27004e892ecca Content-Type: text/plain; charset=ISO-8859-1 On 13 October 2013 00:28, Eric Mill wrote: > I've been reading through the Webfinger spec, and it uses > application/jrd+json in all the examples, and describes the media type it's > registering -- but it never says whether or not a server using > application/json as a content type should fail or not. > > I could potentially see some servers wishing to use application/json, so > that applications that are used for all kinds of JSON manipulation, like > JSONView, could properly pick up on it. > My interpretation is that the server must set Mime Type application/jrd+json if it's serving JRD, which is the only mandatory serialization. Previously there was an XML format (XRD) which is still in use in some places. > > -- Eric > > -- > konklone.com | @konklone > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --001a1133eacaabf27004e892ecca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 13 October 2013 00:28, Eric Mill <eric@konklone.com> wrote:
I've= been reading through the Webfinger spec, and it uses application/jrd+json = in all the examples, and describes the media type it's registering -- b= ut it never says whether or not a server using application/json as a conten= t type should fail or not.

I could potentially see some servers wishing to use applicat= ion/json, so that applications that are used for all kinds of JSON manipula= tion, like JSONView, could properly pick up on it.

My interpretation is that the server must set Mime Type= application/jrd+json if it's serving JRD, which is the only mandatory = serialization.=A0 Previously there was an XML format (XRD) which is still i= n use in some places.
=A0

-- Eric

--
<= a href=3D"http://konklone.com" target=3D"_blank">konklone.com | @konklone
=

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--001a1133eacaabf27004e892ecca-- From konklone@gmail.com Sat Oct 12 15:59:12 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD69721F9998 for ; Sat, 12 Oct 2013 15:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RLjPK3YwAgR for ; Sat, 12 Oct 2013 15:59:12 -0700 (PDT) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id BBCB021F9A40 for ; Sat, 12 Oct 2013 15:59:09 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id e53so2640654eek.13 for ; Sat, 12 Oct 2013 15:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=gRMApspyp/tWEp6mvuY2d1C06yE9RjDJ4rbXZfqDsZk=; b=bYbhWFiaUefdDqtiplz86yDc02pQvZ+x/RMhCiyXTZcY/SJcSLdoG/2jfz+8UwxUYX JZkq1tfsV83los8YjH+klt2wO/9afeQYfjHEvkJitBiJ7dJOLtn3xCKOL7cCdahmpW8y CykF7Rx+iD2Zm1vl2nRdyQF/LXtFLsn3LO61b/9pEyWu0alkplsyvqpzYvX1HwfRC2ed qPLHx0nHE8xINzUBqEBuhlxduAHOBJAkLq2NjOF0Xz1AcQ747CyiF2p9zxUH1cToWmlD 4e4wZqA9KhB8oydYbORY0fzINs2OpbLWyznrCyQFp2WqRgHEAwPqpvWNq4xMeXiYxOI0 9NWA== X-Received: by 10.14.107.68 with SMTP id n44mr42321300eeg.26.1381618748845; Sat, 12 Oct 2013 15:59:08 -0700 (PDT) MIME-Version: 1.0 Sender: konklone@gmail.com Received: by 10.223.167.69 with HTTP; Sat, 12 Oct 2013 15:58:28 -0700 (PDT) In-Reply-To: References: From: Eric Mill Date: Sat, 12 Oct 2013 18:58:28 -0400 X-Google-Sender-Auth: PZiVxLqTIjzYHpSyQDyE5aq-P38 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=001a11c29ad2bd74ca04e8932e3e Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Is application/json an acceptable content type for JRDs? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 22:59:12 -0000 --001a11c29ad2bd74ca04e8932e3e Content-Type: text/plain; charset=ISO-8859-1 So if I'm writing a client, and I get an application/json Content Type, it should fail? Since the spec doesn't seem to explicitly mandate this, and the content *is* valid JSON, this seems a bit restrictive to me. On Sat, Oct 12, 2013 at 6:40 PM, Melvin Carvalho wrote: > > > > On 13 October 2013 00:28, Eric Mill wrote: > >> I've been reading through the Webfinger spec, and it uses >> application/jrd+json in all the examples, and describes the media type it's >> registering -- but it never says whether or not a server using >> application/json as a content type should fail or not. >> >> I could potentially see some servers wishing to use application/json, so >> that applications that are used for all kinds of JSON manipulation, like >> JSONView, could properly pick up on it. >> > > My interpretation is that the server must set Mime Type > application/jrd+json if it's serving JRD, which is the only mandatory > serialization. Previously there was an XML format (XRD) which is still in > use in some places. > > >> >> -- Eric >> >> -- >> konklone.com | @konklone >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> > -- > > --- > You received this message because you are subscribed to the Google Groups > "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to webfinger+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- konklone.com | @konklone --001a11c29ad2bd74ca04e8932e3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So if I'm writing a client, and I get an application/j= son Content Type, it should fail? Since the spec doesn't seem to explic= itly mandate this, and the content *is* valid JSON, this seems a bit restri= ctive to me.


On Sat, Oct 1= 2, 2013 at 6:40 PM, Melvin Carvalho <melvincarvalho@gmail.com&g= t; wrote:



On 13 October 2013= 00:28, Eric Mill <eric@konklone.com> wrote:
I've= been reading through the Webfinger spec, and it uses application/jrd+json = in all the examples, and describes the media type it's registering -- b= ut it never says whether or not a server using application/json as a conten= t type should fail or not.

I could potentially see some servers wishing to use applicat= ion/json, so that applications that are used for all kinds of JSON manipula= tion, like JSONView, could properly pick up on it.

My interpretation is that the server must set Mim= e Type application/jrd+json if it's serving JRD, which is the only mand= atory serialization.=A0 Previously there was an XML format (XRD) which is s= till in use in some places.
=A0

-- Eric

--
<= a href=3D"http://konklone.com" target=3D"_blank">konklone.com | @konklone
=

_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger


<= /font>

--
=A0
---
You received this message because you are subscribed to the Google Groups &= quot;WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
--001a11c29ad2bd74ca04e8932e3e-- From wnorris@gmail.com Sat Oct 12 16:57:16 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D935A21F9926 for ; Sat, 12 Oct 2013 16:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo-6+jxdLjsz for ; Sat, 12 Oct 2013 16:57:16 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CAC9321E805D for ; Sat, 12 Oct 2013 16:57:15 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id x13so12115564ief.29 for ; Sat, 12 Oct 2013 16:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=wBhse0p3cnTgwNMZC4zCPsFWhVaMubUiIc1oncm1I40=; b=SqRCMNS3kSSufB8BN6IYs82yNwNpXBhYx3EodDQacjU5W+swnsK8ecM3ijhHLP+vb8 2G1YHyd+R9TTuRdxvdaBVfFuIxHlCiktkaqlBKrGOqaqWNgaL2Ao5p1DbWTITNp8A24u uCk/A3HbOvML26q699WJXFtO/h06sS/i08JpeCP4FaFOnetYplBHbqJo19xN3Pbc8zqB EYRPx6eb5MrAcI9CTbXKVHsKbRLir3gzr0RY94zmTyRf2tdZpV+dnls5CeFM52SmMV0s JYoYvFk+HEuw2Cgv/9eDfr0XvVirY1fc8v1JPWRCf3BbIzz4rAb8RC9XYLPPG7n+XWa3 vYlA== X-Received: by 10.43.73.197 with SMTP id yt5mr16156804icb.0.1381622235065; Sat, 12 Oct 2013 16:57:15 -0700 (PDT) MIME-Version: 1.0 Sender: wnorris@gmail.com Received: by 10.64.7.50 with HTTP; Sat, 12 Oct 2013 16:56:44 -0700 (PDT) In-Reply-To: References: From: Will Norris Date: Sat, 12 Oct 2013 16:56:44 -0700 X-Google-Sender-Auth: iFsYMJb6PFRufJjcwfZR4vH_msA Message-ID: To: Eric Mill Content-Type: multipart/alternative; boundary=001a11c2190a88f79004e893fedf Cc: "webfinger@ietf.org" , webfinger@googlegroups.com Subject: Re: [webfinger] Is application/json an acceptable content type for JRDs? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 23:57:17 -0000 --001a11c2190a88f79004e893fedf Content-Type: text/plain; charset=ISO-8859-1 reading through some of the list archive (such as http://www.ietf.org/mail-archive/web/webfinger/current/msg00395.html and the rest of that thread), leads me to say that you *really* should use the correct mime type. I agree that for clients they probably should not fail on application/json, but I certainly wouldn't rely on that behavior as a publisher. I wonder how hard it would be to get JSONView updated to accept application/*+json in addition to application/json? On Sat, Oct 12, 2013 at 3:58 PM, Eric Mill wrote: > So if I'm writing a client, and I get an application/json Content Type, it > should fail? Since the spec doesn't seem to explicitly mandate this, and > the content *is* valid JSON, this seems a bit restrictive to me. > > > On Sat, Oct 12, 2013 at 6:40 PM, Melvin Carvalho > wrote: > >> >> >> >> On 13 October 2013 00:28, Eric Mill wrote: >> >>> I've been reading through the Webfinger spec, and it uses >>> application/jrd+json in all the examples, and describes the media type it's >>> registering -- but it never says whether or not a server using >>> application/json as a content type should fail or not. >>> >>> I could potentially see some servers wishing to use application/json, so >>> that applications that are used for all kinds of JSON manipulation, like >>> JSONView, could properly pick up on it. >>> >> >> My interpretation is that the server must set Mime Type >> application/jrd+json if it's serving JRD, which is the only mandatory >> serialization. Previously there was an XML format (XRD) which is still in >> use in some places. >> >> >>> >>> -- Eric >>> >>> -- >>> konklone.com | @konklone >>> >>> _______________________________________________ >>> webfinger mailing list >>> webfinger@ietf.org >>> https://www.ietf.org/mailman/listinfo/webfinger >>> >>> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "WebFinger" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to webfinger+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > konklone.com | @konklone > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --001a11c2190a88f79004e893fedf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
reading through some of the list archive (such as=A0= http://www.ietf.org/mail-archive/web/webfinger/current/msg00395.html an= d the rest of that thread), leads me to say that you *really* should use th= e correct mime type. =A0I agree that for clients they probably should not f= ail on application/json, but I certainly wouldn't rely on that behavior= as a publisher. =A0I wonder how hard it would be to get JSONView updated t= o accept application/*+json in addition to application/json?


On Sat, Oct 1= 2, 2013 at 3:58 PM, Eric Mill <eric@konklone.com> wrote:
So if I'm writing a client, and I get= an application/json Content Type, it should fail? Since the spec doesn'= ;t seem to explicitly mandate this, and the content *is* valid JSON, this s= eems a bit restrictive to me.


On = Sat, Oct 12, 2013 at 6:40 PM, Melvin Carvalho <melvincarvalho@gmail= .com> wrote:



On 13 October 2013 00:28, Eric Mill <eric@konklone.com>= wrote:
I've been reading through the Webfing= er spec, and it uses application/jrd+json in all the examples, and describe= s the media type it's registering -- but it never says whether or not a= server using application/json as a content type should fail or not.

I could potentially see some servers wishing to use applicat= ion/json, so that applications that are used for all kinds of JSON manipula= tion, like JSONView, could properly pick up on it.

My interpretation is that the server must set Mim= e Type application/jrd+json if it's serving JRD, which is the only mand= atory serialization.=A0 Previously there was an XML format (XRD) which is s= till in use in some places.
=A0

-- Eric

--
<= a href=3D"http://konklone.com" target=3D"_blank">konklone.com | @konklone
=

_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger


--
=A0
---
You received this message because you are subscribed to the Google Groups &= quot;WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--

_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger


--001a11c2190a88f79004e893fedf-- From paulej@packetizer.com Sat Oct 12 17:35:29 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B734C21E8098 for ; Sat, 12 Oct 2013 17:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JAwsP6gdz5e for ; Sat, 12 Oct 2013 17:35:25 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B3F8C11E8171 for ; Sat, 12 Oct 2013 17:35:24 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r9D0ZNHv021707 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 12 Oct 2013 20:35:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1381624523; bh=41vvSa03ifm4qfYzfTSxI//YaLi7miYTEfLzMXbP+xs=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=QgSFAO1H0SbYPfw3Ph3vwiv7Ja+IFQq8YN05ojf7JEfutmR4Lq/lLGTRh5u+qLR0k 5hQy+rMn2NWrVhqfSUOKpN3Eg7Y55Ge56n8y8NnyUAXoBwXa1nxFkefocjVqbbJEI9 kav61AzxyVpoL8sSgwKmj9L9tOdpB13IU53jL9oE= Message-ID: <5259EADA.1050601@packetizer.com> Date: Sat, 12 Oct 2013 20:35:38 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: webfinger@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080406040006040403070402" Subject: Re: [webfinger] Is application/json an acceptable content type for JRDs? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 00:35:29 -0000 This is a multi-part message in MIME format. --------------080406040006040403070402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yeah, I think the "be conservative with what you send and liberal with what you accept" comes to play here, as with most protocols. Servers are required to use application/jrd+json, but it's probably best if clients did not rely on that media type being returned. Just try to parse it. It either will or will not parse correctly. Paul On 10/12/2013 7:56 PM, Will Norris wrote: > reading through some of the list archive (such as > http://www.ietf.org/mail-archive/web/webfinger/current/msg00395.html > and the rest of that thread), leads me to say that you *really* should > use the correct mime type. I agree that for clients they probably > should not fail on application/json, but I certainly wouldn't rely on > that behavior as a publisher. I wonder how hard it would be to get > JSONView updated to accept application/*+json in addition to > application/json? > > > On Sat, Oct 12, 2013 at 3:58 PM, Eric Mill > wrote: > > So if I'm writing a client, and I get an application/json Content > Type, it should fail? Since the spec doesn't seem to explicitly > mandate this, and the content *is* valid JSON, this seems a bit > restrictive to me. > > > On Sat, Oct 12, 2013 at 6:40 PM, Melvin Carvalho > > wrote: > > > > > On 13 October 2013 00:28, Eric Mill > wrote: > > I've been reading through the Webfinger spec, and it uses > application/jrd+json in all the examples, and describes > the media type it's registering -- but it never says > whether or not a server using application/json as a > content type should fail or not. > > I could potentially see some servers wishing to use > application/json, so that applications that are used for > all kinds of JSON manipulation, like JSONView, could > properly pick up on it. > > > My interpretation is that the server must set Mime Type > application/jrd+json if it's serving JRD, which is the only > mandatory serialization. Previously there was an XML format > (XRD) which is still in use in some places. > > > -- Eric > > -- > konklone.com | @konklone > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > > -- > > --- > You received this message because you are subscribed to the > Google Groups "WebFinger" group. > To unsubscribe from this group and stop receiving emails from > it, send an email to webfinger+unsubscribe@googlegroups.com > . > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > konklone.com | @konklone > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --------------080406040006040403070402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yeah, I think the "be conservative with what you send and liberal with what you accept" comes to play here, as with most protocols.  Servers are required to use application/jrd+json, but it's probably best if clients did not rely on that media type being returned.  Just try to parse it.  It either will or will not parse correctly.

Paul

On 10/12/2013 7:56 PM, Will Norris wrote:
reading through some of the list archive (such as http://www.ietf.org/mail-archive/web/webfinger/current/msg00395.html and the rest of that thread), leads me to say that you *really* should use the correct mime type.  I agree that for clients they probably should not fail on application/json, but I certainly wouldn't rely on that behavior as a publisher.  I wonder how hard it would be to get JSONView updated to accept application/*+json in addition to application/json?


On Sat, Oct 12, 2013 at 3:58 PM, Eric Mill <eric@konklone.com> wrote:
So if I'm writing a client, and I get an application/json Content Type, it should fail? Since the spec doesn't seem to explicitly mandate this, and the content *is* valid JSON, this seems a bit restrictive to me.


On Sat, Oct 12, 2013 at 6:40 PM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:



On 13 October 2013 00:28, Eric Mill <eric@konklone.com> wrote:
I've been reading through the Webfinger spec, and it uses application/jrd+json in all the examples, and describes the media type it's registering -- but it never says whether or not a server using application/json as a content type should fail or not.

I could potentially see some servers wishing to use application/json, so that applications that are used for all kinds of JSON manipulation, like JSONView, could properly pick up on it.

My interpretation is that the server must set Mime Type application/jrd+json if it's serving JRD, which is the only mandatory serialization.  Previously there was an XML format (XRD) which is still in use in some places.
 

-- Eric

--

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--
 
---
You received this message because you are subscribed to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger




_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--------------080406040006040403070402-- From konklone@gmail.com Sat Oct 12 20:34:18 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55FC21F9193 for ; Sat, 12 Oct 2013 20:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srRarKkB0dSZ for ; Sat, 12 Oct 2013 20:34:17 -0700 (PDT) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id ABC3621E80AB for ; Sat, 12 Oct 2013 20:34:15 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id f15so2627999eak.22 for ; Sat, 12 Oct 2013 20:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=nNNR9LpUGGwNqesjieBWfNYJA23E1gIQFyJI/UlcpOg=; b=bgFrIiTu86d2R3VOAfZU8/OPjwbw0rXW9haOq94cmnTiynWV2RsgbpasTm2TG8eFNk JkAtwkVSL7sAsngsJIrnpF08UxWpki+mZWZUlPUVgvWjNdjxHYpcXlRNVkBoXufTKQHP llMBxnswlTZYrUb9U+G9/y53+uTGitEiJFq/GCCTH+J0q7Hp6Ml+N4vTkIjB9m4eJBsP UnLyQkZ6B6HGEjeEM++EIZY2v6PqSuJRohgbUHW+0LgMbG5VmO02cPesovRFBdycVUge 0DYSSC8iRj6VSndi6VuwRyHGSxSpoVh67q+2nDeVsB8Xue6Hcr0+gogw5ozLKcsq71tY 8M1w== X-Received: by 10.14.210.8 with SMTP id t8mr43066181eeo.39.1381635254704; Sat, 12 Oct 2013 20:34:14 -0700 (PDT) MIME-Version: 1.0 Sender: konklone@gmail.com Received: by 10.223.167.69 with HTTP; Sat, 12 Oct 2013 20:33:34 -0700 (PDT) In-Reply-To: <5259EADA.1050601@packetizer.com> References: <5259EADA.1050601@packetizer.com> From: Eric Mill Date: Sat, 12 Oct 2013 23:33:34 -0400 X-Google-Sender-Auth: CAHrkXH0sw97ZUPka2wBaZPWNkw Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=047d7b603fe290dfc304e897063b Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Is application/json an acceptable content type for JRDs? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 03:34:18 -0000 --047d7b603fe290dfc304e897063b Content-Type: text/plain; charset=ISO-8859-1 Good points/ideas. I opened a ticketon the Firefox JSONView issue tracker to handle *+json, and +1'd the pre-existing threadon the Chrome JSONView tracker. On Sat, Oct 12, 2013 at 8:35 PM, Paul E. Jones wrote: > Yeah, I think the "be conservative with what you send and liberal with > what you accept" comes to play here, as with most protocols. Servers are > required to use application/jrd+json, but it's probably best if clients did > not rely on that media type being returned. Just try to parse it. It > either will or will not parse correctly. > > Paul > > > On 10/12/2013 7:56 PM, Will Norris wrote: > > reading through some of the list archive (such as > http://www.ietf.org/mail-archive/web/webfinger/current/msg00395.html and > the rest of that thread), leads me to say that you *really* should use the > correct mime type. I agree that for clients they probably should not fail > on application/json, but I certainly wouldn't rely on that behavior as a > publisher. I wonder how hard it would be to get JSONView updated to accept > application/*+json in addition to application/json? > > > On Sat, Oct 12, 2013 at 3:58 PM, Eric Mill wrote: > >> So if I'm writing a client, and I get an application/json Content Type, >> it should fail? Since the spec doesn't seem to explicitly mandate this, and >> the content *is* valid JSON, this seems a bit restrictive to me. >> >> >> On Sat, Oct 12, 2013 at 6:40 PM, Melvin Carvalho < >> melvincarvalho@gmail.com> wrote: >> >>> >>> >>> >>> On 13 October 2013 00:28, Eric Mill wrote: >>> >>>> I've been reading through the Webfinger spec, and it uses >>>> application/jrd+json in all the examples, and describes the media type it's >>>> registering -- but it never says whether or not a server using >>>> application/json as a content type should fail or not. >>>> >>>> I could potentially see some servers wishing to use application/json, >>>> so that applications that are used for all kinds of JSON manipulation, like >>>> JSONView, could properly pick up on it. >>>> >>> >>> My interpretation is that the server must set Mime Type >>> application/jrd+json if it's serving JRD, which is the only mandatory >>> serialization. Previously there was an XML format (XRD) which is still in >>> use in some places. >>> >>> >>>> >>>> -- Eric >>>> >>>> -- >>>> konklone.com | @konklone >>>> >>>> _______________________________________________ >>>> webfinger mailing list >>>> webfinger@ietf.org >>>> https://www.ietf.org/mailman/listinfo/webfinger >>>> >>>> >>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "WebFinger" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to webfinger+unsubscribe@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> >> -- >> konklone.com | @konklone >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> > > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > -- konklone.com | @konklone --047d7b603fe290dfc304e897063b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Good points/ideas. I opened a ticket on the Firefox JSONView issue trac= ker to handle *+json, and +1'd the pre-existing = thread on the Chrome JSONView tracker.


On Sat, Oct 1= 2, 2013 at 8:35 PM, Paul E. Jones <paulej@packetizer.com> wrote:
=20 =20 =20
Yeah, I think the "be conservative with what you send and liberal with what you accept" comes to play here, as with most protocols.= =A0 Servers are required to use application/jrd+json, but it's probably best if clients did not rely on that media type being returned.=A0 Just try to parse it.=A0 It either will or will not parse correctly.

Paul


On 10/12/2013 7:56 PM, Will Norris wrote:
reading through some of the list archive (such as=A0= http://www.ietf.org/mail-archive/web/webfinger/curr= ent/msg00395.html and the rest of that thread), leads me to say that you *really* should use the correct mime type. =A0I agree that for clients they probably should not fail on application/json, but I certainly wouldn't rely on that behavior as a publisher. =A0I wonder how hard it would be to get JSONView updated to accept application/*+json in addition to application/json?


On Sat, Oct 12, 2013 at 3:58 PM, Eric Mill <eric@konklone.com> wrote:
So if I'm writing a client, and I get an application/json Content Type, it should fail? Since the spec doesn't seem to explicitly mandate this, and the content *is* valid JSON, this seems a bit restrictive to me.


On Sat, Oct 12, 2013 at 6:40 PM, Melvin Carvalho <melvincarvalho@gmai= l.com> wrote:



On 13 October 2013 00:28, Eric Mill <er= ic@konklone.com> wrote:
I've been reading through the Webfinger spec, and it uses application/jrd+json in all the examples, and describes the media type it's registering -- but it never says whether or not a server using application/json as a content type should fail or not.

I could potentially see some servers wishing to use application/json, so that applications that are used for all kinds of JSON manipulation, like JSONView, could properly pick up on it.

My interpretation is that the server must set Mime Type application/jrd+json if it's serving JRD, which is the only mandatory serialization.=A0 Previously there was an XML format (XRD) which is still in use in some places.
=A0

-- Eric

--

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/we= bfinger


--
=A0
---
You received this message because you are subscribed to the Google Groups "WebFinger= " group.
To unsubscribe from this group and stop receiving emails from it, send an email to w= ebfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/g= roups/opt_out.



--

_______________________________________________
webfinger mailing list
webfi= nger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger




_______________________________________________
webfinger mailing list
webfinger@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/webfinger


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger




--
--047d7b603fe290dfc304e897063b-- From konklone@gmail.com Mon Oct 14 13:32:40 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E865721F9CAF for ; Mon, 14 Oct 2013 13:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7ArfiDFcT7Y for ; Mon, 14 Oct 2013 13:32:39 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 703E921F9ADD for ; Mon, 14 Oct 2013 13:32:39 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id q16so3569970ead.7 for ; Mon, 14 Oct 2013 13:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=u64FLq2F4bGpfjKwjKxoEjTt4IohEcAi3X/BndyEIj0=; b=Tuaty7IOHYGs8s9WWczwkvxsPPgqgmAdtF9FSPWKJJByHXYIEtR1ihJ/JuElkF518V dyOYWuRQU9tluxusvtq9ngAyVgqCjRhqDpvQgJH/+fqmflaOv/o9x+aWziAA1M3qzhKT RQbJjDKTQ4exGB7F1caFvwDi2suLyXBLTR6UOv4Jpyp2TBtKYdwPo3LZcvSLPQGKnGXQ drxSYc3VLdJ8d607fq59CxjInHVaVFhGLUzSK1QxfgNb43dUEzLfuyvps0sCEBMC6+TG 1frDWKWZ0EH+8iTNR3fysbVtvL7AGsDJr0CttksucsvbvRGsYXXYIJJ+oGtmlpzU/a58 xPWA== X-Received: by 10.15.75.73 with SMTP id k49mr58330923eey.36.1381782758087; Mon, 14 Oct 2013 13:32:38 -0700 (PDT) MIME-Version: 1.0 Sender: konklone@gmail.com Received: by 10.223.167.69 with HTTP; Mon, 14 Oct 2013 13:31:56 -0700 (PDT) From: Eric Mill Date: Mon, 14 Oct 2013 16:31:56 -0400 X-Google-Sender-Auth: 57629vdX2tsRMmOXVDvUlDpbKec Message-ID: To: "webfinger@ietf.org" , webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=001a11c1af4c73e0ee04e8b95e82 Subject: [webfinger] Webfinger extension for Sinatra X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 20:32:41 -0000 --001a11c1af4c73e0ee04e8b95e82 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I just wrote an extension for Sinatra, a popular Ruby-based microframework, that adds a Webfinger endpoint for a given email address and set of metadata: https://github.com/konklone/sinatra-webfinger#a-webfinger-plugin-for-sinatra The idea here is to lower the barrier to adding a Webfinger endpoint for one's email, for people running Sinatra apps on their domain (like me). I'm using this on my blog here . It does a couple things I'd like your reaction to. For one, it auto-decides whether data should be in "properties" or "links" based on whether the value is a URL. For two, it lets you specify common short strings as keys, and does the mapping to a URI for you, when there is one. So this is the Ruby code: webfinger "eric@konklone.com" => { name: "Eric Mill", website: "https://konklone.com"} And this is what the endpoint will produce: { "subject": "eric@konklone.com", "properties": { "http://schema.org/name": "Eric Mill" }, "links": [ { "rel": "http://webfinger.net/rel/profile-page", "href": "https://konklone.com" } ]} I'm doing the mapping from field name to URI here: https://github.com/konklone/sinatra-webfinger/blob/master/data/urns.yml based on Will Norris' and Paul Jones' collections of URIs. Next, I'd like to tackle an extension for Jekyll, and a generator for a straight static file you can serve with a couple of lines in nginx/Apache/S3. I'll probably follow the approach I'm taking here in sinatra-webfinger as closely as possible, so, feedback very welcome! -- Eric -- konklone.com | @konklone --001a11c1af4c73e0ee04e8b95e82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I just wrote an extension for S= inatra, a popular Ruby-based microframework, that adds a Webfinger endpoint= for a given email address and set of metadata:

The idea here is to lower the barrier to adding a Webfi= nger endpoint for one's email, for people running Sinatra apps on their= domain (like me). I'm using this on my blog here.

It does a couple things I'd like your reaction to. = For one, it auto-decides whether data should be in "properties" o= r "links" based on whether the value is a URL. For two, it lets y= ou specify common short strings as keys, and does the mapping to a URI for = you, when there is one.

So this is the Ruby code:

webfinger "eric@konklone.com&quo=
t; =3D> {
  name: "Eric Mill=
",
  website: "https://konklone.com"
}
And this is what the endpoint wil= l produce:

{
  "subject"<=
span class=3D"">: &q=
uot;eric@konklone.com"=
,
  "properties": {
    "http://schema.org/name": "Eric Mill"=

  },
  "links": [
    {
      "rel"<=
span class=3D"">: &q=
uot;http://webfinger.net/=
rel/profile-page",
      "href"=
: &=
quot;https://konklone.com"
    }
  ]
}
I'm doing the mapping from fi= eld name to URI here:=A0https://github.com/konklone/sinatra-webfin= ger/blob/master/data/urns.yml=A0based on Will Norris' and Paul Jone= s' collections of URIs.

Next, I'd like to tackle an extension for Jekyll, a= nd a generator for a straight static file you can serve with a couple of li= nes in nginx/Apache/S3. I'll probably follow the approach I'm takin= g here in sinatra-webfinger as closely as possible, so, feedback very welco= me!

-- Eric

--
--001a11c1af4c73e0ee04e8b95e82-- From konklone@gmail.com Mon Oct 14 20:22:19 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975E421E814A for ; Mon, 14 Oct 2013 20:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2G7amt0Q6br for ; Mon, 14 Oct 2013 20:22:17 -0700 (PDT) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id F092421E8146 for ; Mon, 14 Oct 2013 20:22:16 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id c41so3738540eek.39 for ; Mon, 14 Oct 2013 20:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=fySr7fon0mtaCA59ORai/5FYFnifbi2KTNTaNpDpryQ=; b=bb5jkyX8dEtmmVxVuIF6m/3aIUhoqM6tAskFK7aFjJhavoB1s8cdCnNYRnCrP5W76f njUUag1kehVcotLNN+SZHS9iABfk5/NEaXA0mOMoFaKdmSMpGcKAvUXWW/t5vTk9pq9C yNFMWRiTvCr3yoeivX4o8t+KspZwGJ7RxAIQh+5QuM+DF0Rfdq0AF3d6ssEeRFYjNHxO 4y9awEEHCVmukvRQ9H+QMIEi1j2wboEuRKbMM9Z4EhHYSIbTFEfO0FlqjNsPx0owpyj+ tV6UJ4g9UJ5HnectJTjpDkHUnfX+wCVmMHQQLbA+SwQJth4OEQxuYKHPghJWLWFXarSI muug== X-Received: by 10.15.98.194 with SMTP id bj42mr62017498eeb.12.1381807334318; Mon, 14 Oct 2013 20:22:14 -0700 (PDT) MIME-Version: 1.0 Sender: konklone@gmail.com Received: by 10.223.167.69 with HTTP; Mon, 14 Oct 2013 20:21:33 -0700 (PDT) From: Eric Mill Date: Mon, 14 Oct 2013 23:21:33 -0400 X-Google-Sender-Auth: 94QPF3d08hEFe0pDGcYPGV_rim0 Message-ID: To: "webfinger@ietf.org" , webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=089e0160cd884f664204e8bf1738 Subject: [webfinger] Vision for Webfinger - what are we doing? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 03:22:19 -0000 --089e0160cd884f664204e8bf1738 Content-Type: text/plain; charset=ISO-8859-1 Hey all, I was at a hackathon today, and spent the day working on Webfinger libraries for Sinatraand Jekyll . It was really productive, but -- at the end of the day, a reporter was there asking everybody questions about their projects. When he asked what Webfinger was for, I realized that the original easy-to-communicate killer app for Webfinger, easing universal login through OpenID, was dead . The only thing I could think to say was "Remember OpenID? Before it died? Well, this is a piece of the puzzle to putting something like that back together again." That didn't feel like a very impressive answer. So, now that OpenID is dead, what's the one line explanation for why Webfinger is important? What's the path forward to making Webfinger something people are incentivized to support? Should we be pushing really hard to resuscitate OpenID via OpenID Connect? Do we just need to wait for internal lobbying inside of Google/Microsoft/Twitter/etc to pay off in some announcement? I know Webfinger supports more than email lookup -- is there some particular killer app people were envisioning when they lobbied for that feature? I'm so happy there's finally an RFC, after so many years. I recognize how much work was put in to make that happen, and this shouldn't be taken as a criticism of anyone. I just want to know what others see for the future of Webfinger, and what I should do next. -- Eric -- konklone.com | @konklone --089e0160cd884f664204e8bf1738 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey all,

I was at a hackathon=A0today, and spen= t the day working on Webfinger libraries for Sinatra and Jekyll. It was really productive, but -- at t= he end of the day, a reporter was there asking everybody questions about th= eir projects.=A0

When he asked what Webfinger was for, I realized that t= he original easy-to-communicate killer app for Webfinger, easing universal = login through OpenID, was dead. The only thing I could th= ink to say was "Remember OpenID? Before it died? Well, this is a piece= of the puzzle to putting something like that back together again."

That didn't feel like a very impressive answer= . So, now that OpenID is dead, what's the one line explanation for why = Webfinger is important? What's the path forward to making Webfinger som= ething people are incentivized to support?

Should we be pushing really hard to resuscitate OpenID = via OpenID Connect? Do we just need to wait for internal lobbying inside of= Google/Microsoft/Twitter/etc to pay off in some announcement? I know Webfi= nger supports more than email lookup -- is there some particular killer app= people were envisioning when they lobbied for that feature?

I'm so happy there's finally an RFC, after so m= any years. I recognize how much work was put in to make that happen, and th= is shouldn't be taken as a criticism of anyone. I just want to know wha= t others see for the future of Webfinger, and what I should do next.

-- Eric

--
--089e0160cd884f664204e8bf1738-- From bradfitz@google.com Tue Oct 15 10:32:47 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8D111E8183 for ; Tue, 15 Oct 2013 10:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPVVZWuwFnKK for ; Tue, 15 Oct 2013 10:32:45 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8957011E8116 for ; Tue, 15 Oct 2013 10:32:45 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id i4so2577709oah.18 for ; Tue, 15 Oct 2013 10:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GcNX5F7uutrBI7dWucvPWN0CDpC9WycM/o+HWQX5rq4=; b=A2JGJ8Jfx70Xp5zz3yHJ8NaKioaKBOr1C3sId/lboaBsiGz3QyZ+KBwY9NV0E0nIDz EHVsRtw1cIrd1zD8SMLw/Q1RhKRYQGD0M2iRVQstHBMQo/UbrWzIjAayHMj9Q6WjFo2z LGjAe986j/P9PPBVEnLqmzoafb5aBfJyItLOk2ACk5hzbcal+j3AtNcNnTfE6DVvLMUE YJ/QnOsVKdr7DG0m+kdCpeZCfEnY+oTsaKgvEqjxmHbMEiHwRF8pg9aMatV45JZSTpAZ Q5hEmWdDwQVOS1QnCEb7wbXtNJHzx1ybyv+gaFHqYc9CQdJJ/JyQrIjhUttA9sEstTSs 4h9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GcNX5F7uutrBI7dWucvPWN0CDpC9WycM/o+HWQX5rq4=; b=PdeN6I8j3y0Ct0GiIoKLWlL+Zd+TnsP+K1/4QeieNH2s80sSdwTb5yny0HdgRSMg6L 23wTF/h0bECEcIl5DeXFJEU2T3b9bzfcjGG/dAicbiSEBqmzlBNLnxq2lXzxPWK/dZGs HmXwbFWOUajflwKtM7wabln7iag/6ae0lJ1kTcuFomi67HRv/Kk2gvNrcqXv2VItfsDa EeDD/BmsdjFBMyu1XJn/8DK7v/g7hQOutEGMG+mGGDbHJYDXQeP5hH+3vGSCF1fvYHBh R6Uc/oVguTVKDuWrr2Gim2Yrpv3jXamir15pg6LSfv27G6aJgkC5zCFbM7uEgmmH4dCW a7cw== X-Gm-Message-State: ALoCoQlbPzK9i9JckgVTVR+E2RI7YOMGe0pH1TVKf1yMsVGjiLBfkt/WiiDD4hyXdcSFf1I6kEyoMH3UP0i2KMwAGM/fBgpsjSIWCoFTM45hdfa6xqvikb1hLhZbH3rlDqVegILHKkZpJJStIv3EAMuwMEKe6rEV3vneLQFhjtl/Ll4QkSwNqBXGV4WsXH6chbWzmJ5HWDa2 MIME-Version: 1.0 X-Received: by 10.182.18.9 with SMTP id s9mr28586327obd.15.1381858365067; Tue, 15 Oct 2013 10:32:45 -0700 (PDT) Received: by 10.182.39.36 with HTTP; Tue, 15 Oct 2013 10:32:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Oct 2013 10:32:45 -0700 Message-ID: From: Brad Fitzpatrick To: Eric Mill Content-Type: multipart/alternative; boundary=001a11c2d6a0faf6b904e8caf820 Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" Subject: Re: [webfinger] Vision for Webfinger - what are we doing? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:32:47 -0000 --001a11c2d6a0faf6b904e8caf820 Content-Type: text/plain; charset=UTF-8 Encrypted email: the MUA can discovery the user's public key before mailing, and encrypt it before it hits the first SMTP server. Sending money with bitcoin: discovery the receipient's public wallet address from their email address, or an endpoint to generate a wallet address as a function of the sender. etc It makes email addresses readable for any use case, instead of just SMTP-writable. On Mon, Oct 14, 2013 at 8:21 PM, Eric Mill wrote: > Hey all, > > I was at a hackathon today, > and spent the day working on Webfinger libraries for Sinatraand > Jekyll . It was really > productive, but -- at the end of the day, a reporter was there asking > everybody questions about their projects. > > When he asked what Webfinger was for, I realized that the original > easy-to-communicate killer app for Webfinger, easing universal login > through OpenID, was > dead . The only thing I could think to say was > "Remember OpenID? Before it died? Well, this is a piece of the puzzle to > putting something like that back together again." > > That didn't feel like a very impressive answer. So, now that OpenID is > dead, what's the one line explanation for why Webfinger is important? > What's the path forward to making Webfinger something people are > incentivized to support? > > Should we be pushing really hard to resuscitate OpenID via OpenID Connect? > Do we just need to wait for internal lobbying inside of > Google/Microsoft/Twitter/etc to pay off in some announcement? I know > Webfinger supports more than email lookup -- is there some particular > killer app people were envisioning when they lobbied for that feature? > > I'm so happy there's finally an RFC, after so many years. I recognize how > much work was put in to make that happen, and this shouldn't be taken as a > criticism of anyone. I just want to know what others see for the future of > Webfinger, and what I should do next. > > -- Eric > > -- > konklone.com | @konklone > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --001a11c2d6a0faf6b904e8caf820 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Encrypted email: the MUA can discovery the user's publ= ic key before mailing, and encrypt it before it hits the first SMTP server.=

Sending money with bitcoin: discovery the receipient= 9;s public wallet address from their email address, or an endpoint to gener= ate a wallet address as a function of the sender.

etc

It makes email addresses r= eadable for any use case, instead of just SMTP-writable.



On Mo= n, Oct 14, 2013 at 8:21 PM, Eric Mill <eric@konklone.com> wr= ote:
Hey all,

I was at a hackathon=C2=A0today, and spent the day working on We= bfinger libraries for Sinatra and Jekyll. It was really productive= , but -- at the end of the day, a reporter was there asking everybody quest= ions about their projects.=C2=A0

When he asked what Webfinger was for, I realized that t= he original easy-to-communicate killer app for Webfinger, easing universal = login through OpenID, was dead. The only thing I could think to say was "Remember OpenID? B= efore it died? Well, this is a piece of the puzzle to putting something lik= e that back together again."

That didn't feel like a very impressive answer= . So, now that OpenID is dead, what's the one line explanation for why = Webfinger is important? What's the path forward to making Webfinger som= ething people are incentivized to support?

Should we be pushing really hard to resuscitate OpenID = via OpenID Connect? Do we just need to wait for internal lobbying inside of= Google/Microsoft/Twitter/etc to pay off in some announcement? I know Webfi= nger supports more than email lookup -- is there some particular killer app= people were envisioning when they lobbied for that feature?

I'm so happy there's finally an RFC, after so m= any years. I recognize how much work was put in to make that happen, and th= is shouldn't be taken as a criticism of anyone. I just want to know wha= t others see for the future of Webfinger, and what I should do next.

-- Eric

--

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--001a11c2d6a0faf6b904e8caf820-- From paulej@packetizer.com Tue Oct 15 12:17:02 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE2611E8121 for ; Tue, 15 Oct 2013 12:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQRz61HBYquE for ; Tue, 15 Oct 2013 12:16:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7367411E8149 for ; Tue, 15 Oct 2013 12:16:56 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r9FJGtFi011496 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 15 Oct 2013 15:16:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1381864615; bh=CpH+D+binb3CAPtEmk7w3wMB2056JYbwuVODMCcF2js=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=eIgQEItiaWXCP1tWh5KWg9I86oBoPjVCG3iUId7OwAku57vH4537OjyEb2gTUFKyV mqhT8Y8CL5910RHE+/YaBEYjwIqXoKTdZ6CbPpEk1DYyATCW61s/isUgju3CXDf4lG nxu32cAwhZ1mzx7GndK2UsH50FJEL2FoGFfkmoF4= Message-ID: <525D94BB.5020206@packetizer.com> Date: Tue, 15 Oct 2013 15:17:15 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: webfinger@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070005010901000506080500" Subject: Re: [webfinger] Webfinger extension for Sinatra X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:17:02 -0000 This is a multi-part message in MIME format. --------------070005010901000506080500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cool! This looks like a simple way to map most information. Note that, while properties are defined as "strings", there is nothing illegal about putting a a URI inside. Just to avoid any possibility of error, might it be better to name properties like "name_property" or something? If the tag has _property at the end, then put it in properties. Paul On 10/14/2013 4:31 PM, Eric Mill wrote: > Hi all, > > I just wrote an extension for Sinatra, a popular Ruby-based > microframework, that adds a Webfinger endpoint for a given email > address and set of metadata: > https://github.com/konklone/sinatra-webfinger#a-webfinger-plugin-for-sinatra > > The idea here is to lower the barrier to adding a Webfinger endpoint > for one's email, for people running Sinatra apps on their domain (like > me). I'm using this on my blog here > . > > It does a couple things I'd like your reaction to. For one, it > auto-decides whether data should be in "properties" or "links" based > on whether the value is a URL. For two, it lets you specify common > short strings as keys, and does the mapping to a URI for you, when > there is one. > > So this is the Ruby code: > webfinger "eric@konklone.com " => { > name: "Eric Mill", > website: "https://konklone.com" > } > And this is what the endpoint will produce: > { > "subject": "eric@konklone.com ", > "properties": { > "http://schema.org/name": "Eric Mill" > }, > "links": [ > { > "rel": "http://webfinger.net/rel/profile-page", > "href": "https://konklone.com" > } > ] > } > I'm doing the mapping from field name to URI here: > https://github.com/konklone/sinatra-webfinger/blob/master/data/urns.yml based > on Will Norris' and Paul Jones' collections of URIs. > > Next, I'd like to tackle an extension for Jekyll, and a generator for > a straight static file you can serve with a couple of lines in > nginx/Apache/S3. I'll probably follow the approach I'm taking here in > sinatra-webfinger as closely as possible, so, feedback very welcome! > > -- Eric > > -- > konklone.com | @konklone > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --------------070005010901000506080500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cool! This looks like a simple way to map most information.  Note that, while properties are defined as "strings", there is nothing illegal about putting a a URI inside.  Just to avoid any possibility of error, might it be better to name properties like "name_property" or something?  If the tag has _property at the end, then put it in properties.

Paul

On 10/14/2013 4:31 PM, Eric Mill wrote:
Hi all,

I just wrote an extension for Sinatra, a popular Ruby-based microframework, that adds a Webfinger endpoint for a given email address and set of metadata:

The idea here is to lower the barrier to adding a Webfinger endpoint for one's email, for people running Sinatra apps on their domain (like me). I'm using this on my blog here.

It does a couple things I'd like your reaction to. For one, it auto-decides whether data should be in "properties" or "links" based on whether the value is a URL. For two, it lets you specify common short strings as keys, and does the mapping to a URI for you, when there is one.

So this is the Ruby code:
webfinger "eric@konklone.com" => {
  name: "Eric Mill",
  website: "https://konklone.com"
}
And this is what the endpoint will produce:
{
  "subject": "eric@konklone.com",
  "properties": {
    "http://schema.org/name": "Eric Mill"
  },
  "links": [
    {
      "rel": "http://webfinger.net/rel/profile-page",
      "href": "https://konklone.com"
    }
  ]
}
I'm doing the mapping from field name to URI here: https://github.com/konklone/sinatra-webfinger/blob/master/data/urns.yml based on Will Norris' and Paul Jones' collections of URIs.

Next, I'd like to tackle an extension for Jekyll, and a generator for a straight static file you can serve with a couple of lines in nginx/Apache/S3. I'll probably follow the approach I'm taking here in sinatra-webfinger as closely as possible, so, feedback very welcome!

-- Eric

-- 


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--------------070005010901000506080500-- From paulej@packetizer.com Tue Oct 15 12:23:41 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0A511E819F for ; Tue, 15 Oct 2013 12:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljn-DOmcSomd for ; Tue, 15 Oct 2013 12:23:36 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBE311E8166 for ; Tue, 15 Oct 2013 12:23:36 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r9FJNURe011994 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 15 Oct 2013 15:23:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1381865016; bh=bKesfjbc9vY7TiBJL5MEQS7rM3DTX13XPx7MEvhroaY=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=ZDOOR6F6r9T2waILAvv3C3KMRnGDsAV0lewJIMZ9LFNu++7xPyfbvmBdXO01AAtlc OR70nT5XlqiwVaZKN4t/Iz1JB1xo8oEHWeu22SIgX8WPRKv+aNxkN7qxHtQ4Z6dlY/ o9/4QitUG8uFkR6aZ2Ea+e5dUxHB8kApajr1jeI8= Message-ID: <525D9646.7010306@packetizer.com> Date: Tue, 15 Oct 2013 15:23:50 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: webfinger@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010706060701040902020201" Subject: Re: [webfinger] Vision for Webfinger - what are we doing? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:23:41 -0000 This is a multi-part message in MIME format. --------------010706060701040902020201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric, OpenID is not entirely dead, yet. I still run my own OpenID OP server and use it to log into some sites. I still allow OpenID logins on forums.packetizer.com, too. It's still in use, but the large sites just didn't have enough users using it, so they axed it. On its heels, though, is now OpenID Connect and it will use WebFinger for discovery. so, sure... push it :-) Personally, I can think of a lot of good uses for WebFinger: * When I log onto a web site, I want the site to grab my name an picture automatically. * If I want somebody to send me bitcoins, I'd much rather give them my email address (and I do have that in my WF account) * My contact info is published via WebFinger, so I don't have to give people a lot of info on a business card * WebFinger will hopefully be used as the starting point for auto-provisioning of email clients or other devices and applications where one has to enter server and port information Paul On 10/14/2013 11:21 PM, Eric Mill wrote: > Hey all, > > I was at a hackathon > today, and spent > the day working on Webfinger libraries for Sinatra > and Jekyll > . It was really > productive, but -- at the end of the day, a reporter was there asking > everybody questions about their projects. > > When he asked what Webfinger was for, I realized that the original > easy-to-communicate killer app for Webfinger, easing universal login > through OpenID, was > > dead . The only thing I could think to say > was "Remember OpenID? Before it died? Well, this is a piece of the > puzzle to putting something like that back together again." > > That didn't feel like a very impressive answer. So, now that OpenID is > dead, what's the one line explanation for why Webfinger is important? > What's the path forward to making Webfinger something people are > incentivized to support? > > Should we be pushing really hard to resuscitate OpenID via OpenID > Connect? Do we just need to wait for internal lobbying inside of > Google/Microsoft/Twitter/etc to pay off in some announcement? I know > Webfinger supports more than email lookup -- is there some particular > killer app people were envisioning when they lobbied for that feature? > > I'm so happy there's finally an RFC, after so many years. I recognize > how much work was put in to make that happen, and this shouldn't be > taken as a criticism of anyone. I just want to know what others see > for the future of Webfinger, and what I should do next. > > -- Eric > > -- > konklone.com | @konklone > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --------------010706060701040902020201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eric,

OpenID is not entirely dead, yet.  I still run my own OpenID OP server and use it to log into some sites.  I still allow OpenID logins on forums.packetizer.com, too.  It's still in use, but the large sites just didn't have enough users using it, so they axed it.  On its heels, though, is now OpenID Connect and it will use WebFinger for discovery.  so, sure... push it :-)

Personally, I can think of a lot of good uses for WebFinger:
* When I log onto a web site, I want the site to grab my name an picture automatically.
* If I want somebody to send me bitcoins, I'd much rather give them my email address (and I do have that in my WF account)
* My contact info is published via WebFinger, so I don't have to give people a lot of info on a business card
* WebFinger will hopefully be used as the starting point for auto-provisioning of email clients or other devices and applications where one has to enter server and port information

Paul

On 10/14/2013 11:21 PM, Eric Mill wrote:
Hey all,

I was at a hackathon today, and spent the day working on Webfinger libraries for Sinatra and Jekyll. It was really productive, but -- at the end of the day, a reporter was there asking everybody questions about their projects. 

When he asked what Webfinger was for, I realized that the original easy-to-communicate killer app for Webfinger, easing universal login through OpenID, was dead. The only thing I could think to say was "Remember OpenID? Before it died? Well, this is a piece of the puzzle to putting something like that back together again."

That didn't feel like a very impressive answer. So, now that OpenID is dead, what's the one line explanation for why Webfinger is important? What's the path forward to making Webfinger something people are incentivized to support?

Should we be pushing really hard to resuscitate OpenID via OpenID Connect? Do we just need to wait for internal lobbying inside of Google/Microsoft/Twitter/etc to pay off in some announcement? I know Webfinger supports more than email lookup -- is there some particular killer app people were envisioning when they lobbied for that feature?

I'm so happy there's finally an RFC, after so many years. I recognize how much work was put in to make that happen, and this shouldn't be taken as a criticism of anyone. I just want to know what others see for the future of Webfinger, and what I should do next.

-- Eric

-- 


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--------------010706060701040902020201-- From konklone@gmail.com Tue Oct 15 12:44:53 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D58011E8186 for ; Tue, 15 Oct 2013 12:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLmAijzSi2Z3 for ; Tue, 15 Oct 2013 12:44:52 -0700 (PDT) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB3211E81E9 for ; Tue, 15 Oct 2013 12:44:43 -0700 (PDT) Received: by mail-ea0-f180.google.com with SMTP id h10so4230306eaj.11 for ; Tue, 15 Oct 2013 12:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=kw++x+RNRHRkdN08Rd3cASl5CZLEueXQAPWg9Jq0JWA=; b=X/41we6XvLnVc+BX43ZIFUjWedg8Y7M0YbLSgkv0DlGP6mx2930qIbUSY18vW628Ap F85X7e7RiPrIGeyZsv2Ke0ItVAnGaiitCSXUo71L2ORnXknui51A5RreaaEjlV/zlMTf fjkaU+IhjQGZfTm1fd7t9QO/8q4ED3ihOD1IrCt1ca6sNloNM+s7P7lThQ27a5UYpyc4 dCaswBcwvLjhzALq5l8BmFv+hHXUOuOPf5hJ6ncIQQwTYe2LrvneAzcCjhtZ0PFdF6wm N9aYWTxF+Aub0gTQA0dSERR9RS7SIaqayoNpGx1RX8UYqGqtnNFya1JU/sIGBytX/wni 5zXg== X-Received: by 10.14.4.1 with SMTP id 1mr3192873eei.21.1381866283026; Tue, 15 Oct 2013 12:44:43 -0700 (PDT) MIME-Version: 1.0 Sender: konklone@gmail.com Received: by 10.223.167.69 with HTTP; Tue, 15 Oct 2013 12:44:02 -0700 (PDT) In-Reply-To: <525D94BB.5020206@packetizer.com> References: <525D94BB.5020206@packetizer.com> From: Eric Mill Date: Tue, 15 Oct 2013 15:44:02 -0400 X-Google-Sender-Auth: UhzmN_BUWCzIhA5kdKQArRZEwao Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=047d7b66f285ed4fdd04e8ccd04f Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Webfinger extension for Sinatra X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:44:53 -0000 --047d7b66f285ed4fdd04e8ccd04f Content-Type: text/plain; charset=ISO-8859-1 Yeah, I could add an override option to force the key into one bucket or another - I added a ticket for it and sketched out what the syntax might look like. On Tue, Oct 15, 2013 at 3:17 PM, Paul E. Jones wrote: > Cool! This looks like a simple way to map most information. Note that, > while properties are defined as "strings", there is nothing illegal about > putting a a URI inside. Just to avoid any possibility of error, might it > be better to name properties like "name_property" or something? If the tag > has _property at the end, then put it in properties. > > Paul > > > On 10/14/2013 4:31 PM, Eric Mill wrote: > > Hi all, > > I just wrote an extension for Sinatra, a popular Ruby-based > microframework, that adds a Webfinger endpoint for a given email address > and set of metadata: > > https://github.com/konklone/sinatra-webfinger#a-webfinger-plugin-for-sinatra > > The idea here is to lower the barrier to adding a Webfinger endpoint for > one's email, for people running Sinatra apps on their domain (like me). I'm > using this on my blog here > . > > It does a couple things I'd like your reaction to. For one, it > auto-decides whether data should be in "properties" or "links" based on > whether the value is a URL. For two, it lets you specify common short > strings as keys, and does the mapping to a URI for you, when there is one. > > So this is the Ruby code: > > webfinger "eric@konklone.com" => { > name: "Eric Mill", > website: "https://konklone.com"} > > And this is what the endpoint will produce: > > { > "subject": "eric@konklone.com", > "properties": { > "http://schema.org/name": "Eric Mill" > }, > "links": [ > { > "rel": "http://webfinger.net/rel/profile-page", > "href": "https://konklone.com" > } > ]} > > I'm doing the mapping from field name to URI here: > https://github.com/konklone/sinatra-webfinger/blob/master/data/urns.yml based > on Will Norris' and Paul Jones' collections of URIs. > > Next, I'd like to tackle an extension for Jekyll, and a generator for a > straight static file you can serve with a couple of lines in > nginx/Apache/S3. I'll probably follow the approach I'm taking here in > sinatra-webfinger as closely as possible, so, feedback very welcome! > > -- Eric > > -- > konklone.com | @konklone > > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > -- konklone.com | @konklone --047d7b66f285ed4fdd04e8ccd04f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, I could add an override option to force the key into= one bucket or another - I added a ticket=A0for it and sketched out what the s= yntax might look like.


On Tue, Oct 1= 5, 2013 at 3:17 PM, Paul E. Jones <paulej@packetizer.com> wrote:
=20 =20 =20
Cool! This looks like a simple way to map most information.=A0 Note that, while properties are defined as "strings", there is not= hing illegal about putting a a URI inside.=A0 Just to avoid any possibility of error, might it be better to name properties like "name_propert= y" or something?=A0 If the tag has _property at the end, then put it in properties.

Paul


On 10/14/2013 4:31 PM, Eric Mill wrote:
Hi all,

I just wrote an extension for Sinatra, a popular Ruby-based microframework, that adds a Webfinger endpoint for a given email address and set of metadata:

The idea here is to lower the barrier to adding a Webfinger endpoint for one's email, for people running Sinatra apps on their domain (like me). I'm using this on my blog here.

It does a couple things I'd like your reaction to. For one= , it auto-decides whether data should be in "properties" = or "links" based on whether the value is a URL. For two, i= t lets you specify common short strings as keys, and does the mapping to a URI for you, when there is one.

So this is the Ruby code:

webfinger "eric@konklone.com"=
 =3D> {
  name: "Eric Mill",
  website: "https://konklone.com"
}
And this is what the endpoint will produce:

{
  "subject": "eric@konklone.com",
  "properties": {
    "http://schema.org/name": "Eric Mill"
  },
  "links":=
 [
    {
      "rel": "http://webfinger.net/rel/profile-pag=
e",
      "href": "https://konklone.com"
    }
  ]
}
I'm doing the mapping from field name to URI here:=A0https://github.com/konklone/sinatra-webfinger/blob/ma= ster/data/urns.yml=A0based on Will Norris' and Paul Jones' collections of URIs.

Next, I'd like to tackle an extension for Jekyll, and a generator for a straight static file you can serve with a couple of lines in nginx/Apache/S3. I'll probably follow the approach I'm taking here in sinatra-webfinger as closely as possible, so, feedback very welcome!

-- Eric

-- 


_______________________________________________
webfinger mailing list
webfinger@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/webfinger


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger




--
--047d7b66f285ed4fdd04e8ccd04f-- From kidehen@openlinksw.com Tue Oct 15 12:48:26 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C0411E820A for ; Tue, 15 Oct 2013 12:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwqtf1CGBGkR for ; Tue, 15 Oct 2013 12:48:23 -0700 (PDT) Received: from mail.openlinksw.com (mail.openlinksw.com [63.119.36.38]) by ietfa.amsl.com (Postfix) with ESMTP id 9A19E11E8186 for ; Tue, 15 Oct 2013 12:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openlinksw.com; s=x; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=lEpfg3sL234Ui6W1Y1MLtQntJ8r/fNtYa58zGLK553s=; b=IChJ76Xu/gRsTzqgepmHIh1oPeHhI77tFCSk+ZGIhW/UZBFTMuQCLPuFyDg1sBBaSiGrd0iOWbt78ckogeSnkekvidHVcTRDG+KOgA/qz5T25C/3YgmViK/MvOXTt32q; Received: from dyn226.usnet.private ([192.168.11.226]) by mail.openlinksw.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1VWAbJ-0004ej-Tp for webfinger@ietf.org; Tue, 15 Oct 2013 15:48:17 -0400 Message-ID: <525D9C01.9010102@openlinksw.com> Date: Tue, 15 Oct 2013 15:48:17 -0400 From: Kingsley Idehen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: webfinger@ietf.org References: <525D9646.7010306@packetizer.com> In-Reply-To: <525D9646.7010306@packetizer.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090901080101000901040404" Subject: Re: [webfinger] Vision for Webfinger - what are we doing? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:48:27 -0000 This is a cryptographically signed message in MIME format. --------------ms090901080101000901040404 Content-Type: multipart/alternative; boundary="------------090607040101090105080608" This is a multi-part message in MIME format. --------------090607040101090105080608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/15/13 3:23 PM, Paul E. Jones wrote: > Eric, > > OpenID is not entirely dead, yet. I still run my own OpenID OP server = > and use it to log into some sites. I still allow OpenID logins on=20 > forums.packetizer.com, too. It's still in use, but the large sites=20 > just didn't have enough users using it, so they axed it. On its=20 > heels, though, is now OpenID Connect and it will use WebFinger for=20 > discovery. so, sure... push it :-) > > Personally, I can think of a lot of good uses for WebFinger: > * When I log onto a web site, I want the site to grab my name an=20 > picture automatically. > * If I want somebody to send me bitcoins, I'd much rather give them my = > email address (and I do have that in my WF account) > * My contact info is published via WebFinger, so I don't have to give=20 > people a lot of info on a business card > * WebFinger will hopefully be used as the starting point for=20 > auto-provisioning of email clients or other devices and applications=20 > where one has to enter server and port information > > Paul All, Here's a simple and useful thing that can be achieved with Webfinger: You notarize digital identity cards (aka. X.509 certificates) where an=20 acct: scheme URI in the certificate's SAN (Subject Alternative Name)=20 enables X.509 based verifiable identity beyond Email oriented S/MIME. It = also means you can construct sophisticated ACLs and Data Access Policies = for a Global Read-Write Web. We have just released version 1.3.0 of our YouID app for iOS that=20 supports what I've outlined above. This product has actually supported=20 Webfinger since its inception. What we would liked to have been able to=20 add for acct: URIs and Webfinger lookups is the ability for anyone to=20 host their profile document via services such as Dropbox, Google Drive,=20 SkyDrive, Box. etc., which is what's achieved via http: scheme URIs. Links: 1. http://youid.openlinksw.com -- home page 2. http://bit.ly/19McSik -- G+ note about the 1.3.0 release. Kingsley > > On 10/14/2013 11:21 PM, Eric Mill wrote: >> Hey all, >> >> I was at a hackathon=20 >> today, and spent = >> the day working on Webfinger libraries for Sinatra=20 >> and Jekyll=20 >> . It was really=20 >> productive, but -- at the end of the day, a reporter was there asking = >> everybody questions about their projects. >> >> When he asked what Webfinger was for, I realized that the original=20 >> easy-to-communicate killer app for Webfinger, easing universal login=20 >> through OpenID, was=20 >> =20 >> dead . The only thing I could think to say = >> was "Remember OpenID? Before it died? Well, this is a piece of the=20 >> puzzle to putting something like that back together again." >> >> That didn't feel like a very impressive answer. So, now that OpenID=20 >> is dead, what's the one line explanation for why Webfinger is=20 >> important? What's the path forward to making Webfinger something=20 >> people are incentivized to support? >> >> Should we be pushing really hard to resuscitate OpenID via OpenID=20 >> Connect? Do we just need to wait for internal lobbying inside of=20 >> Google/Microsoft/Twitter/etc to pay off in some announcement? I know=20 >> Webfinger supports more than email lookup -- is there some particular = >> killer app people were envisioning when they lobbied for that feature?= >> >> I'm so happy there's finally an RFC, after so many years. I recognize = >> how much work was put in to make that happen, and this shouldn't be=20 >> taken as a criticism of anyone. I just want to know what others see=20 >> for the future of Webfinger, and what I should do next. >> >> -- Eric >> >> --=20 >> konklone.com | @konklone=20 >> >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --=20 Regards, Kingsley Idehen=09 Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen --------------090607040101090105080608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 10/15/13 3:23 PM, Paul E. Jones wrote:
Eric,

OpenID is not entirely dead, yet.  I still run my own OpenID O= P server and use it to log into some sites.  I still allow OpenI= D logins on forums.packetizer.com, too.  It's still in use, but = the large sites just didn't have enough users using it, so they axed it.  On its heels, though, is now OpenID Connect and it will u= se WebFinger for discovery.  so, sure... push it :-)

Personally, I can think of a lot of good uses for WebFinger:
* When I log onto a web site, I want the site to grab my name an picture automatically.
* If I want somebody to send me bitcoins, I'd much rather give them my email address (and I do have that in my WF account)
* My contact info is published via WebFinger, so I don't have to give people a lot of info on a business card
* WebFinger will hopefully be used as the starting point for auto-provisioning of email clients or other devices and applications where one has to enter server and port information
=
Paul

All,

Here's a simple and useful thing that can be achieved with Webfinger:

You notarize digital identity cards (aka. X.509 certificates) where an acct: scheme URI in the certificate's SAN (Subject Alternative Name) enables X.509 based verifiable identity beyond Email oriented S/MIME. It also means you can construct sophisticated ACLs and Data Access Policies for a Global Read-Write Web.

We have just released version 1.3.0 of our YouID app for iOS that supports what I've outlined above. This product has actually supported Webfinger since its inception. What we would liked to have been able to add for acct: URIs and Webfinger lookups is the ability for anyone to host their profile document via services such as Dropbox, Google Drive, SkyDrive, Box. etc., which is what's achieved via http: scheme URIs.

Links:

1. http://youid.openlinksw.com -- home page
2. = http://bit.ly/19McSik -- G+ note about the 1.3.0 release.

Kingsley


On 10/14/2013 11:21 PM, Eric Mill wrote:
Hey all,

I was at a hackathon today, and spent the day working on Webfinger libraries for Sina= tra and Jekyl= l. It was really productive, but -- at the end of the day, a reporter was there asking everybody questions about their projects. 

When he asked what Webfinger was for, I realized that the original easy-to-communicate killer app for Webfinger, easing universal login through OpenID, was dead. The only thing I could think to say was "Remember OpenID? Before it died? Well, this is a piece of the puzzle to putting something like that back together again."

That didn't feel like a very impressive answer. So, now that OpenID is dead, what's the one line explanation for why Webfinger is important? What's the path forward to making Webfinger something people are incentivized to support?

Should we be pushing really hard to resuscitate OpenID via OpenID Connect? Do we just need to wait for internal lobbying inside of Google/Microsoft/Twitter/etc to pay off in some announcement? I know Webfinger supports more than email lookup -- is there some particular killer app people were envisioning when they lobbied for that feature?

I'm so happy there's finally an RFC, after so many years. I recognize how much work was put in to make that happen, and this shouldn't be taken as a criticism of anyone. I just want to know what others see for the future of Webfinger, and what I should do next.

-- Eric

-- 


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/=
listinfo/webfinger




_______________________________________________
webfinger mailing list
=
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



--=20

Regards,

Kingsley Idehen	     =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767=
740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
--------------090607040101090105080608-- --------------ms090901080101000901040404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEtTCC BLEwggOZoAMCAQICAgYRMA0GCSqGSIb3DQEBDQUAMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNv ZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZTAeFw0xMzEwMDEy MDA4NDNaFw0xMzEwMzEyMDA4NDNaMH4xHDAaBgNVBAMUE0BraWRlaGVuIChMaW5rZWRJbikx HTAbBgNVBAoTFFBlcnNvbmFsIERhdGEgU3BhY2UgMQswCQYDVQQGEwJVUzELMAkGA1UECBMC TUExJTAjBgkqhkiG9w0BCQEWFmtpZGVoZW5Ab3Blbmxpbmtzdy5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCgJjN1Vxir8JqQPULDoKLzVrF2ysXT+esccgHmqC5pgHIV sgE3DXOoHh9ANI4WQ75QJF+ZZBSSgwraf4wwtWBaWApb3tQCipcluLYFgBXeoHDwnKA70cPD HoDa5Ijs/1e1EzriEi7FwIn3X9MPOTMWpYAfzm4wD5Tdod3lsiWXzo5EJa8mITyqOkNkuLyZ ZQx6pHFMctby3+7bZZkIEa9SmNamRyQAYpY7TfnTHbL25AMCsnIs2QQvQtYyrd/Y97af4/yL /dJdMQcgQ/SIz1rLDIx+vSmKnq2lhCGLIvt+HzvvQE2UnDwW4ORfuGUPRN+F/EzrP+VlsXv5 74gNB9q9AgMBAAGjggF0MIIBcDAdBgNVHQ4EFgQU6O4BGpchUYb4mfp+6Q88Mr1WupMwbAYD VR0RBGUwY4ZJaHR0cDovL2lkLm15b3BlbmxpbmsubmV0L2Fib3V0L2lkL2VudGl0eS9odHRw L3d3dy5saW5rZWRpbi5jb20vaW4va2lkZWhlboEWa2lkZWhlbkBvcGVubGlua3N3LmNvbTA+ BgNVHRIENzA1hjNodHRwOi8vaWQubXlvcGVubGluay5uZXQvaXNzdWVyL2tleS9kYmEvaWRf cnNhI3RoaXMwNgYJYIZIAYb4QgENBCkWJ0NlcnRpZmljYXRlIEdlbmVyYXRlZCBieSBPcGVu TGluayBZb3VJRDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwNwYIYIZIAbaf SQEEKxYpaHR0cDovL2lkLm15b3BlbmxpbmsubmV0L2NlcnRnZW4va2V5Lzk4NzgwDgYDVR0P AQH/BAQDAgWgMA0GCSqGSIb3DQEBDQUAA4IBAQAVCV8iBywpe8sCzleVJI+euKU4c1Wa/6Bh A/JO4S5TT+iVIHSK1I9BrBHPC0nO9AFN738h2i3kEMtPnHTgSwot2MuceJMYEwrxTalAc1bb gJ+7IQughgtTMnjPLPBU2a/gUI2DHeTYK8sFyfQgqOSmed9bvqT8F5s8eNd7Q9liiMC7T0vf uYUYXMOWracYvVHCS77TUHhKD/sd/owpE6q9MUrpqOKU+PvH549KYhQFIt+8ESgsnBOfa/G1 wIO/TaZxt0JqX+qIg0SCJxiWO64Yfz1ALNQlcGch9gEpHEKrwUTvf/QIR2u7Db5IdXv/Eb29 pNbShthpjHTMyVL+e9fvMYIC7zCCAusCAQEwRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0 d2FyZSBMb2NhbCBDQTEaMBgGA1UECgwRT3BlbkxpbmsgU29mdHdhcmUCAgYRMAkGBSsOAwIa BQCgggF9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTAx NTE5NDgxN1owIwYJKoZIhvcNAQkEMRYEFDZXDfQu7xmNF63sKU/rGbdKeqloMFYGCSsGAQQB gjcQBDFJMEcwQTEjMCEGA1UEAwwaT3BlbkxpbmsgU29mdHdhcmUgTG9jYWwgQ0ExGjAYBgNV BAoMEU9wZW5MaW5rIFNvZnR3YXJlAgIGETBYBgsqhkiG9w0BCRACCzFJoEcwQTEjMCEGA1UE AwwaT3BlbkxpbmsgU29mdHdhcmUgTG9jYWwgQ0ExGjAYBgNVBAoMEU9wZW5MaW5rIFNvZnR3 YXJlAgIGETBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAH+Yjjp3IEMZtoHpumfejmFFPzkHfjZRDW5h 1Q0hPzElFVAWZKRi3904Na1QiFL5hmInRBAcbq0k7+5g8gohlcamoZ/RCdRsgYT1U80ps8UV oEi+74TtQyXgz2AVJOme+Na6Unx4pu/ujbobDqPA5xW1TDJ0JNzH7b7Je+jpTmff7bn+/rnI sJJcGsf2ymE4bN878Kytjd7L2wdxhdZ0PTCDWErvzgECq7b/cxGZoJ9wWemxMEnR07Q9O9i0 p+K8lANISwcwCTMzPWTv9uFMrvya7Zwh8p/Qa4UdJpNsbnk4hHwPrSe6yCs9LTD7bNvHsHuJ idbcQm6pIyB3QVkABvsAAAAAAAA= --------------ms090901080101000901040404-- From melvincarvalho@gmail.com Wed Oct 16 04:28:25 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D874911E81AD for ; Wed, 16 Oct 2013 04:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpAGZiu+8LKl for ; Wed, 16 Oct 2013 04:28:24 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAAD11E81BB for ; Wed, 16 Oct 2013 04:28:21 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id eh20so443329lab.5 for ; Wed, 16 Oct 2013 04:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2ZPvg8jGde5voTaIFkpaP+ZgMaY2yme5/P+HjHeMEvA=; b=YFodlW3iREox4MGZ07ROogJKwIsLhwWEK8+CchwNIqXHNQwz8J1M2Cuu+glyLydVqS 7+okdPof6CLXHyZSrQDino8jTOR4WTan0ttcoRPh1ES/tpJzItGdq0oOsYNchZURrFBg fRAwmJWnCEPy5t8AouII4cbBmyV59vQLh1KreP0A2TP4aJ8rE1TZh5QCC1Tk3odmHgGC OiVYmXsE1r61M6NPxcTo6rK78OfG6Rs0EgU0gowyn8WXmktG6fhMFt046sbwZwqjZHY9 aH45ViffDBPM9yOYXwFD8jHGShZ0PHsBFLdQmFahdQ40n/l3ei2S4NEQysqMvEnyIp2P 8Ruw== MIME-Version: 1.0 X-Received: by 10.152.6.169 with SMTP id c9mr2058589laa.28.1381922900871; Wed, 16 Oct 2013 04:28:20 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Wed, 16 Oct 2013 04:28:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Oct 2013 13:28:20 +0200 Message-ID: From: Melvin Carvalho To: Eric Mill Content-Type: multipart/alternative; boundary=089e01493c069d0e3a04e8d9ffa1 Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" Subject: Re: [webfinger] Vision for Webfinger - what are we doing? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 11:28:26 -0000 --089e01493c069d0e3a04e8d9ffa1 Content-Type: text/plain; charset=ISO-8859-1 On 15 October 2013 05:21, Eric Mill wrote: > Hey all, > > I was at a hackathon today, > and spent the day working on Webfinger libraries for Sinatraand > Jekyll . It was really > productive, but -- at the end of the day, a reporter was there asking > everybody questions about their projects. > > When he asked what Webfinger was for, I realized that the original > easy-to-communicate killer app for Webfinger, easing universal login > through OpenID, was > dead . The only thing I could think to say was > "Remember OpenID? Before it died? Well, this is a piece of the puzzle to > putting something like that back together again." > > That didn't feel like a very impressive answer. So, now that OpenID is > dead, what's the one line explanation for why Webfinger is important? > What's the path forward to making Webfinger something people are > incentivized to support? > > Should we be pushing really hard to resuscitate OpenID via OpenID Connect? > Do we just need to wait for internal lobbying inside of > Google/Microsoft/Twitter/etc to pay off in some announcement? I know > Webfinger supports more than email lookup -- is there some particular > killer app people were envisioning when they lobbied for that feature? > > I'm so happy there's finally an RFC, after so many years. I recognize how > much work was put in to make that happen, and this shouldn't be taken as a > criticism of anyone. I just want to know what others see for the future of > Webfinger, and what I should do next. > When Brad created the great grand father of OpenID, codename Yadis, it actually had a web based discovery system called FOAF. Even though FOAF got to a certain degree of popularity (several million users) users there was a point in time when it became less popular. We dont really know the reason for this, but people say that the XML serialization was unwieldy, there was a lot of complexity baked in (e.g. OWL) and there was no standardization of privacy. Whatever the reason, it simply fell out of fashion, particularly on the west coast, and a new system, XRD was created as a rival. In truth XRD and FOAF data models (RDF) were very similar (both follow the subject / property / value model), but they were developed independently. XRD became the basis of both OpenID and Webfinger. Both FOAF and XRD now have JSON serializations which is where we get today's JRD, which I think many developers prefer. Webfinger was originally conceived to get an XRD/JRD for an email address, but somewhere along the way, with multiple authors it become more generic as a general purpose discovery system, much like the technology behind FOAF. In fact today the email use case (mailto:) is no longer is part of the core, and we have discovery on the new URI scheme acct: which Eran put in before he left. There's many theories on why acct: was invented, but imho, it's because Eran worked out that an email address is the OBJECT of a data structure and not the SUBJECT, so we were missing a subject. Since XRD has no query language, a term to create a subject needed to be created. Hence we have acct: The 5 years of discussion of webfinger mirror quite closely the first 5 years of discussion RDF (aka the semantic web aka web of data aka Linked Data). The path towards a model where you have entities as URIs and key value pairs linked to them seems quite similar. However, as of today, the world is slightly split by two systems that do more or less the same thing. Sadly, they are not 100% compatible with each other at this time, RDF is a more powerful version of XRD, and I would say probably has more people developing it and adoption, particularly at enterprise level. Things have move slightly closer together over time, and maybe the dream one day is to have a giant web based discovery system with webfinger being one important aspect, particularly for finding information on email addresses. We'll have to wait and see! > > -- Eric > > -- > konklone.com | @konklone > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --089e01493c069d0e3a04e8d9ffa1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 15 October 2013 05:21, Eric Mill <eric@konklone.com> wrote:
Hey all,

I was at a hackathon=A0today, and spent the day working on Webfi= nger libraries for Sinatra and Jekyll. It was really productive, b= ut -- at the end of the day, a reporter was there asking everybody question= s about their projects.=A0

When he asked what Webfinger was for, I realized that t= he original easy-to-communicate killer app for Webfinger, easing universal = login through OpenID, was dead. The only thing I could think to say was "Remember OpenID? B= efore it died? Well, this is a piece of the puzzle to putting something lik= e that back together again."

That didn't feel like a very impressive answer= . So, now that OpenID is dead, what's the one line explanation for why = Webfinger is important? What's the path forward to making Webfinger som= ething people are incentivized to support?

Should we be pushing really hard to resuscitate OpenID = via OpenID Connect? Do we just need to wait for internal lobbying inside of= Google/Microsoft/Twitter/etc to pay off in some announcement? I know Webfi= nger supports more than email lookup -- is there some particular killer app= people were envisioning when they lobbied for that feature?

I'm so happy there's finally an RFC, after so m= any years. I recognize how much work was put in to make that happen, and th= is shouldn't be taken as a criticism of anyone. I just want to know wha= t others see for the future of Webfinger, and what I should do next.

When Brad created the gr= eat grand father of OpenID, codename Yadis, it actually had a web based dis= covery system called FOAF.=A0 Even though FOAF got to a certain degree of p= opularity (several million users) users there was a point in time when it b= ecame less popular.=A0 We dont really know the reason for this, but people = say that the XML serialization was unwieldy, there was a lot of complexity = baked in (e.g. OWL) and there was no standardization of privacy.

Whatever the reason, it simply fell out of fashion, particul= arly on the west coast, and a new system, XRD was created as a rival.=A0 In= truth XRD and FOAF data models (RDF) were very similar (both follow the su= bject / property / value model), but they were developed independently.=A0 = XRD became the basis of both OpenID and Webfinger.=A0 Both FOAF and XRD now= have JSON serializations which is where we get today's JRD, which I th= ink many developers prefer.

Webfinger was originally conceived to get an XRD/JRD for an = email address, but somewhere along the way, with multiple authors it become= more generic as a general purpose discovery system, much like the technolo= gy behind FOAF.=A0 In fact today the email use case (mailto:) is no longer = is part of the core, and we have discovery on the new URI scheme acct: whic= h Eran put in before he left.=A0 There's many theories on why acct: was= invented, but imho, it's because Eran worked out that an email address= is the OBJECT of a data structure and not the SUBJECT, so we were missing = a subject.=A0 Since XRD has no query language, a term to create a subject n= eeded to be created.=A0 Hence we have acct:

The 5 years of discussion of webfinger mirror quite closely = the first 5 years of discussion RDF (aka the semantic web aka web of data a= ka Linked Data).=A0 The path towards a model where you have entities as URI= s and key value pairs linked to them seems quite similar.

However, as of today, the world is slightly split by two sys= tems that do more or less the same thing.=A0 Sadly, they are not 100% compa= tible with each other at this time, RDF is a more powerful version of XRD, = and I would say probably has more people developing it and adoption, partic= ularly at enterprise level.

Things have move slightly closer together over time, and may= be the dream one day is to have a giant web based discovery system with web= finger being one important aspect, particularly for finding information on = email addresses.=A0 We'll have to wait and see!
=A0

-- Eric

--

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--089e01493c069d0e3a04e8d9ffa1-- From konklone@gmail.com Wed Oct 16 08:39:08 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E20811E8306 for ; Wed, 16 Oct 2013 08:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsN5Kzj2Y0vb for ; Wed, 16 Oct 2013 08:39:07 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DC67B21F9D2A for ; Wed, 16 Oct 2013 08:38:58 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id b47so455762eek.31 for ; Wed, 16 Oct 2013 08:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=N16sxGc/j/9L+xrW5aoArCvqpM8TZkxmcGRe8+oyJ3M=; b=NSY5IECMcON1LfuXMfoROvPN2oSjPOjU2potm5AfFz4/Btiol4G7+X5BNpJ6Fla6e2 cNMirDsxf3ZIdSozOEfAwxqYHHjc8tv3mV8p9ePeMm2hhQnMAYea7HLaNejH2OF2JBmU bIOlAhLjh8jOzTOKJAslLNqGvP9Ccje7qFpagUwpE6d3Xp3KfKt7esJLz79Z/rFJSZCi y89AD2nZVBKOsGm+KrdkEHFw/Sn4NrhnVUXmBXhsWH3XTKGGHR6yccT/Z0CZDCpqm325 f2jruML34jCpBHi5AuLkny3KsBGbrmj2vPNHF8NSeNH1IXauafMEyDJXr2yw7PHqE1p6 Uq7Q== X-Received: by 10.15.98.9 with SMTP id bi9mr1725293eeb.67.1381937937847; Wed, 16 Oct 2013 08:38:57 -0700 (PDT) MIME-Version: 1.0 Sender: konklone@gmail.com Received: by 10.223.167.69 with HTTP; Wed, 16 Oct 2013 08:38:17 -0700 (PDT) In-Reply-To: <525D9646.7010306@packetizer.com> References: <525D9646.7010306@packetizer.com> From: Eric Mill Date: Wed, 16 Oct 2013 11:38:17 -0400 X-Google-Sender-Auth: V0Q-8A6M3jrjqkDkZTfVH1aQLSY Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e01681470e31a1704e8dd7fbd Cc: "webfinger@ietf.org" , webfinger@googlegroups.com Subject: Re: [webfinger] Vision for Webfinger - what are we doing? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:39:08 -0000 --089e01681470e31a1704e8dd7fbd Content-Type: text/plain; charset=ISO-8859-1 This is all helpful to hear, and I hope these all come to fruition, especially OpenID Connect. I'll take a stab at setting up my own OpenID Connect service on my domain and see how it feels. I guess it's inevitable that we have to hope the big companies make a meaningful gesture, too. Giving Google's outdated Webfinger endpoint for Gmail a big update would be a great start. On Tue, Oct 15, 2013 at 3:23 PM, Paul E. Jones wrote: > Eric, > > OpenID is not entirely dead, yet. I still run my own OpenID OP server and > use it to log into some sites. I still allow OpenID logins on > forums.packetizer.com, too. It's still in use, but the large sites just > didn't have enough users using it, so they axed it. On its heels, though, > is now OpenID Connect and it will use WebFinger for discovery. so, sure... > push it :-) > > Personally, I can think of a lot of good uses for WebFinger: > * When I log onto a web site, I want the site to grab my name an picture > automatically. > * If I want somebody to send me bitcoins, I'd much rather give them my > email address (and I do have that in my WF account) > * My contact info is published via WebFinger, so I don't have to give > people a lot of info on a business card > * WebFinger will hopefully be used as the starting point for > auto-provisioning of email clients or other devices and applications where > one has to enter server and port information > > Paul > > > On 10/14/2013 11:21 PM, Eric Mill wrote: > > Hey all, > > I was at a hackathon today, > and spent the day working on Webfinger libraries for Sinatraand > Jekyll . It was really > productive, but -- at the end of the day, a reporter was there asking > everybody questions about their projects. > > When he asked what Webfinger was for, I realized that the original > easy-to-communicate killer app for Webfinger, easing universal login > through OpenID, was > dead . The only thing I could think to say was > "Remember OpenID? Before it died? Well, this is a piece of the puzzle to > putting something like that back together again." > > That didn't feel like a very impressive answer. So, now that OpenID is > dead, what's the one line explanation for why Webfinger is important? > What's the path forward to making Webfinger something people are > incentivized to support? > > Should we be pushing really hard to resuscitate OpenID via OpenID > Connect? Do we just need to wait for internal lobbying inside of > Google/Microsoft/Twitter/etc to pay off in some announcement? I know > Webfinger supports more than email lookup -- is there some particular > killer app people were envisioning when they lobbied for that feature? > > I'm so happy there's finally an RFC, after so many years. I recognize > how much work was put in to make that happen, and this shouldn't be taken > as a criticism of anyone. I just want to know what others see for the > future of Webfinger, and what I should do next. > > -- Eric > > -- > konklone.com | @konklone > > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > -- konklone.com | @konklone --089e01681470e31a1704e8dd7fbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is all helpful to hear, and I hope these all come to = fruition, especially OpenID Connect. I'll take a stab at setting up my = own OpenID Connect service on my domain and see how it feels.

I guess it's inevitable that we have to hope the big compani= es make a meaningful gesture, too. Giving Google's outdated Webfinger endpoi= nt=A0for Gmail a big update would be a great start.

On Tue, Oct= 15, 2013 at 3:23 PM, Paul E. Jones <paulej@packetizer.com> wrote:
=20 =20 =20
Eric,

OpenID is not entirely dead, yet.=A0 I still run my own OpenID OP server and use it to log into some sites.=A0 I still allow OpenID logins on fo= rums.packetizer.com, too.=A0 It's still in use, but the large sites just didn't have enough users using it, so they axed it.=A0 On its heels, though, is now OpenID Connect and it will use WebFinger for discovery.=A0 so, sure... push it :-)

Personally, I can think of a lot of good uses for WebFinger:
* When I log onto a web site, I want the site to grab my name an picture automatically.
* If I want somebody to send me bitcoins, I'd much rather give them my email address (and I do have that in my WF account)
* My contact info is published via WebFinger, so I don't have to give people a lot of info on a business card
* WebFinger will hopefully be used as the starting point for auto-provisioning of email clients or other devices and applications where one has to enter server and port information

Paul


On 10/14/2013 11:21 PM, Eric Mill wrote:
Hey all,

I was at a hackathon=A0today, and spent the day working on Webfinger libraries for Sinatra and Jekyll. It was really productive, but -- at the end of the day, a reporter was there asking everybody questions about their projects.=A0

When he asked what Webfinger was for, I realized that the original easy-to-communicate killer app for Webfinger, easing universal login through OpenID, was dead. The only thing I could think to say was "Remember OpenID? Before it died? Well, this is a piece of the puzzle to putting something like that back together again."

That didn't feel like a very impressive answer. So, no= w that OpenID is dead, what's the one line explanation for why Webfinger is important? What's the path forward to making Webfinger something people are incentivized to support?

Should we be pushing really hard to resuscitate OpenID via OpenID Connect? Do we just need to wait for internal lobbying inside of Google/Microsoft/Twitter/etc to pay off in some announcement? I know Webfinger supports more than email lookup -- is there some particular killer app people were envisioning when they lobbied for that feature?

I'm so happy there's finally an RFC, after so many years. I recognize how much work was put in to make that happen, and this shouldn't be taken as a criticism of anyone. I just want to know what others see for the future of Webfinger, and what I should do next.

-- Eric

-- 


_______________________________________________
webfinger mailing list
webfinger@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/webfinger


_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger




--
--089e01681470e31a1704e8dd7fbd--