From mrkrcsmith@googlemail.com Thu Aug 1 04:13:15 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 8080221E8053 for ; Thu, 1 Aug 2013 04:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 iUyjbLbbv3tM for ; Thu, 1 Aug 2013 04:13:14 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 54BED21E808A for ; Thu, 1 Aug 2013 04:13:12 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id c11so1585991wgh.32 for ; Thu, 01 Aug 2013 04:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=LfGxv3Oxy7n8YIl47oAP8Nn853nv909YyHbtP/nFjj0=; b=gJpNgxWNoTDLiE7gPwgkWqcae/dV8YtqufYhJ4ozyWsXnNMkwRia/p7dmEd6RxTBXx 2DDhWy0tQeVErGY6Q/7VMt1gZxv/6Aj0shYtkBPQdvHIXahu2che35bsJ4XYI0/wfN8x W/iHIkblrgh60daVwsjb5IzQTpsqv8im84yWDLE15HzQzB6UKK9JdvipoxXVOBOGw2Aj imPearyY87jJbrM8i7iruaURFMiMr+HQ3diQOsg1eu0gQz9xZ7Jn2+2KstxEVGCb0TIg 3eskaJdQBrbs4bGMifYgNiGZu5nYhDOvxEZjx9tJ2saDsSLmlZl3E9a5RhPeqedMLILs 1dcw== X-Received: by 10.180.101.167 with SMTP id fh7mr765095wib.41.1375355591295; Thu, 01 Aug 2013 04:13:11 -0700 (PDT) Received: from KEVIN-SMITHs-MacBook-Air-3.local (cpc5-tonb3-2-0-cust37.croy.cable.virginmedia.com. [82.40.186.38]) by mx.google.com with ESMTPSA id mb7sm3025540wic.10.2013.08.01.04.13.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Aug 2013 04:13:10 -0700 (PDT) Message-ID: <51FA42C5.7060806@googlemail.com> Date: Thu, 01 Aug 2013 12:13:09 +0100 From: Kevin Smith User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: webfinger References: <51F8E3B6.8010002@googlemail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060904040905040408070903" X-Mailman-Approved-At: Thu, 01 Aug 2013 04:24:51 -0700 Subject: Re: [webfinger] create/update JRD via Webfinger 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, 01 Aug 2013 11:13:15 -0000 This is a multi-part message in MIME format. --------------060904040905040408070903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> Thanks Melvin > The most common way to do something like this is in line with WebDAV, > where PUT creates a new document, DELETE removes one and GET reads one. > > POST is very often used as an append technology, tho POST can be > implemented however a server wants to > > POST can be very useful with a query language to perform adds, deletes > and updates > > PATCH is an interesting one, and there's JSON PATCH [1] which *may* be > able to be standardized after JRD is completed > > Personally I'd use a custom script to do this right now, or use > another serialization more suited to updates, and keep it in kilter > with the JRD >> yes, for now we are going to use a simple HTTP-based model, with PUT to create a new Webfinger resource in JRD, and JSON PATCH for updates. I can update the list on the usefulness when done. > > Something like the Linked Data Platform [2] would be a good template > for this too > > [1] http://tools.ietf.org/html/rfc6902 > [2] http://www.w3.org/TR/2013/WD-ldp-20130730/ > > > Many thanks! > Kevin > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --------------060904040905040408070903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >> Thanks Melvin
The most common way to do something like this is in line with WebDAV, where PUT creates a new document, DELETE removes one and GET reads one.

POST is very often used as an append technology, tho POST can be implemented however a server wants to

POST can be very useful with a query language to perform adds, deletes and updates

PATCH is an interesting one, and there's JSON PATCH [1] which *may* be able to be standardized after JRD is completed

Personally I'd use a custom script to do this right now, or use another serialization more suited to updates, and keep it in kilter with the JRD

>> yes, for now we are going to use a simple HTTP-based model, with PUT to create a new Webfinger resource in JRD, and JSON PATCH for updates. I can update the list on the usefulness when done.

Something like the Linked Data Platform [2] would be a good template for this too

[1] http://tools.ietf.org/html/rfc6902
[2] http://www.w3.org/TR/2013/WD-ldp-20130730/
 

Many thanks!
Kevin



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


--------------060904040905040408070903-- From duerst@it.aoyama.ac.jp Fri Aug 2 03:58:55 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 4350821E82DD for ; Fri, 2 Aug 2013 03:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.319 X-Spam-Level: X-Spam-Status: No, score=-103.319 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 NRBpC2FKUpY6 for ; Fri, 2 Aug 2013 03:58:43 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id A093621E8084 for ; Fri, 2 Aug 2013 03:58:41 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r72AwIRc020643; Fri, 2 Aug 2013 19:58:18 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 35bf_aae4_700eb8cc_fb62_11e2_9ee9_001e6722eec2; Fri, 02 Aug 2013 19:58:17 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 1F574BF4E3; Fri, 2 Aug 2013 19:56:11 +0900 (JST) Message-ID: <51FB90B6.4000107@it.aoyama.ac.jp> Date: Fri, 02 Aug 2013 19:57:58 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <028301ce869f$596c12a0$0c4437e0$@packetizer.com> <042f01ce8722$4d98a410$e8c9ec30$@packetizer.com> <51EE45C5.4080701@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] Webfinger and URI vs IRI 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, 02 Aug 2013 10:58:55 -0000 X-List-Received-Date: Fri, 02 Aug 2013 10:58:55 -0000 Hello Barry, Sorry for the delay in answering your mail. On 2013/07/23 18:26, Barry Leiba wrote: >> Please stop this "only for presentation" myth that essentially means t= hat > everything is legible as long as it's English. > > It's not a "myth", Martin. It's a myth. First and foremost, RFC 3987 clearly describes IRIs as=20 protocol elements (it's in the first line of the abstract, so you don't=20 have to search for long). Second, your earlier mail (around July 22nd) said "I believe WF should=20 only use URIs. I believe that IRIs are a presentation layer thing.".=20 Surely we should be able to do better than just "believe". > It's a question of who needs to read it. > Humans don't have to read what's in the JSON. So people on this list are not humans? > The application that shows > a URI to a user will have to render it in a way the user can read it. > That's where we get the presentation layer. What if we had one layer less? Layers are a very convenient thing if=20 they add functionality, but not if they add confusion. If we would redo=20 email, for example, we would do away with all the base64 and=20 quoted-printable stuff, wouldn't we? Regards, Martin. > Barry > > On Tuesday, July 23, 2013, "Martin J. D=C3=BCrst" wrote: > >> Hello everybody, >> >> On 2013/07/23 6:27, Paul E. Jones wrote: >> >>> Barry, >>> >> >> The reason I raise this is that RFC 5988 refers to the target IRI (t= he >>> =E2=80=9Chref=E2=80=9D in WebFinger link relation) and context IRI (t= he =E2=80=9Csubject=E2=80=9D and >>> =E2=80=9Caliases=E2=80=9D in WebFinger). Only ASCII is used in some = protocols, so the >>> IRIs must be formatted as URIs. >>> >> >> However, JRD is JSON and, therefore, Unicode. Thus, we could easily >>> accommodate links like this: >>> >> >> { >>> >>> "rel" : "test2", >>> >>> "href" : "http://example.org/=E7=A7=81=E3=81=AE =E6=96=87=E6=9B= =B8.txt" >>> >>> } >>> >> >> As opposed this form: >>> >> >> { >>> >>> "rel" : "test2", >>> >>> "href" : >>> "http://example.org/%E7%A7%81%**E3%81%AE%20%E6%96%87%E6%9B%B8.**txt >>> " >>> >>> } >>> >> >> I have no strong preference, but the text did have IRI mentioned in = one >>> place in the JRD spec section, but it was not consistent through the >>> document. Everywhere else, we specified URI. >>> >> >> So, if IRIs are truly only for presentation, >>> >> >> That's clearly not the case. IRIs are used in HTML and other places. >> >> then the latter example above >>> should be what WF servers return. The query target is always a >>> percent-encoded URI, so it=E2=80=99s a non-issue. >>> >> >> For most of you, the differences between the above two examples are mo= stly >> irrelevant, and the second one may even look more familiar. But for th= ose >> who can read the first one (Japanese, although the space is highly >> suspicious, because Japanese doesn't use spaces), the first one is ver= y >> clear, whereas the second one is complete gibberish. >> >> As a slightly related example, one could write >> "rel" : "test2" >> as >> "rel" : "%74%65%73%74%32" >> and it would provide about the same level of useless obscuration. >> >> Please stop this "only for presentation" myth that essentially means t= hat >> everything is legible as long as it's English. >> >> Regards, Martin. >> > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From paulej@packetizer.com Fri Aug 9 09:17:59 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 A31EC21E808A for ; Fri, 9 Aug 2013 09:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_05=-1.11] 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 pu6qTdzavDMC for ; Fri, 9 Aug 2013 09:17:55 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3523E11E81A5 for ; Fri, 9 Aug 2013 09:09:44 -0700 (PDT) Received: from sydney (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 r79G9f5m013959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 9 Aug 2013 12:09:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1376064582; bh=GC/9h9kHjurtbvvSra35ObVs6KwcueWbpRBe3L7yA84=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=kjyFJ28EKBsQH+rDSuqVGTwwogJMxN0vfKJUNKk5Z7t/Me3Vz9TcUVqDaP3bVZcxM W5tFt1qTu18CJTVTZpygKcLEZNnK+HbHm/d1SJ/nYwqsOUgtUW7x8xzYCwrJ7P3hwj cMauzrsIatcLsejyURyvr7n/1tHlgg1GcANdh2Jw= From: "Paul E. Jones" To: "'webfinger'" Date: Fri, 9 Aug 2013 12:09:55 -0400 Message-ID: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6VGZcQqZ04lDZOR3WbbyXqRiI0pQ== Content-Language: en-us Subject: [webfinger] New WebFinger Draft posted 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, 09 Aug 2013 16:17:59 -0000 Folks, As we're trying to bring the WebFinger spec to a close, we published a new version -17 with some changes the WG might want to consider. Draft is: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 Those changes are: - Section 2, added a new last paragraph to explain what URI syntax we use in WebFinger - Corrected error in section 3.2 ("Host:" line in example and quotes around "3.2") - We remove the words "absolute URI" since it's really redundant - Added "query target" to 4.5 for clarity - Introduced a new section 8 that describes "WebFinger" applications. This is a major new addition. - Added a new section 10.3 and 10.4 to address registration of link relation types and properties. Link relations types already have a registry and we refer to existing procedures. WebFinger properties did not have a registry, so we define one, primarily for the purpose of helping people avoid creating redundant definitions. If you have any questions or comments, please feel free to post to the list. Paul From melvincarvalho@gmail.com Sat Aug 17 11:12: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 BE45A11E823D for ; Sat, 17 Aug 2013 11:12:13 -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 fBVnXl2BDXZt for ; Sat, 17 Aug 2013 11:12:13 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7A521F8AD5 for ; Sat, 17 Aug 2013 11:12:12 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id eh20so2349088lab.4 for ; Sat, 17 Aug 2013 11:12:11 -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=40UhDztqDvR9cc3lsYukOUSL5Q+R3iSnGdvk4Xj5f+E=; b=JYJH954ui0GBf6nUZNqZ2XgUBeNhfCKRBx+yxPMxFhW2tdRe+pvSXKEq6wNFSzi1uQ 2KgKvxwUpspeWsErYSt+FpSyY36I2QcQF2Nv6lmiED/+tR1q9dgDd8e7xnHAVBKJj/tj 09B62z9Wg8MUAGaxw+DvzOkIElE5IeoPIAEpVYJyPHDbKj5ZOGdeij+rpqaunr5sTZ7D pu3wwrws1gEc2LvhZBtv1NaujqEEeYLDYgESD3JCsD7aTkTQLoqyDR+oAiqYzTscRqeJ ab73iKx4FW5a15CwUbUKIp4Cf140FkVnmclT1WkAv/yV4cTFkyuhI2FEw0xMsn8eZxya iMVQ== MIME-Version: 1.0 X-Received: by 10.152.19.70 with SMTP id c6mr3044838lae.25.1376763131385; Sat, 17 Aug 2013 11:12:11 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Sat, 17 Aug 2013 11:12:11 -0700 (PDT) In-Reply-To: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> Date: Sat, 17 Aug 2013 20:12:11 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e013d1b9c62dd4604e428a548 Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted 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, 17 Aug 2013 18:12:13 -0000 --089e013d1b9c62dd4604e428a548 Content-Type: text/plain; charset=ISO-8859-1 On 9 August 2013 18:09, Paul E. Jones wrote: > Folks, > > As we're trying to bring the WebFinger spec to a close, we published a new > version -17 with some changes the WG might want to consider. > > Draft is: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 > > Those changes are: > > - Section 2, added a new last paragraph to explain what URI syntax we use > in > WebFinger > - Corrected error in section 3.2 ("Host:" line in example and quotes around > "3.2") > - We remove the words "absolute URI" since it's really redundant > - Added "query target" to 4.5 for clarity > - Introduced a new section 8 that describes "WebFinger" applications. This > is a major new addition. > - Added a new section 10.3 and 10.4 to address registration of link > relation > types and properties. Link relations types already have a registry and we > refer to existing procedures. WebFinger properties did not have a > registry, > so we define one, primarily for the purpose of helping people avoid > creating > redundant definitions. > > If you have any questions or comments, please feel free to post to the > list. > [[ The order of elements in the "links" array indicates an order of preference. Thus, if there are two or more link relations having the same "rel" value, the first link relation would indicate the user's preferred link. ]] Maybe remove this altogether, as I am unsure it can be guaranteed. Case 1: Let's say I have a list of friends, how am I to determine as a server the preferred friends? How am I to determine as a client whether the friends are ordered or not? Case 2: Say I mash up data from two sources, how do I then order the combined list? > > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > --089e013d1b9c62dd4604e428a548 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 9 August 2013 18:09, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,

As we're trying to bring the WebFinger spec to a close, we published a = new
version -17 with some changes the WG might want to consider.

Draft is:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17

Those changes are:

- Section 2, added a new last paragraph to explain what URI syntax we use i= n
WebFinger
- Corrected error in section 3.2 ("Host:" line in example and quo= tes around
"3.2")
- We remove the words "absolute URI" since it's really redund= ant
- Added "query target" to 4.5 for clarity
- Introduced a new section 8 that describes "WebFinger" applicati= ons. =A0This
is a major new addition.
- Added a new section 10.3 and 10.4 to address registration of link relatio= n
types and properties. =A0Link relations types already have a registry and w= e
refer to existing procedures. =A0WebFinger properties did not have a regist= ry,
so we define one, primarily for the purpose of helping people avoid creatin= g
redundant definitions.

If you have any questions or comments, please feel free to post to the list= .



Paul


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

--089e013d1b9c62dd4604e428a548-- From paulej@packetizer.com Sat Aug 17 11:32:36 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 D426711E8241 for ; Sat, 17 Aug 2013 11:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 IaStMZrZ73fW for ; Sat, 17 Aug 2013 11:32:32 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4844711E823B for ; Sat, 17 Aug 2013 11:32:32 -0700 (PDT) Received: from [100.118.102.42] (me54636d0.tmodns.net [208.54.70.229]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r7HIWPTU017560 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 17 Aug 2013 14:32:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1376764350; bh=Y3Xr/HWbl4ZnZDGRrBeY8FsQ66ejqCDxVnNoHAdQFIw=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=gquVY870Alhgk2tPgNdz5IyDJYUNw2TaHCQz90Z/7WtSlxI2hiszpYchJ1FKzgY3D eNp7vETvvb8HU98x6kQjy57Tqul4jdVtJRGm7797McYzXtItwc1qhyA+zsngSDlA6+ 3rqSLMQUz6yBydzat25b1omRKOWGEWfS1aJR1+WQ= User-Agent: Kaiten Mail In-Reply-To: References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----XMAZUSBFUTJ6TCRUFRHHXTNR8YDC5C" From: "Paul E. Jones" Date: Sat, 17 Aug 2013 14:32:19 -0400 To: Melvin Carvalho Message-ID: Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted 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, 17 Aug 2013 18:32:37 -0000 ------XMAZUSBFUTJ6TCRUFRHHXTNR8YDC5C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Melvin, We have been asked about this before. If we leave it in, it meets the needs of some. I admit there might be cases where it's hard to control order, but if it matters, there is at least a way. In my own implementation, I assign an integer value to each entry and sort on that. I have no strong objection either way, but I do think it's good to have for those who care. Paul -------- Original Message -------- From: Melvin Carvalho Sent: Sat Aug 17 14:12:11 EDT 2013 To: "Paul E. Jones" Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 9 August 2013 18:09, Paul E. Jones wrote: > Folks, > > As we're trying to bring the WebFinger spec to a close, we published a new > version -17 with some changes the WG might want to consider. > > Draft is: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 > > Those changes are: > > - Section 2, added a new last paragraph to explain what URI syntax we use > in > WebFinger > - Corrected error in section 3.2 ("Host:" line in example and quotes around > "3.2") > - We remove the words "absolute URI" since it's really redundant > - Added "query target" to 4.5 for clarity > - Introduced a new section 8 that describes "WebFinger" applications. This > is a major new addition. > - Added a new section 10.3 and 10.4 to address registration of link > relation > types and properties. Link relations types already have a registry and we > refer to existing procedures. WebFinger properties did not have a > registry, > so we define one, primarily for the purpose of helping people avoid > creating > redundant definitions. > > If you have any questions or comments, please feel free to post to the > list. > [[ The order of elements in the "links" array indicates an order of preference. Thus, if there are two or more link relations having the same "rel" value, the first link relation would indicate the user's preferred link. ]] Maybe remove this altogether, as I am unsure it can be guaranteed. Case 1: Let's say I have a list of friends, how am I to determine as a server the preferred friends? How am I to determine as a client whether the friends are ordered or not? Case 2: Say I mash up data from two sources, how do I then order the combined list? > > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > ------XMAZUSBFUTJ6TCRUFRHHXTNR8YDC5C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Melvin,

We have been asked about this before. If we leave it in, it meets the needs of some. I admit there might be cases where it's hard to control order, but if it matters, there is at least a way.

In my own implementation, I assign an integer value to each entry and sort on that.

I have no strong objection either way, but I do think it's good to have for those who care.

Paul



From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sat Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted




On 9 August 2013 18:09, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,

As we're trying to bring the WebFinger spec to a close, we published a new
version -17 with some changes the WG might want to consider.

Draft is:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17

Those changes are:

- Section 2, added a new last paragraph to explain what URI syntax we use in
WebFinger
- Corrected error in section 3.2 ("Host:" line in example and quotes around
"3.2")
- We remove the words "absolute URI" since it's really redundant
- Added "query target" to 4.5 for clarity
- Introduced a new section 8 that describes "WebFinger" applications.  This
is a major new addition.
- Added a new section 10.3 and 10.4 to address registration of link relation
types and properties.  Link relations types already have a registry and we
refer to existing procedures.  WebFinger properties did not have a registry,
so we define one, primarily for the purpose of helping people avoid creating
redundant definitions.

If you have any questions or comments, please feel free to post to the list.

[[
   The order of elements in the "links" array indicates an order of
   preference.  Thus, if there are two or more link relations having the
   same "rel" value, the first link relation would indicate the user's
   preferred link.
]]
 
Maybe remove this altogether, as I am unsure it can be guaranteed.

Case 1: Let's say I have a list of friends, how am I to determine as a server the preferred friends?  How am I to determine as a client whether the friends are ordered or not?

Case 2: Say I mash up data from two sources, how do I then order the combined list?



Paul


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

------XMAZUSBFUTJ6TCRUFRHHXTNR8YDC5C-- From melvincarvalho@gmail.com Sat Aug 17 11:40:32 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 381DB21F9929 for ; Sat, 17 Aug 2013 11:40:32 -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 L+5E0L+WcmW5 for ; Sat, 17 Aug 2013 11:40:31 -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 B878021F96EF for ; Sat, 17 Aug 2013 11:40:30 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ea20so2392378lab.13 for ; Sat, 17 Aug 2013 11:40:29 -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=z5Hexxyior31difRgyAc1+xsd/TagN8s9CS3u/DKvHU=; b=RtThz3hNnVAoi6UuzsDix5P5gFR2MR8xA8kvaq1aDDi9KTgXd7/FA8iUpD+GP7J/Gx p0+H9lR6160Of1aKJ+0NQW0iVcEFd2ZKGasQEw8Vy1KufCIccnFRvQPoPHVVWOlI1NPO lihoXRm9hX29A2laNCM/23d/dLFbn1MkcN0HVn2mCEVCUtg5chb53tkvPKZ0DSyXCAh5 GdOqMakZgs2P4jns93V0uXN4DeAAb2xd3PeQvA/8LcrFTWbBRw98LqPneegjy5YpAEow crLI50QDzWeNTlYTSzHWKAzGE3kpfW2z3muD8fzquCS4bey/hzs1AWwH3TNfqlV9r6Ag 5wfg== MIME-Version: 1.0 X-Received: by 10.112.87.68 with SMTP id v4mr3755619lbz.2.1376764829611; Sat, 17 Aug 2013 11:40:29 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Sat, 17 Aug 2013 11:40:29 -0700 (PDT) In-Reply-To: References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> Date: Sat, 17 Aug 2013 20:40:29 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a11341b069bbefc04e4290aff Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted 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, 17 Aug 2013 18:40:32 -0000 --001a11341b069bbefc04e4290aff Content-Type: text/plain; charset=ISO-8859-1 On 17 August 2013 20:32, Paul E. Jones wrote: > Melvin, > > We have been asked about this before. If we leave it in, it meets the > needs of some. I admit there might be cases where it's hard to control > order, but if it matters, there is at least a way. > > In my own implementation, I assign an integer value to each entry and sort > on that. > > I have no strong objection either way, but I do think it's good to have > for those who care. > I understand the trade offs. However, I can see that this is useful in many cases, particularly this would work well for openid, but other use cases, eg to have a friends list, for something like a federated social web, would then be perhaps impractical with JRD (not the end of the world, though) > Paul > > > ------------------------------ > *From:* Melvin Carvalho > *Sent:* Sat Aug 17 14:12:11 EDT 2013 > *To:* "Paul E. Jones" > *Cc:* webfinger > *Subject:* Re: [webfinger] New WebFinger Draft posted > > > > > On 9 August 2013 18:09, Paul E. Jones wrote: > >> Folks, >> >> As we're trying to bring the WebFinger spec to a close, we published a new >> version -17 with some changes the WG might want to consider. >> >> Draft is: >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 >> >> Those changes are: >> >> - Section 2, added a new last paragraph to explain what URI syntax we use >> in >> WebFinger >> - Corrected error in section 3.2 ("Host:" line in example and quotes >> around >> "3.2") >> - We remove the words "absolute URI" since it's really redundant >> - Added "query target" to 4.5 for clarity >> - Introduced a new section 8 that describes "WebFinger" applications. >> This >> is a major new addition. >> - Added a new section 10.3 and 10.4 to address registration of link >> relation >> types and properties. Link relations types already have a registry and we >> refer to existing procedures. WebFinger properties did not have a >> registry, >> so we define one, primarily for the purpose of helping people avoid >> creating >> redundant definitions. >> >> If you have any questions or comments, please feel free to post to the >> list. >> > > [[ > > The order of elements in the "links" array indicates an order of > preference. Thus, if there are two or more link relations having the > same "rel" value, the first link relation would indicate the user's > preferred link. > > ]] > > Maybe remove this altogether, as I am unsure it can be guaranteed. > > Case 1: Let's say I have a list of friends, how am I to determine as a > server the preferred friends? How am I to determine as a client whether > the friends are ordered or not? > > Case 2: Say I mash up data from two sources, how do I then order the > combined list? > > >> >> Paul >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> > > --001a11341b069bbefc04e4290aff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 17 August 2013 20:32, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:

Melvin,

We have been asked about this before. If we leave it in, it = meets the needs of some. I admit there might be cases where it's hard t= o control order, but if it matters, there is at least a way.

In my own implementation, I assign an integer value to each = entry and sort on that.

I have no strong objection either way, but I do think it'= ;s good to have for those who care.


I understand the trade offs.=A0 However, I can see that this is useful i= n many cases, particularly this would work well for openid, but other use c= ases, eg to have a friends list, for something like a federated social web,= would then be perhaps impractical with JRD (not the end of the world, thou= gh)

Paul



From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sat Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted




On 9 August 2013 18:09, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,

As we're trying to bring the WebFinger spec to a close, we published a = new
version -17 with some changes the WG might want to consider.

Draft is:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17

Those changes are:

- Section 2, added a new last paragraph to explain what URI syntax we use i= n
WebFinger
- Corrected error in section 3.2 ("Host:" line in example and quo= tes around
"3.2")
- We remove the words "absolute URI" since it's really redund= ant
- Added "query target" to 4.5 for clarity
- Introduced a new section 8 that describes "WebFinger" applicati= ons. =A0This
is a major new addition.
- Added a new section 10.3 and 10.4 to address registration of link relatio= n
types and properties. =A0Link relations types already have a registry and w= e
refer to existing procedures. =A0WebFinger properties did not have a regist= ry,
so we define one, primarily for the purpose of helping people avoid creatin= g
redundant definitions.

If you have any questions or comments, please feel free to post to the list= .



Paul


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


--001a11341b069bbefc04e4290aff-- From Michael.Jones@microsoft.com Sat Aug 17 11:47: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 8A13711E8245 for ; Sat, 17 Aug 2013 11:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.090, 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 diCCIxP3FFVr for ; Sat, 17 Aug 2013 11:47:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 94B1211E81E3 for ; Sat, 17 Aug 2013 11:47:05 -0700 (PDT) Received: from BLUPR03CA030.namprd03.prod.outlook.com (10.141.30.23) by BLUPR03MB246.namprd03.prod.outlook.com (10.255.213.18) with Microsoft SMTP Server (TLS) id 15.0.745.25; Sat, 17 Aug 2013 18:47:03 +0000 Received: from BL2FFO11FD042.protection.gbl (2a01:111:f400:7c09::25) by BLUPR03CA030.outlook.office365.com (2a01:111:e400:879::23) with Microsoft SMTP Server (TLS) id 15.0.745.25 via Frontend Transport; Sat, 17 Aug 2013 18:47:02 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD042.mail.protection.outlook.com (10.173.161.138) with Microsoft SMTP Server (TLS) id 15.0.745.15 via Frontend Transport; Sat, 17 Aug 2013 18:47:02 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.178]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0136.001; Sat, 17 Aug 2013 18:46:21 +0000 From: Mike Jones To: Melvin Carvalho , "Paul E. Jones" Thread-Topic: [webfinger] New WebFinger Draft posted Thread-Index: Ac6VGZcQqZ04lDZOR3WbbyXqRiI0pQGW7PSAAAC0AYAAAEkEgAAAKU/Q Date: Sat, 17 Aug 2013 18:45:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436B7A8D1ETK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52044002)(164054003)(25584003)(377454003)(189002)(199002)(24454002)(74876001)(69226001)(54356001)(81542001)(4396001)(79102001)(56776001)(47976001)(66066001)(47446002)(56816003)(74662001)(81816001)(31966008)(81342001)(74706001)(74502001)(53806001)(77096001)(76482001)(20776003)(80976001)(65816001)(54316002)(71186001)(55846006)(59766001)(74366001)(77982001)(51856001)(512954002)(19300405004)(6806004)(46102001)(47736001)(49866001)(80022001)(50986001)(15202345003)(63696002)(19580405001)(19580385001)(83322001)(76786001)(83072001)(76796001)(16236675002)(19580395003)(81686001)(33656001)(44976005); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB246; H:mail.microsoft.com; CLIP:131.107.125.37; 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: 0941B96580 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 131.107.125.37 X-MS-Exchange-CrossPremises-AuthSource: BL2FFO11FD042.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: BLUPR03MB246.namprd03.prod.outlook.com Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted 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, 17 Aug 2013 18:47:19 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436B7A8D1ETK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When used, the ordering can do good. When not used, it does no harm. Plea= se leave it in. Thanks, -- Mike From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Melvin Carvalho Sent: Saturday, August 17, 2013 11:40 AM To: Paul E. Jones Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 17 August 2013 20:32, Paul E. Jones > wrote: Melvin, We have been asked about this before. If we leave it in, it meets the needs= of some. I admit there might be cases where it's hard to control order, bu= t if it matters, there is at least a way. In my own implementation, I assign an integer value to each entry and sort = on that. I have no strong objection either way, but I do think it's good to have for= those who care. I understand the trade offs. However, I can see that this is useful in man= y cases, particularly this would work well for openid, but other use cases,= eg to have a friends list, for something like a federated social web, woul= d then be perhaps impractical with JRD (not the end of the world, though) Paul ________________________________ From: Melvin Carvalho > Sent: Sat Aug 17 14:12:11 EDT 2013 To: "Paul E. Jones" > Cc: webfinger > Subject: Re: [webfinger] New WebFinger Draft posted On 9 August 2013 18:09, Paul E. Jones > wrote: Folks, As we're trying to bring the WebFinger spec to a close, we published a new version -17 with some changes the WG might want to consider. Draft is: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 Those changes are: - Section 2, added a new last paragraph to explain what URI syntax we use i= n WebFinger - Corrected error in section 3.2 ("Host:" line in example and quotes around "3.2") - We remove the words "absolute URI" since it's really redundant - Added "query target" to 4.5 for clarity - Introduced a new section 8 that describes "WebFinger" applications. This is a major new addition. - Added a new section 10.3 and 10.4 to address registration of link relatio= n types and properties. Link relations types already have a registry and we refer to existing procedures. WebFinger properties did not have a registry= , so we define one, primarily for the purpose of helping people avoid creatin= g redundant definitions. If you have any questions or comments, please feel free to post to the list= . [[ The order of elements in the "links" array indicates an order of preference. Thus, if there are two or more link relations having the same "rel" value, the first link relation would indicate the user's preferred link. ]] Maybe remove this altogether, as I am unsure it can be guaranteed. Case 1: Let's say I have a list of friends, how am I to determine as a serv= er the preferred friends? How am I to determine as a client whether the fr= iends are ordered or not? Case 2: Say I mash up data from two sources, how do I then order the combin= ed list? Paul _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger --_000_4E1F6AAD24975D4BA5B16804296739436B7A8D1ETK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

When used, the ordering c= an do good.  When not used, it does no harm.  Please leave it in.=

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks,

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

 <= /p>

From: webfinge= r-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin Carvalho
Sent: Saturday, August 17, 2013 11:40 AM
To: Paul E. Jones
Cc: webfinger
Subject: Re: [webfinger] New WebFinger Draft posted

 

 

 

On 17 August 2013 20:32, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

We have been asked about this before. If we leave it in, it meets the ne= eds of some. I admit there might be cases where it's hard to control order,= but if it matters, there is at least a way.

In my own implementation, I assign an integer value to each entry and so= rt on that.

I have no strong objection either way, but I do think it's good to have = for those who care.

 

I understand the trade offs.  However, I can se= e that this is useful in many cases, particularly this would work well for = openid, but other use cases, eg to have a friends list, for something like = a federated social web, would then be perhaps impractical with JRD (not the end of the world, though)

 

Paul

 

From: Melvin C= arvalho <m= elvincarvalho@gmail.com>
Sent: Sat Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted

 

 

 

On 9 August 2013 18:09, Paul E. Jones <paulej@packetizer.com&= gt; wrote:

Folks,

As we're trying to bring the WebFinger spec to a close, we published a new<= br> version -17 with some changes the WG might want to consider.

Draft is:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17

Those changes are:

- Section 2, added a new last paragraph to explain what URI syntax we use i= n
WebFinger
- Corrected error in section 3.2 ("Host:" line in example and quo= tes around
"3.2")
- We remove the words "absolute URI" since it's really redundant<= br> - Added "query target" to 4.5 for clarity
- Introduced a new section 8 that describes "WebFinger" applicati= ons.  This
is a major new addition.
- Added a new section 10.3 and 10.4 to address registration of link relatio= n
types and properties.  Link relations types already have a registry an= d we
refer to existing procedures.  WebFinger properties did not have a reg= istry,
so we define one, primarily for the purpose of helping people avoid creatin= g
redundant definitions.

If you have any questions or comments, please feel free to post to the list= .


[[

   The order of elements in the "links" array indi=
cates an order of
   preference.  Thus, if there are two or more link rel=
ations having the
   same "rel" value, the first link relation would=
 indicate the user's
   preferred link.

]]
 

Maybe remove this alt= ogether, as I am unsure it can be guaranteed.

Case 1: Let's say I h= ave a list of friends, how am I to determine as a server the preferred frie= nds?  How am I to determine as a client whether the friends are ordere= d or not?

Case 2: Say I mash up data from two sources, how do = I then order the combined list?

 



Paul


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

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436B7A8D1ETK5EX14MBXC283r_-- From melvincarvalho@gmail.com Sat Aug 17 11:49: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 99DF611E8245 for ; Sat, 17 Aug 2013 11:49:07 -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 lpcNb2-ADSs3 for ; Sat, 17 Aug 2013 11:49:06 -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 3EACC11E8239 for ; Sat, 17 Aug 2013 11:49:06 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id v1so2110868lbd.38 for ; Sat, 17 Aug 2013 11:49:05 -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=FYRoX449sDDD+JWM48qBwCYYZAzP/Ffu46WcsD28Vlo=; b=EqV3zrezx9btK/FabRa2A6A+qgiqarUhxHWbuNwhADjoB6uQe+UxSK26IgJWEpBb8A gg5AX63QQzT8htSavmlkaTmvSe7KZgWhknHvymFWi561g2caw9nY/fYz2empwxJy/bf8 e1QuxMbKE8gqR669r9MhnakD/lzK30bQS4GtERqM24MYrLXSVrwLBybzTuv5yoaqussm Rgr7WGiL90bTty3udIsxbQfTKP8iAxw74iwgkUXfOHnff2li2vTENiWR5axxw78Iqs3n iNF9wleFYPUG+sU3YzIubiaZYVj0o4vsDMVvFHWblS7jZdZMklVL6c3CpX7fBK60od2y tIAg== MIME-Version: 1.0 X-Received: by 10.152.29.103 with SMTP id j7mr3814304lah.7.1376765345114; Sat, 17 Aug 2013 11:49:05 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Sat, 17 Aug 2013 11:49:05 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sat, 17 Aug 2013 20:49:05 +0200 Message-ID: From: Melvin Carvalho To: Mike Jones Content-Type: multipart/alternative; boundary=089e0160b82855b01f04e42929e8 Cc: "Paul E. Jones" , webfinger Subject: Re: [webfinger] New WebFinger Draft posted 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, 17 Aug 2013 18:49:07 -0000 --089e0160b82855b01f04e42929e8 Content-Type: text/plain; charset=ISO-8859-1 On 17 August 2013 20:45, Mike Jones wrote: > When used, the ordering can do good. When not used, it does no harm. > Please leave it in. > Mike, my question related to how the client can *know* when it's used and when it's not used. This seems unclear? > **** > > ** ** > > Thanks,**** > > -- Mike**** > > ** ** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *On > Behalf Of *Melvin Carvalho > *Sent:* Saturday, August 17, 2013 11:40 AM > *To:* Paul E. Jones > *Cc:* webfinger > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > ** ** > > ** ** > > ** ** > > On 17 August 2013 20:32, Paul E. Jones wrote:**** > > Melvin,**** > > We have been asked about this before. If we leave it in, it meets the > needs of some. I admit there might be cases where it's hard to control > order, but if it matters, there is at least a way.**** > > In my own implementation, I assign an integer value to each entry and sort > on that.**** > > I have no strong objection either way, but I do think it's good to have > for those who care.**** > > ** ** > > I understand the trade offs. However, I can see that this is useful in > many cases, particularly this would work well for openid, but other use > cases, eg to have a friends list, for something like a federated social > web, would then be perhaps impractical with JRD (not the end of the world, > though)**** > > **** > > Paul**** > > ** ** > ------------------------------ > > *From:* Melvin Carvalho > *Sent:* Sat Aug 17 14:12:11 EDT 2013 > *To:* "Paul E. Jones" > *Cc:* webfinger > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > ** ** > > ** ** > > ** ** > > On 9 August 2013 18:09, Paul E. Jones wrote:**** > > Folks, > > As we're trying to bring the WebFinger spec to a close, we published a new > version -17 with some changes the WG might want to consider. > > Draft is: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 > > Those changes are: > > - Section 2, added a new last paragraph to explain what URI syntax we use > in > WebFinger > - Corrected error in section 3.2 ("Host:" line in example and quotes around > "3.2") > - We remove the words "absolute URI" since it's really redundant > - Added "query target" to 4.5 for clarity > - Introduced a new section 8 that describes "WebFinger" applications. This > is a major new addition. > - Added a new section 10.3 and 10.4 to address registration of link > relation > types and properties. Link relations types already have a registry and we > refer to existing procedures. WebFinger properties did not have a > registry, > so we define one, primarily for the purpose of helping people avoid > creating > redundant definitions. > > If you have any questions or comments, please feel free to post to the > list.**** > > > [[**** > > The order of elements in the "links" array indicates an order of**** > > preference. Thus, if there are two or more link relations having the**** > > same "rel" value, the first link relation would indicate the user's**** > > preferred link.**** > > ]] > **** > > Maybe remove this altogether, as I am unsure it can be guaranteed.**** > > Case 1: Let's say I have a list of friends, how am I to determine as a > server the preferred friends? How am I to determine as a client whether > the friends are ordered or not?**** > > Case 2: Say I mash up data from two sources, how do I then order the > combined list?**** > > ** ** > > > > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger**** > > ** ** > > ** ** > --089e0160b82855b01f04e42929e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 17 August 2013 20:45, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

When used, the ordering c= an do good.=A0 When not used, it does no harm.=A0 Please leave it in.


Mike, my question related to h= ow the client can *know* when it's used and when it's not used.=A0 = This seems unclear?
=A0

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Thanks,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: webfinger-bounces@= ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin Carvalho
Sent: Saturday, August 17, 2013 11:40 AM
To: Paul E. Jones
Cc: webfinger


Subject: Re: [webfinger] New WebFinger Draft posted

=A0

=A0

=A0

On 17 August 2013 20:32, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

We have been asked about this before. If we leave it in, it meets the ne= eds of some. I admit there might be cases where it's hard to control or= der, but if it matters, there is at least a way.

In my own implementation, I assign an integer value to each entry and so= rt on that.

I have no strong objection either way, but I do think it's good to h= ave for those who care.

=A0

I understand the trade offs.=A0 However, I can see t= hat this is useful in many cases, particularly this would work well for ope= nid, but other use cases, eg to have a friends list, for something like a f= ederated social web, would then be perhaps impractical with JRD (not the end of the world, though)

=A0

Paul

=A0

From: Melvin C= arvalho <m= elvincarvalho@gmail.com>
Sent: Sat Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted

=A0

=A0

=A0

On 9 August 2013 18:09, Paul E. Jones <paulej@packetizer.com&= gt; wrote:

Folks,

As we're trying to bring the WebFinger spec to a close, we published a = new
version -17 with some changes the WG might want to consider.

Draft is:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17

Those changes are:

- Section 2, added a new last paragraph to explain what URI syntax we use i= n
WebFinger
- Corrected error in section 3.2 ("Host:" line in example and quo= tes around
"3.2")
- We remove the words "absolute URI" since it's really redund= ant
- Added "query target" to 4.5 for clarity
- Introduced a new section 8 that describes "WebFinger" applicati= ons. =A0This
is a major new addition.
- Added a new section 10.3 and 10.4 to address registration of link relatio= n
types and properties. =A0Link relations types already have a registry and w= e
refer to existing procedures. =A0WebFinger properties did not have a regist= ry,
so we define one, primarily for the purpose of helping people avoid creatin= g
redundant definitions.

If you have any questions or comments, please feel free to post to the list= .


[[

=A0=A0 The order of elements in the "links" array indicates =
an order of
=A0=A0 preference.=A0 Thus, if there are two or more link relations ha=
ving the
=A0=A0 same "rel" value, the first link relation would indic=
ate the user's
=A0=A0 preferred link.

]]
=A0

Maybe remove this alt= ogether, as I am unsure it can be guaranteed.

Case 1: Let's say= I have a list of friends, how am I to determine as a server the preferred = friends?=A0 How am I to determine as a client whether the friends are order= ed or not?

Case 2: Say I mash up data from two sources, how do = I then order the combined list?

=A0



Paul


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

=A0

=A0


--089e0160b82855b01f04e42929e8-- From paulej@packetizer.com Sat Aug 17 13:30: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 DC21711E8203 for ; Sat, 17 Aug 2013 13:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 gQLzOnRSpnqR for ; Sat, 17 Aug 2013 13:30:09 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5DB11E8129 for ; Sat, 17 Aug 2013 13:30:09 -0700 (PDT) Received: from [100.118.102.42] (me54636d0.tmodns.net [208.54.70.229]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r7HKU2d1024332 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 17 Aug 2013 16:30:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1376771407; bh=qjs9qnWg7fRp78ZEdKnZ/Uig3kBdsciFpZ1GrQBrSfU=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=F8KIrC5+qvUWJnol1DE4fPllbF3p3Ra9jfDEjJE4HYz4z/blwDFtkGbKB6YB4dK/y RanvUOADL1fBKBzORkNE8mNHmnQ5RgjvbA8rcIafu3alqKmNu7AAZKYsJDnSX6Z84a 2c0OVqKHtpZr8tBjcfeUay6Jn1padzC5WxhomT7k= User-Agent: Kaiten Mail In-Reply-To: References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----GPWXKK4CDHS38VEC2PZVKZ4KVKGD3Z" From: "Paul E. Jones" Date: Sat, 17 Aug 2013 16:29:57 -0400 To: Melvin Carvalho , Mike Jones Message-ID: Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted 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, 17 Aug 2013 20:30:14 -0000 ------GPWXKK4CDHS38VEC2PZVKZ4KVKGD3Z Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Why not have the client always offer items in the array in order? Any reason to randomly select items from the array? Paul -------- Original Message -------- From: Melvin Carvalho Sent: Sat Aug 17 14:49:05 EDT 2013 To: Mike Jones Cc: "Paul E. Jones" , webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 17 August 2013 20:45, Mike Jones wrote: > When used, the ordering can do good. When not used, it does no harm. > Please leave it in. > Mike, my question related to how the client can *know* when it's used and when it's not used. This seems unclear? > **** > > ** ** > > Thanks,**** > > -- Mike**** > > ** ** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *On > Behalf Of *Melvin Carvalho > *Sent:* Saturday, August 17, 2013 11:40 AM > *To:* Paul E. Jones > *Cc:* webfinger > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > ** ** > > ** ** > > ** ** > > On 17 August 2013 20:32, Paul E. Jones wrote:**** > > Melvin,**** > > We have been asked about this before. If we leave it in, it meets the > needs of some. I admit there might be cases where it's hard to control > order, but if it matters, there is at least a way.**** > > In my own implementation, I assign an integer value to each entry and sort > on that.**** > > I have no strong objection either way, but I do think it's good to have > for those who care.**** > > ** ** > > I understand the trade offs. However, I can see that this is useful in > many cases, particularly this would work well for openid, but other use > cases, eg to have a friends list, for something like a federated social > web, would then be perhaps impractical with JRD (not the end of the world, > though)**** > > **** > > Paul**** > > ** ** > ------------------------------ > > *From:* Melvin Carvalho > *Sent:* Sat Aug 17 14:12:11 EDT 2013 > *To:* "Paul E. Jones" > *Cc:* webfinger > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > ** ** > > ** ** > > ** ** > > On 9 August 2013 18:09, Paul E. Jones wrote:**** > > Folks, > > As we're trying to bring the WebFinger spec to a close, we published a new > version -17 with some changes the WG might want to consider. > > Draft is: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 > > Those changes are: > > - Section 2, added a new last paragraph to explain what URI syntax we use > in > WebFinger > - Corrected error in section 3.2 ("Host:" line in example and quotes around > "3.2") > - We remove the words "absolute URI" since it's really redundant > - Added "query target" to 4.5 for clarity > - Introduced a new section 8 that describes "WebFinger" applications. This > is a major new addition. > - Added a new section 10.3 and 10.4 to address registration of link > relation > types and properties. Link relations types already have a registry and we > refer to existing procedures. WebFinger properties did not have a > registry, > so we define one, primarily for the purpose of helping people avoid > creating > redundant definitions. > > If you have any questions or comments, please feel free to post to the > list.**** > > > [[**** > > The order of elements in the "links" array indicates an order of**** > > preference. Thus, if there are two or more link relations having the**** > > same "rel" value, the first link relation would indicate the user's**** > > preferred link.**** > > ]] > **** > > Maybe remove this altogether, as I am unsure it can be guaranteed.**** > > Case 1: Let's say I have a list of friends, how am I to determine as a > server the preferred friends? How am I to determine as a client whether > the friends are ordered or not?**** > > Case 2: Say I mash up data from two sources, how do I then order the > combined list?**** > > ** ** > > > > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger**** > > ** ** > > ** ** > ------GPWXKK4CDHS38VEC2PZVKZ4KVKGD3Z Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Why not have the client always offer items in the array in order? Any reason to randomly select items from the array?

Paul



From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sat Aug 17 14:49:05 EDT 2013
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: "Paul E. Jones" <paulej@packetizer.com>, webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted




On 17 August 2013 20:45, Mike Jones <Michael.Jones@microsoft.com> wrote:

When used, the ordering can do good.  When not used, it does no harm.  Please leave it in.


Mike, my question related to how the client can *know* when it's used and when it's not used.  This seems unclear?
 

 

                                                            Thanks,

                                                            -- Mike

 

From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin Carvalho
Sent: Saturday, August 17, 2013 11:40 AM
To: Paul E. Jones
Cc: webfinger


Subject: Re: [webfinger] New WebFinger Draft posted

 

 

 

On 17 August 2013 20:32, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

We have been asked about this before. If we leave it in, it meets the needs of some. I admit there might be cases where it's hard to control order, but if it matters, there is at least a way.

In my own implementation, I assign an integer value to each entry and sort on that.

I have no strong objection either way, but I do think it's good to have for those who care.

 

I understand the trade offs.  However, I can see that this is useful in many cases, particularly this would work well for openid, but other use cases, eg to have a friends list, for something like a federated social web, would then be perhaps impractical with JRD (not the end of the world, though)

 

Paul

 

From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sat Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted

 

 

 

On 9 August 2013 18:09, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

As we're trying to bring the WebFinger spec to a close, we published a new
version -17 with some changes the WG might want to consider.

Draft is:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17

Those changes are:

- Section 2, added a new last paragraph to explain what URI syntax we use in
WebFinger
- Corrected error in section 3.2 ("Host:" line in example and quotes around
"3.2")
- We remove the words "absolute URI" since it's really redundant
- Added "query target" to 4.5 for clarity
- Introduced a new section 8 that describes "WebFinger" applications.  This
is a major new addition.
- Added a new section 10.3 and 10.4 to address registration of link relation
types and properties.  Link relations types already have a registry and we
refer to existing procedures.  WebFinger properties did not have a registry,
so we define one, primarily for the purpose of helping people avoid creating
redundant definitions.

If you have any questions or comments, please feel free to post to the list.


[[

   The order of elements in the "links" array indicates an order of
   preference.  Thus, if there are two or more link relations having the
   same "rel" value, the first link relation would indicate the user's
   preferred link.

]]
 

Maybe remove this altogether, as I am unsure it can be guaranteed.

Case 1: Let's say I have a list of friends, how am I to determine as a server the preferred friends?  How am I to determine as a client whether the friends are ordered or not?

Case 2: Say I mash up data from two sources, how do I then order the combined list?

 



Paul


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

 

 


------GPWXKK4CDHS38VEC2PZVKZ4KVKGD3Z-- From bobwyman@gmail.com Sat Aug 17 14:05: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 B224D11E820B for ; Sat, 17 Aug 2013 14:05:02 -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 1nW-HTBcT8xe for ; Sat, 17 Aug 2013 14:05:01 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA0711E80F5 for ; Sat, 17 Aug 2013 14:04:58 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f12so2395300wgh.3 for ; Sat, 17 Aug 2013 14:04: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:date:message-id:subject :from:to:cc:content-type; bh=8twnsVeobluGubrYWFf15FCT8ZJ8hK7f8susRBqof3k=; b=P8w4/hMDmFbBosrUgHZ6CNCrBzrOoeK3ByxSItsVCAHCQ12Oel+mKDnP2DGQQKzwUj 6TDDHhZN0Qz42dkRwAfEsm/aVeT2W2h3D2NKKiwbpgZVgT29AttSn5A3N/7djRJVdnC6 Dl+fa0Yc0SpA5dGFNCPCDtZz/8OacZYU9qviYe/kYXIrP12IP/AAlXNB9lP0ddB09hnE MH9QBg5L4mJvsOfX6UNIv+PfmhpE66Y9sOow/RyzWFRWqctC/XtD9+TYphPO36b+eC+I E8RvH77fraCZNyKm3XHSABtMRhlnYdQAxbS7plqRDsUsOeWDcM9B3rm7pkevFIsENqNc zNWg== MIME-Version: 1.0 X-Received: by 10.180.206.180 with SMTP id lp20mr1694802wic.48.1376773498227; Sat, 17 Aug 2013 14:04:58 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.194.190.166 with HTTP; Sat, 17 Aug 2013 14:04:58 -0700 (PDT) In-Reply-To: References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sat, 17 Aug 2013 17:04:58 -0400 X-Google-Sender-Auth: 6N52ASZq8WtXXWaEz5bNSGcRbYs Message-ID: From: Bob Wyman To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a11c380b04c55ba04e42b0f20 Cc: webfinger , Mike Jones , Melvin Carvalho Subject: Re: [webfinger] New WebFinger Draft posted 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, 17 Aug 2013 21:05:02 -0000 --001a11c380b04c55ba04e42b0f20 Content-Type: text/plain; charset=ISO-8859-1 I would prefer if the wording didn't require that order of listing is required to indicate a necessary order of preference. Thus, I suggest the following wording: The order of elements in the "links" array *MAY be read as indicating* an order of preference. The idea is to permit readers to infer order of preference, and to allow writers to express that order, without requiring that a preferred order be determined or expressed. Where there is no preferred order, there will be no harm. Where there is a preferred order, the right thing will happen. bob wyman On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones wrote: > Why not have the client always offer items in the array in order? Any > reason to randomly select items from the array? > > Paul > > > ------------------------------ > *From:* Melvin Carvalho > *Sent:* Sat Aug 17 14:49:05 EDT 2013 > *To:* Mike Jones > *Cc:* "Paul E. Jones" , webfinger < > webfinger@ietf.org> > > *Subject:* Re: [webfinger] New WebFinger Draft posted > > > > > On 17 August 2013 20:45, Mike Jones wrote: > >> When used, the ordering can do good. When not used, it does no harm. >> Please leave it in. >> > > Mike, my question related to how the client can *know* when it's used and > when it's not used. This seems unclear? > > >> **** >> >> ** ** >> >> Thanks,**** >> >> -- Mike**** >> >> ** ** >> >> *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *On >> Behalf Of *Melvin Carvalho >> *Sent:* Saturday, August 17, 2013 11:40 AM >> *To:* Paul E. Jones >> *Cc:* webfinger >> >> *Subject:* Re: [webfinger] New WebFinger Draft posted**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> On 17 August 2013 20:32, Paul E. Jones wrote:**** >> >> Melvin,**** >> >> We have been asked about this before. If we leave it in, it meets the >> needs of some. I admit there might be cases where it's hard to control >> order, but if it matters, there is at least a way.**** >> >> In my own implementation, I assign an integer value to each entry and >> sort on that.**** >> >> I have no strong objection either way, but I do think it's good to have >> for those who care.**** >> >> ** ** >> >> I understand the trade offs. However, I can see that this is useful in >> many cases, particularly this would work well for openid, but other use >> cases, eg to have a friends list, for something like a federated social >> web, would then be perhaps impractical with JRD (not the end of the world, >> though)**** >> >> **** >> >> Paul**** >> >> ** ** >> ------------------------------ >> >> *From:* Melvin Carvalho >> *Sent:* Sat Aug 17 14:12:11 EDT 2013 >> *To:* "Paul E. Jones" >> *Cc:* webfinger >> *Subject:* Re: [webfinger] New WebFinger Draft posted**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> On 9 August 2013 18:09, Paul E. Jones wrote:**** >> >> Folks, >> >> As we're trying to bring the WebFinger spec to a close, we published a new >> version -17 with some changes the WG might want to consider. >> >> Draft is: >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 >> >> Those changes are: >> >> - Section 2, added a new last paragraph to explain what URI syntax we use >> in >> WebFinger >> - Corrected error in section 3.2 ("Host:" line in example and quotes >> around >> "3.2") >> - We remove the words "absolute URI" since it's really redundant >> - Added "query target" to 4.5 for clarity >> - Introduced a new section 8 that describes "WebFinger" applications. >> This >> is a major new addition. >> - Added a new section 10.3 and 10.4 to address registration of link >> relation >> types and properties. Link relations types already have a registry and we >> refer to existing procedures. WebFinger properties did not have a >> registry, >> so we define one, primarily for the purpose of helping people avoid >> creating >> redundant definitions. >> >> If you have any questions or comments, please feel free to post to the >> list.**** >> >> >> [[**** >> >> The order of elements in the "links" array indicates an order of**** >> >> preference. Thus, if there are two or more link relations having the**** >> >> same "rel" value, the first link relation would indicate the user's**** >> >> preferred link.**** >> >> ]] >> **** >> >> Maybe remove this altogether, as I am unsure it can be guaranteed.**** >> >> Case 1: Let's say I have a list of friends, how am I to determine as a >> server the preferred friends? How am I to determine as a client whether >> the friends are ordered or not?**** >> >> Case 2: Say I mash up data from two sources, how do I then order the >> combined list?**** >> >> ** ** >> >> >> >> 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 > > --001a11c380b04c55ba04e42b0f20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would prefer if the wording didn't require that orde= r of listing is required to indicate a necessary order of preference. Thus,= I suggest the following wording:
The order of elements in the "=
;links" array MAY be read as indicating an order of preference.=

The idea is to permit readers t=
o infer order of preference, and to allow writers to express that order, wi=
thout requiring that a preferred order be determined or expressed. Where th=
ere is no preferred order, there will be no harm. Where there is a preferre=
d order, the right thing will happen.
bob wyman

On Sat, Aug 17, 2013 at 4:29 PM, Paul E= . Jones <paulej@packetizer.com> wrote:

Why not have the client always offer i= tems in the array in order? Any reason to randomly select items from the ar= ray?

Paul



From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sat Aug 17 14:49:05 EDT 2013
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: "Paul E. Jones" <paulej@packetizer.com>, webfinger <webfinger@ietf.org&g= t;

Subject: Re: [webfinger] New WebFinger Draft posted




On 17 August 2013 20:45, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

When used, the ordering can do good.=A0 When not used= , it does no harm.=A0 Please leave it in.


Mike, my question related to h= ow the client can *know* when it's used and when it's not used.=A0 = This seems unclear?
=A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0

From: webfi= nger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin Carvalho
Sent: Saturday, August 17, 2013 11:40 AM
To: Paul E. Jones
Cc: webfinger


Subject: Re: [webfinger] New WebFinger Draft posted

=A0

=A0

=A0

On 17 August 2013 20:32, Paul E. Jones <paulej@packetizer.com> wrot= e:

Melvin,

We have been asked about this before. If we leave it in, it meets the ne= eds of some. I admit there might be cases where it's hard to control or= der, but if it matters, there is at least a way.

In my own implementation, I assign an integer value to each entry and so= rt on that.

I have no strong objection either way, but I do think it's good to h= ave for those who care.

=A0

I understand the trade offs.=A0 However, I can see that this = is useful in many cases, particularly this would work well for openid, but = other use cases, eg to have a friends list, for something like a federated = social web, would then be perhaps impractical with JRD (not the end of the world, though)

=A0

Paul

=A0

From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sat Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted

=A0

=A0

=A0

On 9 August 2013 18:09, Paul E. Jones <paulej@packetizer.com> wrote= :

Folks,

As we're trying to bring the WebFinger spec to a close, we published a = new
version -17 with some changes the WG might want to consider.

Draft is:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17

Those changes are:

- Section 2, added a new last paragraph to explain what URI syntax we use i= n
WebFinger
- Corrected error in section 3.2 ("Host:" line in example and quo= tes around
"3.2")
- We remove the words "absolute URI" since it's really redund= ant
- Added "query target" to 4.5 for clarity
- Introduced a new section 8 that describes "WebFinger" applicati= ons. =A0This
is a major new addition.
- Added a new section 10.3 and 10.4 to address registration of link relatio= n
types and properties. =A0Link relations types already have a registry and w= e
refer to existing procedures. =A0WebFinger properties did not have a regist= ry,
so we define one, primarily for the purpose of helping people avoid creatin= g
redundant definitions.

If you have any questions or comments, please feel free to post to the list= .


[[

=A0=A0 The order of elements in the "links" array indicates =
an order of
=A0=A0 preference.=A0 Thus, if there are two or more link relations ha=
ving the
=A0=A0 same "rel" value, the first link relation would indic=
ate the user's
=A0=A0 preferred link.

]]
=A0

Maybe remove this altogether, as= I am unsure it can be guaranteed.

Case 1: Let's say I have a l= ist of friends, how am I to determine as a server the preferred friends?=A0= How am I to determine as a client whether the friends are ordered or not?<= u>

Case 2: Say I mash up data from two sources, how do I then or= der the combined list?

=A0



Paul


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

=A0

=A0



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


--001a11c380b04c55ba04e42b0f20-- From melvincarvalho@gmail.com Sat Aug 17 22:14: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 E8B5A11E81C9 for ; Sat, 17 Aug 2013 22:14:10 -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 QcnP99zlHxiL for ; Sat, 17 Aug 2013 22:14:10 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 19BF011E81C8 for ; Sat, 17 Aug 2013 22:14:07 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id er20so2530071lab.35 for ; Sat, 17 Aug 2013 22:14:05 -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=ghs8M4B/BDVIuJAz96V3PAOfq/GQbEiEk67ndVWlzJQ=; b=Z0FLXkzm/mgbcU4aGqVx9OisHtYiNFZqJ8B50qc7FDKtTcZPZc7lO8PCRQmM3/Hwp+ B0oukx832k4Qb2bBTjNrc2D5SemkkZe/g9ztV5srDPW1yI0Z66qrEixF4UkElMLo4yRy BzKk6l2sjizADLl0JA6JM6E9h2HchzPSyPQ/QethqAPeczmBemHn+totDp0eBRz2D9QE 8jZjwJrjsbYm5WUdgflM850sXVtQ0fSFwYNKWZg15/qCXRXbEq27VWL4q/jcFVFL04j5 n9vpYqYqPIVxaqtvOnP/e7g5MOy8EV73B3up4zDQt1X4Ffwwt2UbLSmlXuTRQlK+CGY/ kL4A== MIME-Version: 1.0 X-Received: by 10.112.89.100 with SMTP id bn4mr5564282lbb.16.1376802845643; Sat, 17 Aug 2013 22:14:05 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Sat, 17 Aug 2013 22:14:05 -0700 (PDT) In-Reply-To: References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sun, 18 Aug 2013 07:14:05 +0200 Message-ID: From: Melvin Carvalho To: Bob Wyman Content-Type: multipart/alternative; boundary=001a11c379ec8a5b3b04e431e457 Cc: "Paul E. Jones" , Mike Jones , webfinger Subject: Re: [webfinger] New WebFinger Draft posted 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, 18 Aug 2013 05:14:11 -0000 --001a11c379ec8a5b3b04e431e457 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 17 August 2013 23:04, Bob Wyman wrote: > I would prefer if the wording didn't require that order of listing is > required to indicate a necessary order of preference. Thus, I suggest the > following wording: > > The order of elements in the "links" array *MAY be read as indicating* an= order of preference. > > The idea is to permit readers to infer order of preference, and to allow = writers to express that order, without requiring that a preferred order be = determined or expressed. Where there is no preferred order, there will be n= o harm. Where there is a preferred order, the right thing will happen. > > +1 > bob wyman > > > On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones wro= te: > >> Why not have the client always offer items in the array in order? Any >> reason to randomly select items from the array? >> >> Paul >> >> >> ------------------------------ >> *From:* Melvin Carvalho >> *Sent:* Sat Aug 17 14:49:05 EDT 2013 >> *To:* Mike Jones >> *Cc:* "Paul E. Jones" , webfinger < >> webfinger@ietf.org> >> >> *Subject:* Re: [webfinger] New WebFinger Draft posted >> >> >> >> >> On 17 August 2013 20:45, Mike Jones wrote: >> >>> When used, the ordering can do good. When not used, it does no harm. >>> Please leave it in. >>> >> >> Mike, my question related to how the client can *know* when it's used an= d >> when it's not used. This seems unclear? >> >> >>> **** >>> >>> ** ** >>> >>> Thanks,**** >>> >>> -- Mike**** >>> >>> ** ** >>> >>> *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = *On >>> Behalf Of *Melvin Carvalho >>> *Sent:* Saturday, August 17, 2013 11:40 AM >>> *To:* Paul E. Jones >>> *Cc:* webfinger >>> >>> *Subject:* Re: [webfinger] New WebFinger Draft posted**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> On 17 August 2013 20:32, Paul E. Jones wrote:**= * >>> * >>> >>> Melvin,**** >>> >>> We have been asked about this before. If we leave it in, it meets the >>> needs of some. I admit there might be cases where it's hard to control >>> order, but if it matters, there is at least a way.**** >>> >>> In my own implementation, I assign an integer value to each entry and >>> sort on that.**** >>> >>> I have no strong objection either way, but I do think it's good to have >>> for those who care.**** >>> >>> ** ** >>> >>> I understand the trade offs. However, I can see that this is useful in >>> many cases, particularly this would work well for openid, but other use >>> cases, eg to have a friends list, for something like a federated social >>> web, would then be perhaps impractical with JRD (not the end of the wor= ld, >>> though)**** >>> >>> **** >>> >>> Paul**** >>> >>> ** ** >>> ------------------------------ >>> >>> *From:* Melvin Carvalho >>> *Sent:* Sat Aug 17 14:12:11 EDT 2013 >>> *To:* "Paul E. Jones" >>> *Cc:* webfinger >>> *Subject:* Re: [webfinger] New WebFinger Draft posted**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> On 9 August 2013 18:09, Paul E. Jones wrote:***= * >>> >>> Folks, >>> >>> As we're trying to bring the WebFinger spec to a close, we published a >>> new >>> version -17 with some changes the WG might want to consider. >>> >>> Draft is: >>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 >>> >>> Those changes are: >>> >>> - Section 2, added a new last paragraph to explain what URI syntax we >>> use in >>> WebFinger >>> - Corrected error in section 3.2 ("Host:" line in example and quotes >>> around >>> "3.2") >>> - We remove the words "absolute URI" since it's really redundant >>> - Added "query target" to 4.5 for clarity >>> - Introduced a new section 8 that describes "WebFinger" applications. >>> This >>> is a major new addition. >>> - Added a new section 10.3 and 10.4 to address registration of link >>> relation >>> types and properties. Link relations types already have a registry and >>> we >>> refer to existing procedures. WebFinger properties did not have a >>> registry, >>> so we define one, primarily for the purpose of helping people avoid >>> creating >>> redundant definitions. >>> >>> If you have any questions or comments, please feel free to post to the >>> list.**** >>> >>> >>> [[**** >>> >>> The order of elements in the "links" array indicates an order of**** >>> >>> preference. Thus, if there are two or more link relations having th= e**** >>> >>> same "rel" value, the first link relation would indicate the user's*= *** >>> >>> preferred link.**** >>> >>> ]] >>> **** >>> >>> Maybe remove this altogether, as I am unsure it can be guaranteed.**** >>> >>> Case 1: Let's say I have a list of friends, how am I to determine as a >>> server the preferred friends? How am I to determine as a client whethe= r >>> the friends are ordered or not?**** >>> >>> Case 2: Say I mash up data from two sources, how do I then order the >>> combined list?**** >>> >>> ** ** >>> >>> >>> >>> 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 >> >> > --001a11c379ec8a5b3b04e431e457 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 17 August 2013 23:04, Bob Wyman <bob@wyman.us> wrote:<= br>
I would prefer if the wording didn't require that orde= r of listing is required to indicate a necessary order of preference. Thus,= I suggest the following wording:
The order of elements in the "=
;links" array MAY be read as indicating an order of preference.=

The idea is to permit readers t=
o infer order of preference, and to allow writers to express that order, wi=
thout requiring that a preferred order be determined or expressed. Where th=
ere is no preferred order, there will be no harm. Where there is a preferre=
d order, the right thing will happen.

+1
=A0
bob wyman

On= Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Why not have the client always offer i= tems in the array in order? Any reason to randomly select items from the ar= ray?

Paul



Sent: Sat Aug 17 14:49:05 EDT 2013
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: "Paul E. Jones" <paulej@packetizer.com>, webfinger <webfinger@ietf.org&g= t;

Subject: Re: [webfinger] New WebFinger Draft posted




On 17 August 2013 20:45, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

When used, the ordering can do good.=A0 When not used, it does n= o harm.=A0 Please leave it in.


Mike, my question related to h= ow the client can *know* when it's used and when it's not used.=A0 = This seems unclear?
=A0

<= u>

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0

From: webfinger-bounce= s@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin Carvalho
Sent: Saturday, August 17, 2013 11:40 AM
To: Paul E. Jones
Cc: webfinger


Subject: Re: [webfinger] New WebFinger Draft posted

=A0

=A0

=A0

On 17 August 2013 20:32, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

We have been asked about this before. If we leave it in, it meets the ne= eds of some. I admit there might be cases where it's hard to control or= der, but if it matters, there is at least a way.

In my own implementation, I assign an integer value to each entry and so= rt on that.

I have no strong objection either way, but I do think it's good to h= ave for those who care.

=A0

I understand the trade offs.=A0 However, I can see that this is useful i= n many cases, particularly this would work well for openid, but other use c= ases, eg to have a friends list, for something like a federated social web,= would then be perhaps impractical with JRD (not the end of the world, though)

=A0

Paul

=A0

From: Melvi= n Carvalho <melvincarvalho@gmail.com>
Sent: Sat Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted

=A0

=A0

=A0

On 9 August 2013 18:09, Paul E. Jones <paulej@packetizer.com> wrote:=

Folks,

As we're trying to bring the WebFinger spec to a close, we published a = new
version -17 with some changes the WG might want to consider.

Draft is:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17

Those changes are:

- Section 2, added a new last paragraph to explain what URI syntax we use i= n
WebFinger
- Corrected error in section 3.2 ("Host:" line in example and quo= tes around
"3.2")
- We remove the words "absolute URI" since it's really redund= ant
- Added "query target" to 4.5 for clarity
- Introduced a new section 8 that describes "WebFinger" applicati= ons. =A0This
is a major new addition.
- Added a new section 10.3 and 10.4 to address registration of link relatio= n
types and properties. =A0Link relations types already have a registry and w= e
refer to existing procedures. =A0WebFinger properties did not have a regist= ry,
so we define one, primarily for the purpose of helping people avoid creatin= g
redundant definitions.

If you have any questions or comments, please feel free to post to the list= .


[[

=A0=A0 The order of elements in the "links" array indicates =
an order of
=A0=A0 preference.=A0 Thus, if there are two or more link relations ha=
ving the
=A0=A0 same "rel" value, the first link relation would indic=
ate the user's
=A0=A0 preferred link.

]]
=A0

Maybe remove this altogether, as I am unsur= e it can be guaranteed.

Case 1: Let's say I have a list of frie= nds, how am I to determine as a server the preferred friends?=A0 How am I t= o determine as a client whether the friends are ordered or not?

Case 2: Say I mash up data from two sources, how do I then order the com= bined list?

=A0



Paul


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

=A0

=A0



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



--001a11c379ec8a5b3b04e431e457-- From paulej@packetizer.com Mon Aug 19 09:16: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 ADB9911E812A for ; Mon, 19 Aug 2013 09:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, 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 YevMrMHBlhah for ; Mon, 19 Aug 2013 09:16:18 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DB2FF21F9302 for ; Mon, 19 Aug 2013 09:16:17 -0700 (PDT) Received: from sydney (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 r7JGGF9l017445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Aug 2013 12:16:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1376928976; bh=Z7hNSIeAt30pYZIla9PdNIgiRjK2hBxE0Ru7UFoc/6o=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=pprj1J4hOcI4IUaSx9eTXfuN7LVVHPbQUcoNHH/dgs7O0F8E6Wl7gJGrYWMB2sBI4 9dMJ95amajHs8gG0fJlW2Vark0hbbTbByMUADx3r9jo2zHRSYL9UgPlMur16t4r9jF nncrXqygQmGYBBF/Pr6MsDEc0fBL68ZCUKy6Q2eo= From: "Paul E. Jones" To: "'Bob Wyman'" References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Date: Mon, 19 Aug 2013 12:16:26 -0400 Message-ID: <028601ce9cf7$74da6cd0$5e8f4670$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0287_01CE9CD5.EDCAEFB0" X-Mailer: Microsoft Outlook 14.0 thread-index: AQIRsulmUP4nxla1qQgQS/ZK2x+2zAK8b0g/AfMzvyICFml4JQLBB8OAAfhMdnoCd1cdhwFCqMITmJy79mA= Content-Language: en-us Cc: 'webfinger' , 'Mike Jones' , 'Melvin Carvalho' Subject: Re: [webfinger] New WebFinger Draft posted 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, 19 Aug 2013 16:16:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0287_01CE9CD5.EDCAEFB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bob, I'm OK with that change, if we're permitted to make this type of change now. Paul From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman Sent: Saturday, August 17, 2013 5:05 PM To: Paul E. Jones Cc: Melvin Carvalho; Mike Jones; webfinger Subject: Re: [webfinger] New WebFinger Draft posted I would prefer if the wording didn't require that order of listing is required to indicate a necessary order of preference. Thus, I suggest the following wording: The order of elements in the "links" array MAY be read as indicating an order of preference. The idea is to permit readers to infer order of preference, and to allow writers to express that order, without requiring that a preferred order be determined or expressed. Where there is no preferred order, there will be no harm. Where there is a preferred order, the right thing will happen. bob wyman On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones wrote: Why not have the client always offer items in the array in order? Any reason to randomly select items from the array? Paul _____ From: Melvin Carvalho Sent: Sat Aug 17 14:49:05 EDT 2013 To: Mike Jones Cc: "Paul E. Jones" , webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 17 August 2013 20:45, Mike Jones wrote: When used, the ordering can do good. When not used, it does no harm. Please leave it in. Mike, my question related to how the client can *know* when it's used and when it's not used. This seems unclear? Thanks, -- Mike From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin Carvalho Sent: Saturday, August 17, 2013 11:40 AM To: Paul E. Jones Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 17 August 2013 20:32, Paul E. Jones wrote: Melvin, We have been asked about this before. If we leave it in, it meets the needs of some. I admit there might be cases where it's hard to control order, but if it matters, there is at least a way. In my own implementation, I assign an integer value to each entry and sort on that. I have no strong objection either way, but I do think it's good to have for those who care. I understand the trade offs. However, I can see that this is useful in many cases, particularly this would work well for openid, but other use cases, eg to have a friends list, for something like a federated social web, would then be perhaps impractical with JRD (not the end of the world, though) Paul _____ From: Melvin Carvalho Sent: Sat Aug 17 14:12:11 EDT 2013 To: "Paul E. Jones" Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 9 August 2013 18:09, Paul E. Jones wrote: Folks, As we're trying to bring the WebFinger spec to a close, we published a new version -17 with some changes the WG might want to consider. Draft is: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 Those changes are: - Section 2, added a new last paragraph to explain what URI syntax we use in WebFinger - Corrected error in section 3.2 ("Host:" line in example and quotes around "3.2") - We remove the words "absolute URI" since it's really redundant - Added "query target" to 4.5 for clarity - Introduced a new section 8 that describes "WebFinger" applications. This is a major new addition. - Added a new section 10.3 and 10.4 to address registration of link relation types and properties. Link relations types already have a registry and we refer to existing procedures. WebFinger properties did not have a registry, so we define one, primarily for the purpose of helping people avoid creating redundant definitions. If you have any questions or comments, please feel free to post to the list. [[ The order of elements in the "links" array indicates an order of preference. Thus, if there are two or more link relations having the same "rel" value, the first link relation would indicate the user's preferred link. ]] Maybe remove this altogether, as I am unsure it can be guaranteed. Case 1: Let's say I have a list of friends, how am I to determine as a server the preferred friends? How am I to determine as a client whether the friends are ordered or not? Case 2: Say I mash up data from two sources, how do I then order the combined list? 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 ------=_NextPart_000_0287_01CE9CD5.EDCAEFB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

I’m OK with that change, if we’re permitted to make this = type of change now.

 

Paul

 

From:= = bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman
Sent: Saturday, August 17, 2013 5:05 PM
To: = Paul E. Jones
Cc: Melvin Carvalho; Mike Jones; = webfinger
Subject: Re: [webfinger] New WebFinger Draft = posted

 

I would = prefer if the wording didn't require that order of listing is required = to indicate a necessary order of preference. Thus, I suggest the = following wording:

The order of elements in the =
"links" array MAY be read as indicating an order of =
preference.
The idea is to permit readers =
to infer order of preference, and to allow writers to express that =
order, without requiring that a preferred order be determined or =
expressed. Where there is no preferred order, there will be no harm. =
Where there is a preferred order, the right thing will =
happen.
bob =
wyman

 

On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Why not have the client always offer items = in the array in order? Any reason to randomly select items from the = array?

Paul

 

From:= = Melvin Carvalho <melvincarvalho@gmail.com>

<= /div>

Sent:= = Sat Aug 17 14:49:05 EDT 2013
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: = "Paul E. Jones" <paulej@packetizer.com>, webfinger <webfinger@ietf.org>


Subje= ct: Re: [webfinger] New WebFinger Draft = posted

 

 

 

On 17 August 2013 20:45, Mike Jones <Michael.Jones@microsoft.com> = wrote:

When used, the ordering can do good.  When not used, it does no = harm.  Please leave it in.

 

Mike, my question related to how the client can *know* = when it's used and when it's not used.  This seems = unclear?

 

 

           &nbs= p;            = ;            =             &= nbsp;           = Thanks,

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

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Melvin Carvalho
Sent: Saturday, August 17, 2013 11:40 = AM
To: Paul E. Jones
Cc: = webfinger


Subject: Re: [webfinger] New WebFinger = Draft posted

 <= /o:p>

 <= /o:p>

 <= /p>

On 17 = August 2013 20:32, Paul E. Jones <paulej@packetizer.com> = wrote:

Melvin,

We have been asked = about this before. If we leave it in, it meets the needs of some. I = admit there might be cases where it's hard to control order, but if it = matters, there is at least a way.

In my own = implementation, I assign an integer value to each entry and sort on = that.

I have no strong objection either way, but I do = think it's good to have for those who care.

 <= /o:p>

I = understand the trade offs.  However, I can see that this is useful = in many cases, particularly this would work well for openid, but other = use cases, eg to have a friends list, for something like a federated = social web, would then be perhaps impractical with JRD (not the end of = the world, though)

 <= /o:p>

Paul

 <= /p>

From:= = Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sat = Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger = <webfinger@ietf.org>
Subject: Re: = [webfinger] New WebFinger Draft = posted

 <= /o:p>

 <= /o:p>

 <= /p>

On 9 August = 2013 18:09, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,
As we're trying to bring the WebFinger spec to a close, we published a = new
version -17 with some changes the WG might want to = consider.

Draft is:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -17

Those changes are:

- Section 2, added a new last = paragraph to explain what URI syntax we use in
WebFinger
- = Corrected error in section 3.2 ("Host:" line in example and = quotes around
"3.2")
- We remove the words = "absolute URI" since it's really redundant
- Added = "query target" to 4.5 for clarity
- Introduced a new = section 8 that describes "WebFinger" applications. =  This
is a major new addition.
- Added a new section 10.3 and = 10.4 to address registration of link relation
types and properties. =  Link relations types already have a registry and we
refer to = existing procedures.  WebFinger properties did not have a = registry,
so we define one, primarily for the purpose of helping = people avoid creating
redundant definitions.

If you have any = questions or comments, please feel free to post to the = list.


[[<= /o:p>

   The order of elements in the =
"links" array indicates an order =
of
   preference.  Thus, if there =
are two or more link relations having =
the
   same "rel" value, the =
first link relation would indicate the =
user's
   preferred =
link.

]]
 =

Maybe remove this = altogether, as I am unsure it can be = guaranteed.

Case 1: Let's say = I have a list of friends, how am I to determine as a server the = preferred friends?  How am I to determine as a client whether the = friends are ordered or not?

Case 2: Say = I mash up data from two sources, how do I then order the combined = list?

 <= /o:p>



Paul=


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

 <= /o:p>

 <= /o:p>

 


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

 

 ------=_NextPart_000_0287_01CE9CD5.EDCAEFB0-- From nick@silverbucket.net Mon Aug 19 09:21:30 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 7AAC311E8113 for ; Mon, 19 Aug 2013 09:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 UK2+H7vY5+95 for ; Mon, 19 Aug 2013 09:21:21 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id AEC3021F9371 for ; Mon, 19 Aug 2013 09:21:16 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ep20so3490944lab.16 for ; Mon, 19 Aug 2013 09:21:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0eHIBuigliEKLuGBqG4LWbA44PcpmnKbY8sKI+pA6aI=; b=OZljE8VIpbr6uoIjn1DJ89gQwIQBLMSfJN6mCQEZdIg10C5DXstn5X2i/OAafKFuG+ VPNa38gMBpJtee4w5jQFhX7VG108bCQFeDnY72xu0mEGHxRHHZ2wnu32V23DBMP7ien+ Qe+sYFmfm3ThFD9UlpCsN5bXI2EutZmeFXNMqVtrBXMCL04xf8YaS1do9SIx6bYB//wR ya8ia/PcvwQIXNcSmeiN9R40aIXNS1BJ4RhotKlmBqTiWtqAsDobxYoRGVRsCW5rhCPV T08XuBFFuuhZKI5HCuMt7fBL5goXquigWffMOT4vGLWxw1TpoRRwAlHQ6vbktPn4QlxW erMA== X-Gm-Message-State: ALoCoQlkjyFbzrO7uCpZPb6pOXAFWDjcLaEybhaZ79l7m89sieFkALp6THtMGQNUsU15CWnJsckK X-Received: by 10.152.8.115 with SMTP id q19mr13044489laa.16.1376929274351; Mon, 19 Aug 2013 09:21:14 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [2a00:1450:4010:c03::232]) by mx.google.com with ESMTPSA id rd5sm4701916lbb.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 09:21:13 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ek20so3448760lab.23 for ; Mon, 19 Aug 2013 09:21:13 -0700 (PDT) X-Received: by 10.112.52.225 with SMTP id w1mr2558661lbo.31.1376929273273; Mon, 19 Aug 2013 09:21:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.42.109 with HTTP; Mon, 19 Aug 2013 09:20:43 -0700 (PDT) In-Reply-To: <028601ce9cf7$74da6cd0$5e8f4670$@packetizer.com> References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <028601ce9cf7$74da6cd0$5e8f4670$@packetizer.com> From: Nick Jennings Date: Mon, 19 Aug 2013 18:20:43 +0200 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a11c3fe9036e48104e44f546b Cc: Bob Wyman , Mike Jones , Melvin Carvalho , webfinger Subject: Re: [webfinger] New WebFinger Draft posted 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, 19 Aug 2013 16:21:39 -0000 --001a11c3fe9036e48104e44f546b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Mon, Aug 19, 2013 at 6:16 PM, Paul E. Jones wrote= : > Bob,**** > > ** ** > > I=E2=80=99m OK with that change, if we=E2=80=99re permitted to make this = type of change > now.**** > > ** ** > > Paul**** > > ** ** > > *From:* bobwyman@gmail.com [mailto:bobwyman@gmail.com] *On Behalf Of *Bob > Wyman > *Sent:* Saturday, August 17, 2013 5:05 PM > *To:* Paul E. Jones > *Cc:* Melvin Carvalho; Mike Jones; webfinger > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > ** ** > > I would prefer if the wording didn't require that order of listing is > required to indicate a necessary order of preference. Thus, I suggest the > following wording:**** > > The order of elements in the "links" array *MAY be read as indicating* an= order of preference.**** > > The idea is to permit readers to infer order of preference, and to allow = writers to express that order, without requiring that a preferred order be = determined or expressed. Where there is no preferred order, there will be n= o harm. Where there is a preferred order, the right thing will happen.**** > > bob wyman**** > > ** ** > > On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones > wrote:**** > > Why not have the client always offer items in the array in order? Any > reason to randomly select items from the array?**** > > Paul**** > > ** ** > ------------------------------ > > *From:* Melvin Carvalho **** > > *Sent:* Sat Aug 17 14:49:05 EDT 2013 > *To:* Mike Jones > *Cc:* "Paul E. Jones" , webfinger < > webfinger@ietf.org>**** > > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > ** ** > > ** ** > > ** ** > > On 17 August 2013 20:45, Mike Jones wrote:*= * > ** > > When used, the ordering can do good. When not used, it does no harm. > Please leave it in.**** > > ** ** > > Mike, my question related to how the client can *know* when it's used and > when it's not used. This seems unclear?**** > > **** > > **** > > Thanks,**** > > -- Mike**** > > **** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Melvin Carvalho > *Sent:* Saturday, August 17, 2013 11:40 AM > *To:* Paul E. Jones > *Cc:* webfinger**** > > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > **** > > **** > > **** > > On 17 August 2013 20:32, Paul E. Jones wrote:**** > > Melvin,**** > > We have been asked about this before. If we leave it in, it meets the > needs of some. I admit there might be cases where it's hard to control > order, but if it matters, there is at least a way.**** > > In my own implementation, I assign an integer value to each entry and sor= t > on that.**** > > I have no strong objection either way, but I do think it's good to have > for those who care.**** > > **** > > I understand the trade offs. However, I can see that this is useful in > many cases, particularly this would work well for openid, but other use > cases, eg to have a friends list, for something like a federated social > web, would then be perhaps impractical with JRD (not the end of the world= , > though)**** > > **** > > Paul**** > > **** > ------------------------------ > > *From:* Melvin Carvalho > *Sent:* Sat Aug 17 14:12:11 EDT 2013 > *To:* "Paul E. Jones" > *Cc:* webfinger > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > **** > > **** > > **** > > On 9 August 2013 18:09, Paul E. Jones wrote:**** > > Folks, > > As we're trying to bring the WebFinger spec to a close, we published a ne= w > version -17 with some changes the WG might want to consider. > > Draft is: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 > > Those changes are: > > - Section 2, added a new last paragraph to explain what URI syntax we use > in > WebFinger > - Corrected error in section 3.2 ("Host:" line in example and quotes arou= nd > "3.2") > - We remove the words "absolute URI" since it's really redundant > - Added "query target" to 4.5 for clarity > - Introduced a new section 8 that describes "WebFinger" applications. Th= is > is a major new addition. > - Added a new section 10.3 and 10.4 to address registration of link > relation > types and properties. Link relations types already have a registry and w= e > refer to existing procedures. WebFinger properties did not have a > registry, > so we define one, primarily for the purpose of helping people avoid > creating > redundant definitions. > > If you have any questions or comments, please feel free to post to the > list.**** > > > [[**** > > The order of elements in the "links" array indicates an order of**** > > preference. Thus, if there are two or more link relations having the*= *** > > same "rel" value, the first link relation would indicate the user's***= * > > preferred link.**** > > ]] > **** > > Maybe remove this altogether, as I am unsure it can be guaranteed.**** > > Case 1: Let's say I have a list of friends, how am I to determine as a > server the preferred friends? How am I to determine as a client whether > the friends are ordered or not?**** > > Case 2: Say I mash up data from two sources, how do I then order the > combined list?**** > > **** > > > > 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**** > > ** ** > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --001a11c3fe9036e48104e44f546b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1


On Mon, Aug 19, 2013 at 6:16 PM, Paul E. Jones <pau= lej@packetizer.com> wrote:

Bob,

=C2=A0

I=E2=80=99m OK with= that change, if we=E2=80=99re permitted to make this type of change now.

=C2=A0

Paul<= /span>

=C2=A0

From: bobwyman@gmai= l.com [mailto:b= obwyman@gmail.com] On Behalf Of Bob Wyman
Sent: Saturday, August 17, 2013 5:05 PM
To: Paul E. Jones<= br>Cc: Melvin Carvalho; Mike Jones; webfinger


Subject: Re: [webfinger] New WebFinger Draft posted

<= /u>=C2=A0

I would prefer if the wordi= ng didn't require that order of listing is required to indicate a neces= sary order of preference. Thus, I suggest the following wording:<= /u>

The order of elements in the "=
;links" array MAY be read as indicating an order of preference.=

The idea is to=
 permit readers to infer order of preference, and to allow writers to expre=
ss that order, without requiring that a preferred order be determined or ex=
pressed. Where there is no preferred order, there will be no harm. Where th=
ere is a preferred order, the right thing will happen.=

bob wyman

=C2=A0

On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones <paulej@packetizer.com> wrote:<= /u>

Why not have the client always offer items in the arr= ay in order? Any reason to randomly select items from the array?<= /u>

Paul

=C2=A0

From: Melvin Carvalho <melvincarvalho@gmail.com>

Sent: Sa= t Aug 17 14:49:05 EDT 2013
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: "Pau= l E. Jones" <paulej@packetizer.com>, webfinger <webfinger@ietf.org>


Subject: Re: [webfi= nger] New WebFinger Draft posted

=C2=A0

=C2=A0

=C2=A0

On 17= August 2013 20:45, Mike Jones <Michael.Jones@microsoft.com> wrote:<= u>

When used, the = ordering can do good.=C2=A0 When not used, it does no harm.=C2=A0 Please le= ave it in.

=C2=A0

=

Mike, my question related to how the client can *kno= w* when it's used and when it's not used.=C2=A0 This seems unclear?=

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -- Mike

=C2=A0

From: webfinger-bounces@= ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin Carv= alho
Sent: Saturday, August 17, 2013 11:40 AM
To: Paul E. Jones=
Cc: webfinger


Subject: Re: [webfinger] New WebFinger Draft posted

=C2=A0

<= p class=3D"MsoNormal">=C2=A0

=C2=A0

On 17 August 2013 20:32, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

We have been asked about this before. I= f we leave it in, it meets the needs of some. I admit there might be cases = where it's hard to control order, but if it matters, there is at least = a way.

In my own implementation, I assign an integer value to each entry and so= rt on that.

I have no strong objection either way, but = I do think it's good to have for those who care.

=C2=A0

I understand the trade offs.=C2=A0 However, I can see that this = is useful in many cases, particularly this would work well for openid, but = other use cases, eg to have a friends list, for something like a federated = social web, would then be perhaps impractical with JRD (not the end of the = world, though)

=C2=A0

Paul

=C2=A0

From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sat Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones= " <paule= j@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted=

=C2=A0

=C2=A0

=C2=A0

On 9 August 2013 18:09,= Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

As we're trying to bring the WebFinger spec to a close, we publishe= d a new
version -17 with some changes the WG might want to consider.
=
Draft is:
http://tools.ietf.org/html/draft-ietf-appsaw= g-webfinger-17

Those changes are:

- Section 2, added a new last paragraph to ex= plain what URI syntax we use in
WebFinger
- Corrected error in sectio= n 3.2 ("Host:" line in example and quotes around
"3.2&quo= t;)
- We remove the words "absolute URI" since it's really redund= ant
- Added "query target" to 4.5 for clarity
- Introduced = a new section 8 that describes "WebFinger" applications. =C2=A0Th= is
is a major new addition.
- Added a new section 10.3 and 10.4 to address = registration of link relation
types and properties. =C2=A0Link relations= types already have a registry and we
refer to existing procedures. =C2= =A0WebFinger properties did not have a registry,
so we define one, primarily for the purpose of helping people avoid creatin= g
redundant definitions.

If you have any questions or comments, p= lease feel free to post to the list.


[[

=C2=A0=C2=A0 The order of elements in the &quo=
t;links" array indicates an order of
=C2=A0=C2=
=A0 preference.=C2=A0 Thus, if there are two or more link relations having =
the
=C2=A0=C2=A0 same "rel" value, the first link relation would=
 indicate the user's
=C2=A0=C2=A0 preferred lin=
k.

]]
=C2=A0

=

Maybe remove this altogether, as I am unsure it can be guaranteed.

C= ase 1: Let's say I have a list of friends, how am I to determine as a s= erver the preferred friends?=C2=A0 How am I to determine as a client whethe= r the friends are ordered or not?

Case 2: Say I mash up data from two sourc= es, how do I then order the combined list?

=C2=A0



Paul


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

=C2=A0

=C2=A0

=C2=A0


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

=C2=A0

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


--001a11c3fe9036e48104e44f546b-- From melvincarvalho@gmail.com Mon Aug 19 09: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 35CCA21F9C72 for ; Mon, 19 Aug 2013 09:41:07 -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 IwWLVqvzAtdG for ; Mon, 19 Aug 2013 09:41:06 -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 228E621F9A57 for ; Mon, 19 Aug 2013 09:41:04 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id 10so2028632lbf.32 for ; Mon, 19 Aug 2013 09:40:57 -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=fxNU7CWTjKn0Da2zJqm5jr1d5nvlZe0VJAImKyFLywg=; b=oVmTG1X1bOntyiF/o4auzfbhA9OuKTzC9DHSiTid5uQKWjKPBzca60W8WBfCjrMsqA IGHAIen4MHKtjv+pVZPAmUpLolcu3xtJ2sqm1ZylZRwBvZNrUEEtEe6gsrjwSU40iciM LMDYTMnzmkkDEiYMYwb0PJWYcEaVfjXLltz5iSyX92aolgAANf1CUkNZ6+hUzdSkG2Hn qtRpg3zCizom+wZmzcMjN6lU1Gof9OSw5mDVoW0GpT/f7rBLPBz15PqkjBfVfOcw5nC8 mKVUe850htUTJ5vmNre47Th97Nof3nkL5k45OZL1dCbynGrRgFZsr48+y3GLGZu9espK UxKw== MIME-Version: 1.0 X-Received: by 10.112.42.68 with SMTP id m4mr12419704lbl.4.1376930456985; Mon, 19 Aug 2013 09:40:56 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Mon, 19 Aug 2013 09:40:56 -0700 (PDT) In-Reply-To: <028601ce9cf7$74da6cd0$5e8f4670$@packetizer.com> References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <028601ce9cf7$74da6cd0$5e8f4670$@packetizer.com> Date: Mon, 19 Aug 2013 18:40:56 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a11336876c4e64604e44f9a58 Cc: Bob Wyman , Mike Jones , webfinger Subject: Re: [webfinger] New WebFinger Draft posted 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, 19 Aug 2013 16:41:07 -0000 --001a11336876c4e64604e44f9a58 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 19 August 2013 18:16, Paul E. Jones wrote: > Bob,**** > > ** ** > > I=92m OK with that change, if we=92re permitted to make this type of chan= ge > now. > I guess if it's too late it's not the end of the world. I do think Bob's change is an improvement. But I still dont quite understand how the client is supposed to know if it's dealing with an ordered list or an unordered list. > **** > > ** ** > > Paul**** > > ** ** > > *From:* bobwyman@gmail.com [mailto:bobwyman@gmail.com] *On Behalf Of *Bob > Wyman > *Sent:* Saturday, August 17, 2013 5:05 PM > *To:* Paul E. Jones > *Cc:* Melvin Carvalho; Mike Jones; webfinger > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > ** ** > > I would prefer if the wording didn't require that order of listing is > required to indicate a necessary order of preference. Thus, I suggest the > following wording:**** > > The order of elements in the "links" array *MAY be read as indicating* an= order of preference.**** > > The idea is to permit readers to infer order of preference, and to allow = writers to express that order, without requiring that a preferred order be = determined or expressed. Where there is no preferred order, there will be n= o harm. Where there is a preferred order, the right thing will happen.**** > > bob wyman**** > > ** ** > > On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones > wrote:**** > > Why not have the client always offer items in the array in order? Any > reason to randomly select items from the array?**** > > Paul**** > > ** ** > ------------------------------ > > *From:* Melvin Carvalho **** > > *Sent:* Sat Aug 17 14:49:05 EDT 2013 > *To:* Mike Jones > *Cc:* "Paul E. Jones" , webfinger < > webfinger@ietf.org>**** > > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > ** ** > > ** ** > > ** ** > > On 17 August 2013 20:45, Mike Jones wrote:*= * > ** > > When used, the ordering can do good. When not used, it does no harm. > Please leave it in.**** > > ** ** > > Mike, my question related to how the client can *know* when it's used and > when it's not used. This seems unclear?**** > > **** > > **** > > Thanks,**** > > -- Mike**** > > **** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Melvin Carvalho > *Sent:* Saturday, August 17, 2013 11:40 AM > *To:* Paul E. Jones > *Cc:* webfinger**** > > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > **** > > **** > > **** > > On 17 August 2013 20:32, Paul E. Jones wrote:**** > > Melvin,**** > > We have been asked about this before. If we leave it in, it meets the > needs of some. I admit there might be cases where it's hard to control > order, but if it matters, there is at least a way.**** > > In my own implementation, I assign an integer value to each entry and sor= t > on that.**** > > I have no strong objection either way, but I do think it's good to have > for those who care.**** > > **** > > I understand the trade offs. However, I can see that this is useful in > many cases, particularly this would work well for openid, but other use > cases, eg to have a friends list, for something like a federated social > web, would then be perhaps impractical with JRD (not the end of the world= , > though)**** > > **** > > Paul**** > > **** > ------------------------------ > > *From:* Melvin Carvalho > *Sent:* Sat Aug 17 14:12:11 EDT 2013 > *To:* "Paul E. Jones" > *Cc:* webfinger > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > **** > > **** > > **** > > On 9 August 2013 18:09, Paul E. Jones wrote:**** > > Folks, > > As we're trying to bring the WebFinger spec to a close, we published a ne= w > version -17 with some changes the WG might want to consider. > > Draft is: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 > > Those changes are: > > - Section 2, added a new last paragraph to explain what URI syntax we use > in > WebFinger > - Corrected error in section 3.2 ("Host:" line in example and quotes arou= nd > "3.2") > - We remove the words "absolute URI" since it's really redundant > - Added "query target" to 4.5 for clarity > - Introduced a new section 8 that describes "WebFinger" applications. Th= is > is a major new addition. > - Added a new section 10.3 and 10.4 to address registration of link > relation > types and properties. Link relations types already have a registry and w= e > refer to existing procedures. WebFinger properties did not have a > registry, > so we define one, primarily for the purpose of helping people avoid > creating > redundant definitions. > > If you have any questions or comments, please feel free to post to the > list.**** > > > [[**** > > The order of elements in the "links" array indicates an order of**** > > preference. Thus, if there are two or more link relations having the*= *** > > same "rel" value, the first link relation would indicate the user's***= * > > preferred link.**** > > ]] > **** > > Maybe remove this altogether, as I am unsure it can be guaranteed.**** > > Case 1: Let's say I have a list of friends, how am I to determine as a > server the preferred friends? How am I to determine as a client whether > the friends are ordered or not?**** > > Case 2: Say I mash up data from two sources, how do I then order the > combined list?**** > > **** > > > > 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**** > > ** ** > --001a11336876c4e64604e44f9a58 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On 19 August 2013 18:16, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:

Bob,

=A0<= /p>

I=92m OK with that cha= nge, if we=92re permitted to make this type of change now.


I guess if it's too late i= t's not the end of the world.

I do think Bob's ch= ange is an improvement.=A0 But I still dont quite understand how the client= is supposed to know if it's dealing with an ordered list or an unorder= ed list.=A0=A0
=A0

=A0<= /p>

Paul

=A0<= /p>

From: bobwyman@gmai= l.com [mailto:b= obwyman@gmail.com] On Behalf Of Bob Wyman
Sent: Saturday, August 17, 2013 5:05 PM
To: Paul E. Jones<= br>Cc: Melvin Carvalho; Mike Jones; webfinger


Subject: Re: [webfinger] New WebFinger Draft posted

<= /u>=A0

I would prefer if the wording = didn't require that order of listing is required to indicate a necessar= y order of preference. Thus, I suggest the following wording:= 

The order of elements in the "=
;links" array MAY be read as indicating an order of preference.=

The idea is to=
 permit readers to infer order of preference, and to allow writers to expre=
ss that order, without requiring that a preferred order be determined or ex=
pressed. Where there is no preferred order, there will be no harm. Where th=
ere is a preferred order, the right thing will happen.=

bob wyman

=A0

On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones <paulej@packetizer.com> wrote:<= /u>

Why not have the client always offer items in the arr= ay in order? Any reason to randomly select items from the array?<= /u>

Paul

=A0

From: Melvin Carvalho <melvincarvalho@gmail.com>

Sent: Sa= t Aug 17 14:49:05 EDT 2013
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: "Pau= l E. Jones" <paulej@packetizer.com>, webfinger <webfinger@ietf.org>


Subject: Re: [webfi= nger] New WebFinger Draft posted

=A0

=A0

=A0

On 17 August 2= 013 20:45, Mike Jones <Michael.Jones@microsoft.com> wrote:

When used, the = ordering can do good.=A0 When not used, it does no harm.=A0 Please leave it= in.

=A0

Mike, my question related to how the client can *know* = when it's used and when it's not used.=A0 This seems unclear?

=A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Thanks,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0=

From: webfinger-bounces@= ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin Carv= alho
Sent: Saturday, August 17, 2013 11:40 AM
To: Paul E. Jones=
Cc: webfinger


Subject: Re: [webfinger] New WebFinger Draft posted

=A0

=A0

=A0

= On 17 August 2013 20:32, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

We have been asked about this before. I= f we leave it in, it meets the needs of some. I admit there might be cases = where it's hard to control order, but if it matters, there is at least = a way.

In my own implementation, I assign an integer value to each entry and so= rt on that.

I have no strong objection either way, but = I do think it's good to have for those who care.

=A0

I understand the trade offs.=A0 However, I can see that this is use= ful in many cases, particularly this would work well for openid, but other = use cases, eg to have a friends list, for something like a federated social= web, would then be perhaps impractical with JRD (not the end of the world,= though)

=A0

=

Paul

=A0

From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sat Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones= " <paule= j@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted=

=A0

=A0

=A0

On 9 August 2013 18:09, Pa= ul E. Jones <= paulej@packetizer.com> wrote:

Folks,

As we're trying to bring the WebFinger spec to a close, we publishe= d a new
version -17 with some changes the WG might want to consider.
=
Draft is:
http://tools.ietf.org/html/draft-ietf-appsaw= g-webfinger-17

Those changes are:

- Section 2, added a new last paragraph to ex= plain what URI syntax we use in
WebFinger
- Corrected error in sectio= n 3.2 ("Host:" line in example and quotes around
"3.2&quo= t;)
- We remove the words "absolute URI" since it's really redund= ant
- Added "query target" to 4.5 for clarity
- Introduced = a new section 8 that describes "WebFinger" applications. =A0This<= br> is a major new addition.
- Added a new section 10.3 and 10.4 to address = registration of link relation
types and properties. =A0Link relations ty= pes already have a registry and we
refer to existing procedures. =A0WebF= inger properties did not have a registry,
so we define one, primarily for the purpose of helping people avoid creatin= g
redundant definitions.

If you have any questions or comments, p= lease feel free to post to the list.


[[

=A0=A0 The order of elements in the "link=
s" array indicates an order of
=A0=A0 preferen=
ce.=A0 Thus, if there are two or more link relations having the
=A0=A0 same "rel" value, the first link relation would indic=
ate the user's
=A0=A0 preferred link.=

]]
=A0

Maybe remove this altogether, as I am unsure it can be guaranteed.

C= ase 1: Let's say I have a list of friends, how am I to determine as a s= erver the preferred friends?=A0 How am I to determine as a client whether t= he friends are ordered or not?

Case 2: Say I mash up data from two sourc= es, how do I then order the combined list?

=A0



Paul


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

=A0

=

=A0

=A0


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

=A0


--001a11336876c4e64604e44f9a58-- From paulej@packetizer.com Mon Aug 19 10:01:32 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 3C9A911E812B for ; Mon, 19 Aug 2013 10:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 FVaOBlRSrvnx for ; Mon, 19 Aug 2013 10:01:27 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 700C711E80DF for ; Mon, 19 Aug 2013 10:01:27 -0700 (PDT) Received: from sydney (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 r7JH1PHe020379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Aug 2013 13:01:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1376931686; bh=q8CoF1RqO0sazOQwyajJSMopGUgXDB1FZd1WSsjNDMw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=h7FmkJBmy2w3RP2XSlDXVC4erV1yVVP/7MSOi4e2mE7Rn2MoZSd7v/d98pyhie2i9 aYEYcxf4NQVNZvNSFF5qyr1lwroeL+JdFV3VyS8yWLEMsE99wJ+2gaWEZnubn8wFRG 2sKvS3J4QkMAszKD02MUzRV9ba2JLDlbiTLv4mWw= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <028601ce9cf7$74da6cd0$5e8f4670$@packetizer.com> In-Reply-To: Date: Mon, 19 Aug 2013 13:01:36 -0400 Message-ID: <02c701ce9cfd$c441ab20$4cc50160$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C8_01CE9CDC.3D325510" X-Mailer: Microsoft Outlook 14.0 thread-index: AQIRsulmUP4nxla1qQgQS/ZK2x+2zAK8b0g/AfMzvyICFml4JQLBB8OAAfhMdnoCd1cdhwFCqMITAqp4nHsA6F1BWJiAMPZw Content-Language: en-us Cc: 'Bob Wyman' , 'Mike Jones' , 'webfinger' Subject: Re: [webfinger] New WebFinger Draft posted 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, 19 Aug 2013 17:01:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02C8_01CE9CDC.3D325510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, Items in a JSON array are ordered by definition, so adding this language actually does not change the fact that the list is ordered. What it does, though, is remind people that if they have information they would like to prioritize, they can take advantage of the fact that arrays are ordered. So to answer your question, clients always know the links array is ordered :) If I have two avatars that I would like to make available, do I care which one is selected? If I do, then I should ensure the preferred avatar is first. If I do not, then it does not matter about order. That said, it should be understood that some clients are likely to select the first avatar it encounters and some clients might not even look further in the array to see if there are alternatives. Other clients, though, might actually offer all alternative avatars. Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Monday, August 19, 2013 12:41 PM To: Paul E. Jones Cc: Bob Wyman; Mike Jones; webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 19 August 2013 18:16, Paul E. Jones wrote: Bob, I'm OK with that change, if we're permitted to make this type of change now. I guess if it's too late it's not the end of the world. I do think Bob's change is an improvement. But I still dont quite understand how the client is supposed to know if it's dealing with an ordered list or an unordered list. Paul From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman Sent: Saturday, August 17, 2013 5:05 PM To: Paul E. Jones Cc: Melvin Carvalho; Mike Jones; webfinger Subject: Re: [webfinger] New WebFinger Draft posted I would prefer if the wording didn't require that order of listing is required to indicate a necessary order of preference. Thus, I suggest the following wording: The order of elements in the "links" array MAY be read as indicating an order of preference. The idea is to permit readers to infer order of preference, and to allow writers to express that order, without requiring that a preferred order be determined or expressed. Where there is no preferred order, there will be no harm. Where there is a preferred order, the right thing will happen. bob wyman On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones wrote: Why not have the client always offer items in the array in order? Any reason to randomly select items from the array? Paul _____ From: Melvin Carvalho Sent: Sat Aug 17 14:49:05 EDT 2013 To: Mike Jones Cc: "Paul E. Jones" , webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 17 August 2013 20:45, Mike Jones wrote: When used, the ordering can do good. When not used, it does no harm. Please leave it in. Mike, my question related to how the client can *know* when it's used and when it's not used. This seems unclear? Thanks, -- Mike From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin Carvalho Sent: Saturday, August 17, 2013 11:40 AM To: Paul E. Jones Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 17 August 2013 20:32, Paul E. Jones wrote: Melvin, We have been asked about this before. If we leave it in, it meets the needs of some. I admit there might be cases where it's hard to control order, but if it matters, there is at least a way. In my own implementation, I assign an integer value to each entry and sort on that. I have no strong objection either way, but I do think it's good to have for those who care. I understand the trade offs. However, I can see that this is useful in many cases, particularly this would work well for openid, but other use cases, eg to have a friends list, for something like a federated social web, would then be perhaps impractical with JRD (not the end of the world, though) Paul _____ From: Melvin Carvalho Sent: Sat Aug 17 14:12:11 EDT 2013 To: "Paul E. Jones" Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 9 August 2013 18:09, Paul E. Jones wrote: Folks, As we're trying to bring the WebFinger spec to a close, we published a new version -17 with some changes the WG might want to consider. Draft is: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 Those changes are: - Section 2, added a new last paragraph to explain what URI syntax we use in WebFinger - Corrected error in section 3.2 ("Host:" line in example and quotes around "3.2") - We remove the words "absolute URI" since it's really redundant - Added "query target" to 4.5 for clarity - Introduced a new section 8 that describes "WebFinger" applications. This is a major new addition. - Added a new section 10.3 and 10.4 to address registration of link relation types and properties. Link relations types already have a registry and we refer to existing procedures. WebFinger properties did not have a registry, so we define one, primarily for the purpose of helping people avoid creating redundant definitions. If you have any questions or comments, please feel free to post to the list. [[ The order of elements in the "links" array indicates an order of preference. Thus, if there are two or more link relations having the same "rel" value, the first link relation would indicate the user's preferred link. ]] Maybe remove this altogether, as I am unsure it can be guaranteed. Case 1: Let's say I have a list of friends, how am I to determine as a server the preferred friends? How am I to determine as a client whether the friends are ordered or not? Case 2: Say I mash up data from two sources, how do I then order the combined list? 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 ------=_NextPart_000_02C8_01CE9CDC.3D325510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

Items in a JSON array are ordered by definition, so adding this = language actually does not change the fact that the list is = ordered.  What it does, though, is remind people that if they have = information they would like to prioritize, they can take advantage of = the fact that arrays are ordered.

 

So to answer your question, clients always know the links array is = ordered :)

 

If I have two avatars that I would like to make available, do I care = which one is selected?  If I do, then I should ensure the preferred = avatar is first.  If I do not, then it does not matter about = order.  That said, it should be understood that some clients are = likely to select the first avatar it encounters and some clients might = not even look further in the array to see if there are = alternatives.  Other clients, though, might actually offer all = alternative avatars.

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Monday, August 19, 2013 12:41 PM
To: Paul E. = Jones
Cc: Bob Wyman; Mike Jones; webfinger
Subject: = Re: [webfinger] New WebFinger Draft = posted

 

 

 

On 19 August 2013 18:16, Paul E. Jones <paulej@packetizer.com> = wrote:

Bob,

 

I’m OK with that change, if we’re permitted to make this = type of change now.

 

I guess if it's too late it's not the end = of the world.

I do think = Bob's change is an improvement.  But I still dont quite understand = how the client is supposed to know if it's dealing with an ordered list = or an unordered list.  

 

 

Paul

 

From:= = bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman
Sent: Saturday, August 17, 2013 5:05 PM
To: = Paul E. Jones
Cc: Melvin Carvalho; Mike Jones; = webfinger


Subject: Re: [webfinger] New WebFinger = Draft posted

 <= /o:p>

I would = prefer if the wording didn't require that order of listing is required = to indicate a necessary order of preference. Thus, I suggest the = following wording:

The order of elements in the =
"links" array MAY be read as indicating an order of =
preference.
The idea is to permit readers =
to infer order of preference, and to allow writers to express that =
order, without requiring that a preferred order be determined or =
expressed. Where there is no preferred order, there will be no harm. =
Where there is a preferred order, the right thing will =
happen.
bob =
wyman

 <= /o:p>

On Sat, Aug = 17, 2013 at 4:29 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Why not have the client always offer items = in the array in order? Any reason to randomly select items from the = array?

Paul

 <= /p>

From:= = Melvin Carvalho <melvincarvalho@gmail.com>

<= /div>

Sent:= = Sat Aug 17 14:49:05 EDT 2013
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: = "Paul E. Jones" <paulej@packetizer.com>, webfinger <webfinger@ietf.org>


Subje= ct: Re: [webfinger] New WebFinger Draft = posted

 <= /o:p>

 <= /o:p>

 <= /p>

On 17 = August 2013 20:45, Mike Jones <Michael.Jones@microsoft.com> = wrote:

When used, the ordering can do good.  When not used, it does no = harm.  Please leave it in.

 <= /o:p>

Mike, my = question related to how the client can *know* when it's used and when = it's not used.  This seems unclear?

 <= /o:p>

 

           &nbs= p;            = ;            =             &= nbsp;           = Thanks,

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

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Melvin Carvalho
Sent: Saturday, August 17, 2013 11:40 = AM
To: Paul E. Jones
Cc: = webfinger


Subje= ct: Re: [webfinger] New WebFinger Draft = posted

 <= /o:p>

 <= /o:p>

 <= /p>

On 17 = August 2013 20:32, Paul E. Jones <paulej@packetizer.com> = wrote:

Melvin,

We have been asked = about this before. If we leave it in, it meets the needs of some. I = admit there might be cases where it's hard to control order, but if it = matters, there is at least a way.

In my own = implementation, I assign an integer value to each entry and sort on = that.

I have no strong objection either way, but I do = think it's good to have for those who care.

 <= /o:p>

I = understand the trade offs.  However, I can see that this is useful = in many cases, particularly this would work well for openid, but other = use cases, eg to have a friends list, for something like a federated = social web, would then be perhaps impractical with JRD (not the end of = the world, though)

 <= /o:p>

Paul

 <= /p>

From:= = Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sat = Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger = <webfinger@ietf.org>
Subject: Re: = [webfinger] New WebFinger Draft = posted

 <= /o:p>

 <= /o:p>

 <= /p>

On 9 August = 2013 18:09, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,
As we're trying to bring the WebFinger spec to a close, we published a = new
version -17 with some changes the WG might want to = consider.

Draft is:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -17

Those changes are:

- Section 2, added a new last = paragraph to explain what URI syntax we use in
WebFinger
- = Corrected error in section 3.2 ("Host:" line in example and = quotes around
"3.2")
- We remove the words = "absolute URI" since it's really redundant
- Added = "query target" to 4.5 for clarity
- Introduced a new = section 8 that describes "WebFinger" applications. =  This
is a major new addition.
- Added a new section 10.3 and = 10.4 to address registration of link relation
types and properties. =  Link relations types already have a registry and we
refer to = existing procedures.  WebFinger properties did not have a = registry,
so we define one, primarily for the purpose of helping = people avoid creating
redundant definitions.

If you have any = questions or comments, please feel free to post to the = list.


[[<= /o:p>

   The order of elements in the =
"links" array indicates an order =
of
   preference.  Thus, if there =
are two or more link relations having =
the
   same "rel" value, the =
first link relation would indicate the =
user's
   preferred =
link.

]]
 =

Maybe remove this = altogether, as I am unsure it can be = guaranteed.

Case 1: Let's say = I have a list of friends, how am I to determine as a server the = preferred friends?  How am I to determine as a client whether the = friends are ordered or not?

Case 2: Say = I mash up data from two sources, how do I then order the combined = list?

 <= /o:p>



Paul=


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

 <= /o:p>

 <= /o:p>

 <= /o:p>


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

 <= /o:p>

 

------=_NextPart_000_02C8_01CE9CDC.3D325510-- From Michael.Jones@microsoft.com Mon Aug 19 10:07: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 B8C4111E8119 for ; Mon, 19 Aug 2013 10:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.082, 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 R+ZvO91+QMzw for ; Mon, 19 Aug 2013 10:07:35 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA6411E8108 for ; Mon, 19 Aug 2013 10:07:35 -0700 (PDT) Received: from BLUPR03CA031.namprd03.prod.outlook.com (10.141.30.24) by BLUPR03MB019.namprd03.prod.outlook.com (10.255.208.41) with Microsoft SMTP Server (TLS) id 15.0.745.25; Mon, 19 Aug 2013 16:52:31 +0000 Received: from BY2FFO11FD025.protection.gbl (2a01:111:f400:7c0c::25) by BLUPR03CA031.outlook.office365.com (2a01:111:e400:879::24) with Microsoft SMTP Server (TLS) id 15.0.745.25 via Frontend Transport; Mon, 19 Aug 2013 16:52:31 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD025.mail.protection.outlook.com (10.1.15.214) with Microsoft SMTP Server (TLS) id 15.0.745.15 via Frontend Transport; Mon, 19 Aug 2013 16:52:30 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.178]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0136.001; Mon, 19 Aug 2013 16:51:01 +0000 From: Mike Jones To: Melvin Carvalho , "Paul E. Jones" Thread-Topic: [webfinger] New WebFinger Draft posted Thread-Index: Ac6VGZcQqZ04lDZOR3WbbyXqRiI0pQGW7PSAAAC0AYAAAEkEgAAAKU/QAAAjlYAAA4XRgAABORMAAFqBhQAAANsMAAAAKuXQ Date: Mon, 19 Aug 2013 16:51:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436B7C3047@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <028601ce9cf7$74da6cd0$5e8f4670$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436B7C3047TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52044002)(377454003)(25584003)(24454002)(199002)(164054003)(189002)(46102001)(512954002)(80022001)(66066001)(81342001)(65816001)(47736001)(81542001)(50986001)(49866001)(77096001)(33656001)(69226001)(56816003)(71186001)(4396001)(47976001)(81816001)(76786001)(63696002)(76796001)(20776003)(74706001)(77982001)(59766001)(19580405001)(54356001)(55846006)(53806001)(74366001)(56776001)(54316002)(74876001)(81686001)(76482001)(31966008)(74662001)(44976005)(15202345003)(74502001)(47446002)(79102001)(19580385001)(83322001)(83072001)(80976001)(6806004)(19300405004)(51856001)(16236675002)(19580395003); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB019; H:mail.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 09435FCA72 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 131.107.125.37 X-MS-Exchange-CrossPremises-AuthSource: BY2FFO11FD025.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: BLUPR03MB019.namprd03.prod.outlook.com Cc: Bob Wyman , webfinger Subject: Re: [webfinger] New WebFinger Draft posted 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, 19 Aug 2013 17:07:40 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436B7C3047TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not OK making this change. Expressing an order of preference is useful= semantics and we shouldn't remove it. No the handling of it isn't guarant= eed (it's a *preference*, not a hard requirement), but it's still useful as= -is. We're resolving the last IESG comments now. It seems pretty late to be ask= ing for non-essential changes - especially when they degrade functionality. -- Mike From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Monday, August 19, 2013 9:41 AM To: Paul E. Jones Cc: Bob Wyman; Mike Jones; webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 19 August 2013 18:16, Paul E. Jones > wrote: Bob, I'm OK with that change, if we're permitted to make this type of change now= . I guess if it's too late it's not the end of the world. I do think Bob's change is an improvement. But I still dont quite understa= nd how the client is supposed to know if it's dealing with an ordered list = or an unordered list. Paul From: bobwyman@gmail.com [mailto:bobwyman@gmail.= com] On Behalf Of Bob Wyman Sent: Saturday, August 17, 2013 5:05 PM To: Paul E. Jones Cc: Melvin Carvalho; Mike Jones; webfinger Subject: Re: [webfinger] New WebFinger Draft posted I would prefer if the wording didn't require that order of listing is requi= red to indicate a necessary order of preference. Thus, I suggest the follow= ing wording: The order of elements in the "links" array MAY be read as indicating an ord= er of preference. The idea is to permit readers to infer order of preference, and to allow wr= iters to express that order, without requiring that a preferred order be de= termined or expressed. Where there is no preferred order, there will be no = harm. Where there is a preferred order, the right thing will happen. bob wyman On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones > wrote: Why not have the client always offer items in the array in order? Any reaso= n to randomly select items from the array? Paul ________________________________ From: Melvin Carvalho > Sent: Sat Aug 17 14:49:05 EDT 2013 To: Mike Jones > Cc: "Paul E. Jones" >, = webfinger > Subject: Re: [webfinger] New WebFinger Draft posted On 17 August 2013 20:45, Mike Jones > wrote: When used, the ordering can do good. When not used, it does no harm. Plea= se leave it in. Mike, my question related to how the client can *know* when it's used and w= hen it's not used. This seems unclear? Thanks, -- Mike From: webfinger-bounces@ietf.org [mailto= :webfinger-bounces@ietf.org] On Behalf O= f Melvin Carvalho Sent: Saturday, August 17, 2013 11:40 AM To: Paul E. Jones Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 17 August 2013 20:32, Paul E. Jones > wrote: Melvin, We have been asked about this before. If we leave it in, it meets the needs= of some. I admit there might be cases where it's hard to control order, bu= t if it matters, there is at least a way. In my own implementation, I assign an integer value to each entry and sort = on that. I have no strong objection either way, but I do think it's good to have for= those who care. I understand the trade offs. However, I can see that this is useful in man= y cases, particularly this would work well for openid, but other use cases,= eg to have a friends list, for something like a federated social web, woul= d then be perhaps impractical with JRD (not the end of the world, though) Paul ________________________________ From: Melvin Carvalho > Sent: Sat Aug 17 14:12:11 EDT 2013 To: "Paul E. Jones" > Cc: webfinger > Subject: Re: [webfinger] New WebFinger Draft posted On 9 August 2013 18:09, Paul E. Jones > wrote: Folks, As we're trying to bring the WebFinger spec to a close, we published a new version -17 with some changes the WG might want to consider. Draft is: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 Those changes are: - Section 2, added a new last paragraph to explain what URI syntax we use i= n WebFinger - Corrected error in section 3.2 ("Host:" line in example and quotes around "3.2") - We remove the words "absolute URI" since it's really redundant - Added "query target" to 4.5 for clarity - Introduced a new section 8 that describes "WebFinger" applications. This is a major new addition. - Added a new section 10.3 and 10.4 to address registration of link relatio= n types and properties. Link relations types already have a registry and we refer to existing procedures. WebFinger properties did not have a registry= , so we define one, primarily for the purpose of helping people avoid creatin= g redundant definitions. If you have any questions or comments, please feel free to post to the list= . [[ The order of elements in the "links" array indicates an order of preference. Thus, if there are two or more link relations having the same "rel" value, the first link relation would indicate the user's preferred link. ]] Maybe remove this altogether, as I am unsure it can be guaranteed. Case 1: Let's say I have a list of friends, how am I to determine as a serv= er the preferred friends? How am I to determine as a client whether the fr= iends are ordered or not? Case 2: Say I mash up data from two sources, how do I then order the combin= ed list? 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 --_000_4E1F6AAD24975D4BA5B16804296739436B7C3047TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not OK making t= his change.  Expressing an order of preference is useful semantics and= we shouldn’t remove it.  No the handling of it isn’t guar= anteed (it’s a *preference*, not a hard requirement), but it’s still usefu= l as-is.

 <= /p>

We’re resolving the= last IESG comments now.  It seems pretty late to be asking for non-es= sential changes – especially when they degrade functionality.

 <= /p>

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

 <= /p>

From: Melvin C= arvalho [mailto:melvincarvalho@gmail.com]
Sent: Monday, August 19, 2013 9:41 AM
To: Paul E. Jones
Cc: Bob Wyman; Mike Jones; webfinger
Subject: Re: [webfinger] New WebFinger Draft posted

 

 

 

On 19 August 2013 18:16, Paul E. Jones <paulej@packetizer.com> wrote:

Bob,

 

I’m OK with that change, if we= 217;re permitted to make this type of change now.

 

I guess if it's too l= ate it's not the end of the world.

I do think Bob's change is an improvement.  But= I still dont quite understand how the client is supposed to know if it's d= ealing with an ordered list or an unordered list.  

 

 

Paul

 

From: bobwyman@gmail.com<= /a> [mailto:bobwyma= n@gmail.com] On Behalf Of Bob Wyman
Sent: Saturday, August 17, 2013 5:05 PM
To: Paul E. Jones
Cc: Melvin Carvalho; Mike Jones; webfinger


Subject: Re: [webfinger] New WebFinger Draft posted

 

I would prefer if the wording didn't require that order of listing= is required to indicate a necessary order of preference. Thus, I suggest t= he following wording:

The order of elements in the "link=
s" array MAY be read as indicating an order of preference.=

The idea is to permit readers to infer order =
of preference, and to allow writers to express that order, without requirin=
g that a preferred order be determined or expressed. Where there is no pref=
erred order, there will be no harm. Where there is a preferred order, the r=
ight thing will happen.
bob wyman

 

On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones <paulej@packetizer.com> w= rote:

Why not have the client always offer items in the array in order? Any re= ason to randomly select items from the array?

Paul

 

From: Melvin Carvalho <melvincarvalho@= gmail.com>

Sent: Sat Aug 17 14:49:05 ED= T 2013
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: "Paul E. Jones" <paulej@packetizer.com>, webfinger <webfinger@ietf.org&g= t;


Subject: Re: [webfinger] New WebFinger Draft posted

 

 

 

On 17 August 2013 20:45, Mike Jones <Michael.Jones@microsoft.com> = wrote:

When used, the ordering can do good.&nb= sp; When not used, it does no harm.  Please leave it in.

 

Mike, my question related to how the client can *know* when it's u= sed and when it's not used.  This seems unclear?

 

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   Thanks,

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   -- Mike

 

From: webfinger-b= ounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin Carvalho
Sent: Saturday, August 17, 2013 11:40 AM
To: Paul E. Jones
Cc: webfinger


Subject: Re: [webfinger] New WebFinger Draft posted

 

 

 

On 17 August 2013 20:32, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

We have been asked about this before. If we leave it in, it meets the ne= eds of some. I admit there might be cases where it's hard to control order,= but if it matters, there is at least a way.

In my own implementation, I assign an integer value to each entry and so= rt on that.

I have no strong objection either way, but I do think it's good to have = for those who care.

 

I understand the trade offs.  However, I can see that this is= useful in many cases, particularly this would work well for openid, but ot= her use cases, eg to have a friends list, for something like a federated social web, would then be perhaps impractic= al with JRD (not the end of the world, though)

 

Paul

 

From: Melvin Carvalho <melvincarvalho@= gmail.com>
Sent: Sat Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted

 

 

 

On 9 August 2013 18:09, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

As we're trying to bring the WebFinger spec to a close, we published a new<= br> version -17 with some changes the WG might want to consider.

Draft is:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17

Those changes are:

- Section 2, added a new last paragraph to explain what URI syntax we use i= n
WebFinger
- Corrected error in section 3.2 ("Host:" line in example and quo= tes around
"3.2")
- We remove the words "absolute URI" since it's really redundant<= br> - Added "query target" to 4.5 for clarity
- Introduced a new section 8 that describes "WebFinger" applicati= ons.  This
is a major new addition.
- Added a new section 10.3 and 10.4 to address registration of link relatio= n
types and properties.  Link relations types already have a registry an= d we
refer to existing procedures.  WebFinger properties did not have a reg= istry,
so we define one, primarily for the purpose of helping people avoid creatin= g
redundant definitions.

If you have any questions or comments, please feel free to post to the list= .


[[

   The order of elements in the "links" array indi=
cates an order of
   preference.  Thus, if there are two or more link rel=
ations having the
   same "rel" value, the first link relation would=
 indicate the user's
   preferred link.

]]
 

Maybe remove this altogether, as I am unsure it can be guaranteed.<= /o:p>

Case 1: Let's say I have a list of friends, how am I to determine as a s= erver the preferred friends?  How am I to determine as a client whethe= r the friends are ordered or not?

Case 2: Say I mash up data from two sources, how do I then order t= he combined list?

 



Paul


_______________________________________________
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

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436B7C3047TK5EX14MBXC283r_-- From melvincarvalho@gmail.com Mon Aug 19 10:28: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 0652D11E8130 for ; Mon, 19 Aug 2013 10:28:42 -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 va2S5nJoY2XL for ; Mon, 19 Aug 2013 10:28:40 -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 0544F11E8133 for ; Mon, 19 Aug 2013 10:28:39 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id a16so826622lbj.25 for ; Mon, 19 Aug 2013 10:28:38 -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=9EPR3291be7DiVKzmr0nDbibUVlio57b3nahsQNlMOY=; b=pN5/bWEk6EEySLu8hEjWYc/pa7e1d+4s6OOOCy8lQxAqlLlNX8UjDuvECSl8FDK98j 0pRN+jpo351CKCkweU8+krwkb4+t1i4VqGieVfxWwAzgLC7NBLgQQI0R1NVppZxNct01 PhZsiJypkvdBJEMn1VRPiV6ENOQzCbieABBovVIPEmh0NBp7AYH7LsRdM1bwV4H0PaXd NF4JGFlT94cy3c/hyXveiy86FFvLHdzNFtvgQDND+fhQVVJorKWLSetr02CmcS+m5VvL xsCTXmnBqD9QTdU+L+QnsTiKzU+De4gVAU4RLuyrtXt/9IhjCbGDYCwyZF7aB5nXha7S 6nHA== MIME-Version: 1.0 X-Received: by 10.152.22.198 with SMTP id g6mr13012619laf.5.1376933317711; Mon, 19 Aug 2013 10:28:37 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Mon, 19 Aug 2013 10:28:37 -0700 (PDT) In-Reply-To: <02c701ce9cfd$c441ab20$4cc50160$@packetizer.com> References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <028601ce9cf7$74da6cd0$5e8f4670$@packetizer.com> <02c701ce9cfd$c441ab20$4cc50160$@packetizer.com> Date: Mon, 19 Aug 2013 19:28:37 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e0160bab0481b7604e45045c6 Cc: Bob Wyman , Mike Jones , webfinger Subject: Re: [webfinger] New WebFinger Draft posted 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, 19 Aug 2013 17:28:42 -0000 --089e0160bab0481b7604e45045c6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 19 August 2013 19:01, Paul E. Jones wrote: > Melvin,**** > > ** ** > > Items in a JSON array are ordered by definition, so adding this language > actually does not change the fact that the list is ordered. What it does= , > though, is remind people that if they have information they would like to > prioritize, they can take advantage of the fact that arrays are ordered.*= * > ** > > ** ** > > So to answer your question, clients always know the links array is ordere= d > :)**** > > ** ** > > If I have two avatars that I would like to make available, do I care whic= h > one is selected? If I do, then I should ensure the preferred avatar is > first. If I do not, then it does not matter about order. That said, it > should be understood that some clients are likely to select the first > avatar it encounters and some clients might not even look further in the > array to see if there are alternatives. Other clients, though, might > actually offer all alternative avatars. > Thanks for the explanation, I think I get this. So, as a client, lists are ordered by preference. As a server should order lists according to the information it has. If it has that information, or the preference order is not important, then we're good. As a server if the order *is* important and we dont have preference information, probably best to send nothing? > **** > > ** ** > > Paul**** > > ** ** > > *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com] > *Sent:* Monday, August 19, 2013 12:41 PM > *To:* Paul E. Jones > *Cc:* Bob Wyman; Mike Jones; webfinger > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > ** ** > > ** ** > > ** ** > > On 19 August 2013 18:16, Paul E. Jones wrote:**** > > Bob,**** > > **** > > I=92m OK with that change, if we=92re permitted to make this type of chan= ge > now.**** > > ** ** > > I guess if it's too late it's not the end of the world.**** > > I do think Bob's change is an improvement. But I still dont quite > understand how the client is supposed to know if it's dealing with an > ordered list or an unordered list. **** > > **** > > **** > > Paul**** > > **** > > *From:* bobwyman@gmail.com [mailto:bobwyman@gmail.com] *On Behalf Of *Bob > Wyman > *Sent:* Saturday, August 17, 2013 5:05 PM > *To:* Paul E. Jones > *Cc:* Melvin Carvalho; Mike Jones; webfinger**** > > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > **** > > I would prefer if the wording didn't require that order of listing is > required to indicate a necessary order of preference. Thus, I suggest the > following wording:**** > > The order of elements in the "links" array *MAY be read as indicating* an= order of preference.**** > > The idea is to permit readers to infer order of preference, and to allow = writers to express that order, without requiring that a preferred order be = determined or expressed. Where there is no preferred order, there will be n= o harm. Where there is a preferred order, the right thing will happen.**** > > bob wyman**** > > **** > > On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones > wrote:**** > > Why not have the client always offer items in the array in order? Any > reason to randomly select items from the array?**** > > Paul**** > > **** > ------------------------------ > > *From:* Melvin Carvalho **** > > *Sent:* Sat Aug 17 14:49:05 EDT 2013 > *To:* Mike Jones > *Cc:* "Paul E. Jones" , webfinger < > webfinger@ietf.org>**** > > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > **** > > **** > > **** > > On 17 August 2013 20:45, Mike Jones wrote:*= * > ** > > When used, the ordering can do good. When not used, it does no harm. > Please leave it in.**** > > **** > > Mike, my question related to how the client can *know* when it's used and > when it's not used. This seems unclear?**** > > **** > > **** > > Thanks,**** > > -- Mike**** > > **** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Melvin Carvalho > *Sent:* Saturday, August 17, 2013 11:40 AM > *To:* Paul E. Jones > *Cc:* webfinger**** > > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > **** > > **** > > **** > > On 17 August 2013 20:32, Paul E. Jones wrote:**** > > Melvin,**** > > We have been asked about this before. If we leave it in, it meets the > needs of some. I admit there might be cases where it's hard to control > order, but if it matters, there is at least a way.**** > > In my own implementation, I assign an integer value to each entry and sor= t > on that.**** > > I have no strong objection either way, but I do think it's good to have > for those who care.**** > > **** > > I understand the trade offs. However, I can see that this is useful in > many cases, particularly this would work well for openid, but other use > cases, eg to have a friends list, for something like a federated social > web, would then be perhaps impractical with JRD (not the end of the world= , > though)**** > > **** > > Paul**** > > **** > ------------------------------ > > *From:* Melvin Carvalho > *Sent:* Sat Aug 17 14:12:11 EDT 2013 > *To:* "Paul E. Jones" > *Cc:* webfinger > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > **** > > **** > > **** > > On 9 August 2013 18:09, Paul E. Jones wrote:**** > > Folks, > > As we're trying to bring the WebFinger spec to a close, we published a ne= w > version -17 with some changes the WG might want to consider. > > Draft is: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 > > Those changes are: > > - Section 2, added a new last paragraph to explain what URI syntax we use > in > WebFinger > - Corrected error in section 3.2 ("Host:" line in example and quotes arou= nd > "3.2") > - We remove the words "absolute URI" since it's really redundant > - Added "query target" to 4.5 for clarity > - Introduced a new section 8 that describes "WebFinger" applications. Th= is > is a major new addition. > - Added a new section 10.3 and 10.4 to address registration of link > relation > types and properties. Link relations types already have a registry and w= e > refer to existing procedures. WebFinger properties did not have a > registry, > so we define one, primarily for the purpose of helping people avoid > creating > redundant definitions. > > If you have any questions or comments, please feel free to post to the > list.**** > > > [[**** > > The order of elements in the "links" array indicates an order of**** > > preference. Thus, if there are two or more link relations having the*= *** > > same "rel" value, the first link relation would indicate the user's***= * > > preferred link.**** > > ]] > **** > > Maybe remove this altogether, as I am unsure it can be guaranteed.**** > > Case 1: Let's say I have a list of friends, how am I to determine as a > server the preferred friends? How am I to determine as a client whether > the friends are ordered or not?**** > > Case 2: Say I mash up data from two sources, how do I then order the > combined list?**** > > **** > > > > 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**** > > **** > > ** ** > --089e0160bab0481b7604e45045c6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On 19 August 2013 19:01, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:

Melvin,

=A0<= /p>

Items in a JSON array = are ordered by definition, so adding this language actually does not change= the fact that the list is ordered.=A0 What it does, though, is remind peop= le that if they have information they would like to prioritize, they can ta= ke advantage of the fact that arrays are ordered.

=A0<= /p>

So to answer your ques= tion, clients always know the links array is ordered :)

=A0<= /p>

If I have two avatars = that I would like to make available, do I care which one is selected?=A0 If= I do, then I should ensure the preferred avatar is first.=A0 If I do not, = then it does not matter about order.=A0 That said, it should be understood = that some clients are likely to select the first avatar it encounters and s= ome clients might not even look further in the array to see if there are al= ternatives.=A0 Other clients, though, might actually offer all alternative = avatars.


Thanks for the explanation, I = think I get this.

So, as a client, lists are ordered by preference.<= br>
As a server should order lists according to the informati= on it has.=A0 If it has that information, or the preference order is not im= portant, then we're good.=A0

As a server if the order *is* important and we dont have preference inf= ormation, probably best to send nothing?=A0

=A0

=A0

Paul=

=A0

From:= Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: Monday, August 19, 2013 12:41 PM
To: Paul E. JonesCc: Bob Wyman; Mike Jones; webfinger


Subject: Re: [webfinger] New WebFinger Draft posted

<= /u>=A0

=A0

=A0

On 19 August 2013 18:16, Paul E. Jones <paulej@packetizer.com> wrote:

Bob,

=A0<= /p>

I=92m OK with that cha= nge, if we=92re permitted to make this type of change now.=

=A0

I guess if it's too = late it's not the end of the world.

I do think Bob's change is an improvement.=A0 But I still dont quite un= derstand how the client is supposed to know if it's dealing with an ord= ered list or an unordered list.=A0=A0

=A0

=A0<= u>

Paul=

=A0<= /u>

From:= bobwym= an@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman
Sent: Saturday, August 17, 2013 5:05 PM
To: Paul E. Jones<= br>Cc: Melvin Carvalho; Mike Jones; webfinger


Subject: Re: [webfinger] New = WebFinger Draft posted

=A0<= /p>

I would prefer if the wording didn't req= uire that order of listing is required to indicate a necessary order of pre= ference. Thus, I suggest the following wording:

The order of elements in the "=
;links" array MAY be read as indicating an order of preference.=

The idea is to=
 permit readers to infer order of preference, and to allow writers to expre=
ss that order, without requiring that a preferred order be determined or ex=
pressed. Where there is no preferred order, there will be no harm. Where th=
ere is a preferred order, the right thing will happen.=

bob wyman

=A0

On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones <paulej@packetizer.com> wrote:<= /u>

Why not have the client always offer items in the arr= ay in order? Any reason to randomly select items from the array?<= /u>

Paul

=A0

From: Melvin Carvalho <melvincarvalho@gmail.com>

Sent: Sa= t Aug 17 14:49:05 EDT 2013
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: "Pau= l E. Jones" <paulej@packetizer.com>, webfinger <webfinger@ietf.org><= /u>


Subject: Re: [webfi= nger] New WebFinger Draft posted

=A0

=A0

=A0

On 17 August 2= 013 20:45, Mike Jones <Michael.Jones@microsoft.com> wrote:

When used, the = ordering can do good.=A0 When not used, it does no harm.=A0 Please leave it= in.

=A0

Mike, my question related to how the client can *know* = when it's used and when it's not used.=A0 This seems unclear?

=A0

=

=A0=

=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Thanks,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0

From: webfinger-bounces@ietf.org [mailto:= webfinger-b= ounces@ietf.org] On Behalf Of Melvin Carvalho
Sent: Saturday, August 17, 2013 11:40 AM
To: Paul E. Jones=
Cc: webfinger


Subject: Re: [webfinger] New WebFinger Draft posted

=A0

=A0

=A0

= On 17 August 2013 20:32, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

We have been asked about this before. I= f we leave it in, it meets the needs of some. I admit there might be cases = where it's hard to control order, but if it matters, there is at least = a way.

In my own implementation, I assign an integer value to each entry and so= rt on that.

I have no strong objection either way, but = I do think it's good to have for those who care.

=A0

I understand the trade offs.=A0 However, I can see that this is use= ful in many cases, particularly this would work well for openid, but other = use cases, eg to have a friends list, for something like a federated social= web, would then be perhaps impractical with JRD (not the end of the world,= though)

=A0

=

Paul

=A0

From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sat Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones= " <paule= j@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted=

=A0

=A0

=A0

On 9 August 2013 18:09, Pa= ul E. Jones <= paulej@packetizer.com> wrote:

Folks,

As we're trying to bring the WebFinger spec to a close, we publishe= d a new
version -17 with some changes the WG might want to consider.
=
Draft is:
http://tools.ietf.org/html/draft-ietf-appsaw= g-webfinger-17

Those changes are:

- Section 2, added a new last paragraph to ex= plain what URI syntax we use in
WebFinger
- Corrected error in sectio= n 3.2 ("Host:" line in example and quotes around
"3.2&quo= t;)
- We remove the words "absolute URI" since it's really redund= ant
- Added "query target" to 4.5 for clarity
- Introduced = a new section 8 that describes "WebFinger" applications. =A0This<= br> is a major new addition.
- Added a new section 10.3 and 10.4 to address = registration of link relation
types and properties. =A0Link relations ty= pes already have a registry and we
refer to existing procedures. =A0WebF= inger properties did not have a registry,
so we define one, primarily for the purpose of helping people avoid creatin= g
redundant definitions.

If you have any questions or comments, p= lease feel free to post to the list.


[[

=A0=A0 The order of elements in the "link=
s" array indicates an order of
=A0=A0 preferen=
ce.=A0 Thus, if there are two or more link relations having the
=A0=A0 same "rel" value, the first link relation would indic=
ate the user's
=A0=A0 preferred link.=

]]
=A0

Maybe remove this altogether, as I am unsure it can be guaranteed.

C= ase 1: Let's say I have a list of friends, how am I to determine as a s= erver the preferred friends?=A0 How am I to determine as a client whether t= he friends are ordered or not?

Case 2: Say I mash up data from two sourc= es, how do I then order the combined list?

=A0



Paul


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

=A0

=

=A0

=A0


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

=A0

=A0

=

--089e0160bab0481b7604e45045c6-- From paulej@packetizer.com Mon Aug 19 12:22: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 ABD3B11E823D for ; Mon, 19 Aug 2013 12:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 CILU5oOyhBtF for ; Mon, 19 Aug 2013 12:22:06 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 098A811E82C2 for ; Mon, 19 Aug 2013 12:22:04 -0700 (PDT) Received: from sydney (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 r7JJM2tK029143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Aug 2013 15:22:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1376940123; bh=nTMtF151IeLUaINGBNFCH5fv08RtCI68bpl90iH3A+s=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=sbtDeS4ahV3NAEEMcvTrL1N+Ff+jI/q6ysXF22khA5DE5YKikC4yZOIu69v2LoZxI Wno+Rn+V5q47wjyg97Azj8UrU+bGE0UA44JJ8dvLFJjTRfcnZRjTqY7/JVekUdvogh Xxq3ti3+1n7groXYci1EXRw3L1y9Yaa/o1kPK8nQ= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <028601ce9cf7$74da6cd0$5e8f4670$@packetizer.com> <02c701ce9cfd$c441ab20$4cc50160$@packetizer.com> In-Reply-To: Date: Mon, 19 Aug 2013 15:22:14 -0400 Message-ID: <033801ce9d11$696848d0$3c38da70$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0339_01CE9CEF.E25967F0" X-Mailer: Microsoft Outlook 14.0 thread-index: AQIRsulmUP4nxla1qQgQS/ZK2x+2zAK8b0g/AfMzvyICFml4JQLBB8OAAfhMdnoCd1cdhwFCqMITAqp4nHsA6F1BWAGSme5yAV/qRiaYaMYIoA== Content-Language: en-us Cc: 'Bob Wyman' , 'Mike Jones' , 'webfinger' Subject: Re: [webfinger] New WebFinger Draft posted 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, 19 Aug 2013 19:22:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0339_01CE9CEF.E25967F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, If order is important, then why would the server not have that information? It either is or is not important, and I don't see how one can say order is important and then not consider order when data is collected. I order everything as I enter information into my database, but if there are items for which I have no preference I just use the same priority value and don't worry about the order in which information is rendered. Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Monday, August 19, 2013 1:29 PM To: Paul E. Jones Cc: Bob Wyman; Mike Jones; webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 19 August 2013 19:01, Paul E. Jones wrote: Melvin, Items in a JSON array are ordered by definition, so adding this language actually does not change the fact that the list is ordered. What it does, though, is remind people that if they have information they would like to prioritize, they can take advantage of the fact that arrays are ordered. So to answer your question, clients always know the links array is ordered :) If I have two avatars that I would like to make available, do I care which one is selected? If I do, then I should ensure the preferred avatar is first. If I do not, then it does not matter about order. That said, it should be understood that some clients are likely to select the first avatar it encounters and some clients might not even look further in the array to see if there are alternatives. Other clients, though, might actually offer all alternative avatars. Thanks for the explanation, I think I get this. So, as a client, lists are ordered by preference. As a server should order lists according to the information it has. If it has that information, or the preference order is not important, then we're good. As a server if the order *is* important and we dont have preference information, probably best to send nothing? Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Monday, August 19, 2013 12:41 PM To: Paul E. Jones Cc: Bob Wyman; Mike Jones; webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 19 August 2013 18:16, Paul E. Jones wrote: Bob, I'm OK with that change, if we're permitted to make this type of change now. I guess if it's too late it's not the end of the world. I do think Bob's change is an improvement. But I still dont quite understand how the client is supposed to know if it's dealing with an ordered list or an unordered list. Paul From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman Sent: Saturday, August 17, 2013 5:05 PM To: Paul E. Jones Cc: Melvin Carvalho; Mike Jones; webfinger Subject: Re: [webfinger] New WebFinger Draft posted I would prefer if the wording didn't require that order of listing is required to indicate a necessary order of preference. Thus, I suggest the following wording: The order of elements in the "links" array MAY be read as indicating an order of preference. The idea is to permit readers to infer order of preference, and to allow writers to express that order, without requiring that a preferred order be determined or expressed. Where there is no preferred order, there will be no harm. Where there is a preferred order, the right thing will happen. bob wyman On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones wrote: Why not have the client always offer items in the array in order? Any reason to randomly select items from the array? Paul _____ From: Melvin Carvalho Sent: Sat Aug 17 14:49:05 EDT 2013 To: Mike Jones Cc: "Paul E. Jones" , webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 17 August 2013 20:45, Mike Jones wrote: When used, the ordering can do good. When not used, it does no harm. Please leave it in. Mike, my question related to how the client can *know* when it's used and when it's not used. This seems unclear? Thanks, -- Mike From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin Carvalho Sent: Saturday, August 17, 2013 11:40 AM To: Paul E. Jones Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 17 August 2013 20:32, Paul E. Jones wrote: Melvin, We have been asked about this before. If we leave it in, it meets the needs of some. I admit there might be cases where it's hard to control order, but if it matters, there is at least a way. In my own implementation, I assign an integer value to each entry and sort on that. I have no strong objection either way, but I do think it's good to have for those who care. I understand the trade offs. However, I can see that this is useful in many cases, particularly this would work well for openid, but other use cases, eg to have a friends list, for something like a federated social web, would then be perhaps impractical with JRD (not the end of the world, though) Paul _____ From: Melvin Carvalho Sent: Sat Aug 17 14:12:11 EDT 2013 To: "Paul E. Jones" Cc: webfinger Subject: Re: [webfinger] New WebFinger Draft posted On 9 August 2013 18:09, Paul E. Jones wrote: Folks, As we're trying to bring the WebFinger spec to a close, we published a new version -17 with some changes the WG might want to consider. Draft is: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 Those changes are: - Section 2, added a new last paragraph to explain what URI syntax we use in WebFinger - Corrected error in section 3.2 ("Host:" line in example and quotes around "3.2") - We remove the words "absolute URI" since it's really redundant - Added "query target" to 4.5 for clarity - Introduced a new section 8 that describes "WebFinger" applications. This is a major new addition. - Added a new section 10.3 and 10.4 to address registration of link relation types and properties. Link relations types already have a registry and we refer to existing procedures. WebFinger properties did not have a registry, so we define one, primarily for the purpose of helping people avoid creating redundant definitions. If you have any questions or comments, please feel free to post to the list. [[ The order of elements in the "links" array indicates an order of preference. Thus, if there are two or more link relations having the same "rel" value, the first link relation would indicate the user's preferred link. ]] Maybe remove this altogether, as I am unsure it can be guaranteed. Case 1: Let's say I have a list of friends, how am I to determine as a server the preferred friends? How am I to determine as a client whether the friends are ordered or not? Case 2: Say I mash up data from two sources, how do I then order the combined list? 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 ------=_NextPart_000_0339_01CE9CEF.E25967F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

If order is important, then why would the server not have that = information?  It either is or is not important, and I don’t = see how one can say order is important and then not consider order when = data is collected.

 

I order everything as I enter information into my database, but if = there are items for which I have no preference I just use the same = priority value and don’t worry about the order in which = information is rendered.

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Monday, August 19, 2013 1:29 PM
To: Paul E. = Jones
Cc: Bob Wyman; Mike Jones; webfinger
Subject: = Re: [webfinger] New WebFinger Draft = posted

 

 

 

On 19 August 2013 19:01, Paul E. Jones <paulej@packetizer.com> = wrote:

Melvin,

 

Items in a JSON array are ordered by definition, so adding this = language actually does not change the fact that the list is = ordered.  What it does, though, is remind people that if they have = information they would like to prioritize, they can take advantage of = the fact that arrays are ordered.

 

So to answer your question, clients always know the links array is = ordered :)

 

If I have two avatars that I would like to make available, do I care = which one is selected?  If I do, then I should ensure the preferred = avatar is first.  If I do not, then it does not matter about = order.  That said, it should be understood that some clients are = likely to select the first avatar it encounters and some clients might = not even look further in the array to see if there are = alternatives.  Other clients, though, might actually offer all = alternative avatars.

 

Thanks for the explanation, I think I get = this.

So, as a client, lists are ordered by = preference.

As a server should order lists according = to the information it has.  If it has that information, or the = preference order is not important, then we're good. 

As a = server if the order *is* important and we dont have preference = information, probably best to send nothing?  =

 

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: Monday, = August 19, 2013 12:41 PM
To: Paul E. Jones
Cc: Bob = Wyman; Mike Jones; webfinger


Subject: Re: [webfinger] New WebFinger = Draft posted

 <= /o:p>

 <= /o:p>

 <= /p>

On 19 = August 2013 18:16, Paul E. Jones <paulej@packetizer.com> = wrote:

Bob,

 

I’m OK with that change, if we’re permitted to make this = type of change now.

 <= /o:p>

I guess if it's = too late it's not the end of the world.

I do think = Bob's change is an improvement.  But I still dont quite understand = how the client is supposed to know if it's dealing with an ordered list = or an unordered list.  

 <= /o:p>

 

Paul

 

From:= = bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman
Sent: Saturday, August 17, 2013 5:05 PM
To: = Paul E. Jones
Cc: Melvin Carvalho; Mike Jones; = webfinger


Subje= ct: Re: [webfinger] New WebFinger Draft = posted

 <= /o:p>

I would = prefer if the wording didn't require that order of listing is required = to indicate a necessary order of preference. Thus, I suggest the = following wording:

The order of elements in the =
"links" array MAY be read as indicating an order of =
preference.
The idea is to permit readers =
to infer order of preference, and to allow writers to express that =
order, without requiring that a preferred order be determined or =
expressed. Where there is no preferred order, there will be no harm. =
Where there is a preferred order, the right thing will =
happen.
bob =
wyman

 <= /o:p>

On Sat, Aug = 17, 2013 at 4:29 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Why not have the client always offer items = in the array in order? Any reason to randomly select items from the = array?

Paul

 <= /p>

From:= = Melvin Carvalho <melvincarvalho@gmail.com>

<= /div>

Sent:= = Sat Aug 17 14:49:05 EDT 2013
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: = "Paul E. Jones" <paulej@packetizer.com>, webfinger <webfinger@ietf.org>


Subje= ct: Re: [webfinger] New WebFinger Draft = posted

 <= /o:p>

 <= /o:p>

 <= /p>

On 17 = August 2013 20:45, Mike Jones <Michael.Jones@microsoft.com> = wrote:

When used, the ordering can do good.  When not used, it does no = harm.  Please leave it in.

 <= /o:p>

Mike, my = question related to how the client can *know* when it's used and when = it's not used.  This seems unclear?

 <= /o:p>

 

           &nbs= p;            = ;            =             &= nbsp;           = Thanks,

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

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Melvin Carvalho
Sent: Saturday, August 17, 2013 11:40 = AM
To: Paul E. Jones
Cc: = webfinger


Subje= ct: Re: [webfinger] New WebFinger Draft = posted

 <= /o:p>

 <= /o:p>

 <= /p>

On 17 = August 2013 20:32, Paul E. Jones <paulej@packetizer.com> = wrote:

Melvin,

We have been asked = about this before. If we leave it in, it meets the needs of some. I = admit there might be cases where it's hard to control order, but if it = matters, there is at least a way.

In my own = implementation, I assign an integer value to each entry and sort on = that.

I have no strong objection either way, but I do = think it's good to have for those who care.

 <= /o:p>

I = understand the trade offs.  However, I can see that this is useful = in many cases, particularly this would work well for openid, but other = use cases, eg to have a friends list, for something like a federated = social web, would then be perhaps impractical with JRD (not the end of = the world, though)

 <= /o:p>

Paul

 <= /p>

From:= = Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sat = Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger = <webfinger@ietf.org>
Subject: Re: = [webfinger] New WebFinger Draft = posted

 <= /o:p>

 <= /o:p>

 <= /p>

On 9 August = 2013 18:09, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,
As we're trying to bring the WebFinger spec to a close, we published a = new
version -17 with some changes the WG might want to = consider.

Draft is:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -17

Those changes are:

- Section 2, added a new last = paragraph to explain what URI syntax we use in
WebFinger
- = Corrected error in section 3.2 ("Host:" line in example and = quotes around
"3.2")
- We remove the words = "absolute URI" since it's really redundant
- Added = "query target" to 4.5 for clarity
- Introduced a new = section 8 that describes "WebFinger" applications. =  This
is a major new addition.
- Added a new section 10.3 and = 10.4 to address registration of link relation
types and properties. =  Link relations types already have a registry and we
refer to = existing procedures.  WebFinger properties did not have a = registry,
so we define one, primarily for the purpose of helping = people avoid creating
redundant definitions.

If you have any = questions or comments, please feel free to post to the = list.


[[<= /o:p>

   The order of elements in the =
"links" array indicates an order =
of
   preference.  Thus, if there =
are two or more link relations having =
the
   same "rel" value, the =
first link relation would indicate the =
user's
   preferred =
link.

]]
 =

Maybe remove this = altogether, as I am unsure it can be = guaranteed.

Case 1: Let's say = I have a list of friends, how am I to determine as a server the = preferred friends?  How am I to determine as a client whether the = friends are ordered or not?

Case 2: Say = I mash up data from two sources, how do I then order the combined = list?

 <= /o:p>



Paul=


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

 <= /o:p>

 <= /o:p>

 <= /o:p>


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

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_0339_01CE9CEF.E25967F0-- From melvincarvalho@gmail.com Mon Aug 19 15:54: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 650F811E818D for ; Mon, 19 Aug 2013 15:54:28 -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 S-iMm2W2zA7r for ; Mon, 19 Aug 2013 15:54:23 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 39A6211E819D for ; Mon, 19 Aug 2013 15:54:19 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id t13so3437250lbd.2 for ; Mon, 19 Aug 2013 15:54:16 -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=ZGNF0gglNwg/dODxgQ7AyZkAfgYEX+5h2dcHu9b4Nlc=; b=WXxQhL1w0Y3SvXMPOpOND7QaypzCizdzdRufd4dXqrNBMwipgGyx2wWA7wgpmeSTHt 4ZGXX1R4izLXaMF6Nwj6OqO1EUE970JVmD+gHu3mldwrcQk3MCSVOr9lTKBKriHWpo83 6Csq4tK2I3clF0zNs7zLEpW6YxIaJd30MXrsyclNXOfbRFw1CzOnbIJ4wf8XIBZ043VY YmLYl+HN1UNr++1HERPFxS158ySC1qMLIySEYD6j+xyO5JOHWbcf3tt6QY5HECwvpBHe c4RayWHxMKxZ1mssoxzLOkPQH8i3cevAr3jUzyo2dq4aKUgsALXrnHYB2sw6Far/nxbg f6NA== MIME-Version: 1.0 X-Received: by 10.112.92.110 with SMTP id cl14mr90255lbb.78.1376952856059; Mon, 19 Aug 2013 15:54:16 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Mon, 19 Aug 2013 15:54:15 -0700 (PDT) In-Reply-To: <033801ce9d11$696848d0$3c38da70$@packetizer.com> References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <028601ce9cf7$74da6cd0$5e8f4670$@packetizer.com> <02c701ce9cfd$c441ab20$4cc50160$@packetizer.com> <033801ce9d11$696848d0$3c38da70$@packetizer.com> Date: Tue, 20 Aug 2013 00:54:15 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a11336c2cdba40f04e454d16b Cc: Bob Wyman , Mike Jones , webfinger Subject: Re: [webfinger] New WebFinger Draft posted 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, 19 Aug 2013 22:54:28 -0000 --001a11336c2cdba40f04e454d16b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 19 August 2013 21:22, Paul E. Jones wrote: > Melvin,**** > > ** ** > > If order is important, then why would the server not have that > information? It either is or is not important, and I don=92t see how one= can > say order is important and then not consider order when data is collected= . > **** > > ** ** > > I order everything as I enter information into my database, but if there > are items for which I have no preference I just use the same priority val= ue > and don=92t worry about the order in which information is rendered. > Very good point. The term "important" seems to be a subjective evaluation. Most data I have comes from some kind of relational or nosql style DB. So as a server, when I'm getting data from a DB and serving it dynamically for webfinger record, I'll need to A) subjectively determine whether order is important B) attempt to order the preferred items to the top I dont naturally tend to keep lists ordered (except maybe by timestamp), but I can start to, where I think it matters. Seems a slight extra implementation challenge, but something probably doable when it matters ... > **** > > ** ** > > Paul**** > > ** ** > > *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com] > *Sent:* Monday, August 19, 2013 1:29 PM > > *To:* Paul E. Jones > *Cc:* Bob Wyman; Mike Jones; webfinger > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > ** ** > > ** ** > > ** ** > > On 19 August 2013 19:01, Paul E. Jones wrote:**** > > Melvin,**** > > **** > > Items in a JSON array are ordered by definition, so adding this language > actually does not change the fact that the list is ordered. What it does= , > though, is remind people that if they have information they would like to > prioritize, they can take advantage of the fact that arrays are ordered.*= * > ** > > **** > > So to answer your question, clients always know the links array is ordere= d > :)**** > > **** > > If I have two avatars that I would like to make available, do I care whic= h > one is selected? If I do, then I should ensure the preferred avatar is > first. If I do not, then it does not matter about order. That said, it > should be understood that some clients are likely to select the first > avatar it encounters and some clients might not even look further in the > array to see if there are alternatives. Other clients, though, might > actually offer all alternative avatars.**** > > ** ** > > Thanks for the explanation, I think I get this. > > So, as a client, lists are ordered by preference.**** > > As a server should order lists according to the information it has. If i= t > has that information, or the preference order is not important, then we'r= e > good. > > As a server if the order *is* important and we dont have preference > information, probably best to send nothing? **** > > **** > > **** > > Paul**** > > **** > > *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com] > *Sent:* Monday, August 19, 2013 12:41 PM > *To:* Paul E. Jones > *Cc:* Bob Wyman; Mike Jones; webfinger**** > > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > **** > > **** > > **** > > On 19 August 2013 18:16, Paul E. Jones wrote:**** > > Bob,**** > > **** > > I=92m OK with that change, if we=92re permitted to make this type of chan= ge > now.**** > > **** > > I guess if it's too late it's not the end of the world.**** > > I do think Bob's change is an improvement. But I still dont quite > understand how the client is supposed to know if it's dealing with an > ordered list or an unordered list. **** > > **** > > **** > > Paul**** > > **** > > *From:* bobwyman@gmail.com [mailto:bobwyman@gmail.com] *On Behalf Of *Bob > Wyman > *Sent:* Saturday, August 17, 2013 5:05 PM > *To:* Paul E. Jones > *Cc:* Melvin Carvalho; Mike Jones; webfinger**** > > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > **** > > I would prefer if the wording didn't require that order of listing is > required to indicate a necessary order of preference. Thus, I suggest the > following wording:**** > > The order of elements in the "links" array *MAY be read as indicating* an= order of preference.**** > > The idea is to permit readers to infer order of preference, and to allow = writers to express that order, without requiring that a preferred order be = determined or expressed. Where there is no preferred order, there will be n= o harm. Where there is a preferred order, the right thing will happen.**** > > bob wyman**** > > **** > > On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones > wrote:**** > > Why not have the client always offer items in the array in order? Any > reason to randomly select items from the array?**** > > Paul**** > > **** > ------------------------------ > > *From:* Melvin Carvalho **** > > *Sent:* Sat Aug 17 14:49:05 EDT 2013 > *To:* Mike Jones > *Cc:* "Paul E. Jones" , webfinger < > webfinger@ietf.org>**** > > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > **** > > **** > > **** > > On 17 August 2013 20:45, Mike Jones wrote:*= * > ** > > When used, the ordering can do good. When not used, it does no harm. > Please leave it in.**** > > **** > > Mike, my question related to how the client can *know* when it's used and > when it's not used. This seems unclear?**** > > **** > > **** > > Thanks,**** > > -- Mike**** > > **** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Melvin Carvalho > *Sent:* Saturday, August 17, 2013 11:40 AM > *To:* Paul E. Jones > *Cc:* webfinger**** > > > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > **** > > **** > > **** > > On 17 August 2013 20:32, Paul E. Jones wrote:**** > > Melvin,**** > > We have been asked about this before. If we leave it in, it meets the > needs of some. I admit there might be cases where it's hard to control > order, but if it matters, there is at least a way.**** > > In my own implementation, I assign an integer value to each entry and sor= t > on that.**** > > I have no strong objection either way, but I do think it's good to have > for those who care.**** > > **** > > I understand the trade offs. However, I can see that this is useful in > many cases, particularly this would work well for openid, but other use > cases, eg to have a friends list, for something like a federated social > web, would then be perhaps impractical with JRD (not the end of the world= , > though)**** > > **** > > Paul**** > > **** > ------------------------------ > > *From:* Melvin Carvalho > *Sent:* Sat Aug 17 14:12:11 EDT 2013 > *To:* "Paul E. Jones" > *Cc:* webfinger > *Subject:* Re: [webfinger] New WebFinger Draft posted**** > > **** > > **** > > **** > > On 9 August 2013 18:09, Paul E. Jones wrote:**** > > Folks, > > As we're trying to bring the WebFinger spec to a close, we published a ne= w > version -17 with some changes the WG might want to consider. > > Draft is: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 > > Those changes are: > > - Section 2, added a new last paragraph to explain what URI syntax we use > in > WebFinger > - Corrected error in section 3.2 ("Host:" line in example and quotes arou= nd > "3.2") > - We remove the words "absolute URI" since it's really redundant > - Added "query target" to 4.5 for clarity > - Introduced a new section 8 that describes "WebFinger" applications. Th= is > is a major new addition. > - Added a new section 10.3 and 10.4 to address registration of link > relation > types and properties. Link relations types already have a registry and w= e > refer to existing procedures. WebFinger properties did not have a > registry, > so we define one, primarily for the purpose of helping people avoid > creating > redundant definitions. > > If you have any questions or comments, please feel free to post to the > list.**** > > > [[**** > > The order of elements in the "links" array indicates an order of**** > > preference. Thus, if there are two or more link relations having the*= *** > > same "rel" value, the first link relation would indicate the user's***= * > > preferred link.**** > > ]] > **** > > Maybe remove this altogether, as I am unsure it can be guaranteed.**** > > Case 1: Let's say I have a list of friends, how am I to determine as a > server the preferred friends? How am I to determine as a client whether > the friends are ordered or not?**** > > Case 2: Say I mash up data from two sources, how do I then order the > combined list?**** > > **** > > > > 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**** > > **** > > **** > > ** ** > --001a11336c2cdba40f04e454d16b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On 19 August 2013 21:22, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:

Melvin,

=A0<= /p>

If order is important,= then why would the server not have that information?=A0 It either is or is= not important, and I don=92t see how one can say order is important and th= en not consider order when data is collected.

=A0<= /p>

I order everything as = I enter information into my database, but if there are items for which I ha= ve no preference I just use the same priority value and don=92t worry about= the order in which information is rendered.


Very good point.=A0 The term &= quot;important" seems to be a subjective evaluation.

Most data I have comes from some kind of relational or nosql style DB.=A0 =

=A0<= /p>

Paul

=A0<= /p>

From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: Monday, August 19, 2013 1:29 PM


To: Paul E. Jones
Cc: Bob Wyman; Mike Jones; webfin= ger
Subject: Re: [webfinger] New WebFinger Draft posted=

<= /u>=A0

=A0

=A0

On 19 August 2013 19:01, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

=A0<= /p>

Items in a JSON array = are ordered by definition, so adding this language actually does not change= the fact that the list is ordered.=A0 What it does, though, is remind peop= le that if they have information they would like to prioritize, they can ta= ke advantage of the fact that arrays are ordered.

=A0<= /p>

So to answer your ques= tion, clients always know the links array is ordered :)

=A0<= /p>

If I have two avatars = that I would like to make available, do I care which one is selected?=A0 If= I do, then I should ensure the preferred avatar is first.=A0 If I do not, = then it does not matter about order.=A0 That said, it should be understood = that some clients are likely to select the first avatar it encounters and s= ome clients might not even look further in the array to see if there are al= ternatives.=A0 Other clients, though, might actually offer all alternative = avatars.

=A0

Thanks for the explanati= on, I think I get this.

So, as a client, lists are ordered by prefer= ence.

As a serve= r should order lists according to the information it has.=A0 If it has that= information, or the preference order is not important, then we're good= .=A0

As a server if the order *is* important and we dont have preference inf= ormation, probably best to send nothing?=A0

=A0

=A0

Paul<= u>

=A0<= /p>

From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: Monday, August 19, 2013 12:41 PM
To: Paul E. JonesCc: Bob Wyman; Mike Jones; webfinger

=


Subject: Re: [webfinger] New WebFing= er Draft posted

=A0<= /p>

=A0

=A0

On 19 August 2013 18:16, Paul E. Jones <paulej@packetizer.com> wrote:

Bob,<= /u>

=A0<= u>

I=92m OK with that change= , if we=92re permitted to make this type of change now.

=A0

I guess if it's too = late it's not the end of the world.

I do think Bob's change is an improvement.=A0 But I still dont quite un= derstand how the client is supposed to know if it's dealing with an ord= ered list or an unordered list.=A0=A0

=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=A0

Paul=

=A0<= /u>

From:= bobwym= an@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman
Sent: Saturday, August 17, 2013 5:05 PM
To: Paul E. Jones<= br>Cc: Melvin Carvalho; Mike Jones; webfinger


Subject: Re: [webfinger] New = WebFinger Draft posted

=A0<= /p>

I would prefer if the wording didn't req= uire that order of listing is required to indicate a necessary order of pre= ference. Thus, I suggest the following wording:

The order of elements in the "=
;links" array MAY be read as indicating an order of preference.=

The idea is to=
 permit readers to infer order of preference, and to allow writers to expre=
ss that order, without requiring that a preferred order be determined or ex=
pressed. Where there is no preferred order, there will be no harm. Where th=
ere is a preferred order, the right thing will happen.=

bob wyman

=A0

On Sat, Aug 17, 2013 at 4:29 PM, Paul E. Jones <paulej@packetizer.com> wrote:<= /u>

Why not have the client always offer items in the arr= ay in order? Any reason to randomly select items from the array?<= /u>

Paul

=A0

From: Melvin Carvalho <melvincarvalho@gmail.com>

Sent: Sa= t Aug 17 14:49:05 EDT 2013
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: "Pau= l E. Jones" <paulej@packetizer.com>, webfinger <webfinger@ietf.org><= /u>


Subject: Re: [webfi= nger] New WebFinger Draft posted

=A0

=A0

=A0

On 17 August 2= 013 20:45, Mike Jones <Michael.Jones@microsoft.com> wrote:

When used, the = ordering can do good.=A0 When not used, it does no harm.=A0 Please leave it= in.

=A0

Mike, my question related to how the client can *know* = when it's used and when it's not used.=A0 This seems unclear?

=A0

=

=A0=

=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Thanks,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0

From: webfinger-bounces@ietf.org [mailto:= webfinger-b= ounces@ietf.org] On Behalf Of Melvin Carvalho
Sent: Saturday, August 17, 2013 11:40 AM
To: Paul E. Jones=
Cc: webfinger


Subject: Re: [webfinger] New WebFinger Draft posted

=A0

=A0

=A0

= On 17 August 2013 20:32, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

We have been asked about this before. I= f we leave it in, it meets the needs of some. I admit there might be cases = where it's hard to control order, but if it matters, there is at least = a way.

In my own implementation, I assign an integer value to each entry and so= rt on that.

I have no strong objection either way, but = I do think it's good to have for those who care.

=A0

I understand the trade offs.=A0 However, I can see that this is use= ful in many cases, particularly this would work well for openid, but other = use cases, eg to have a friends list, for something like a federated social= web, would then be perhaps impractical with JRD (not the end of the world,= though)

=A0

=

Paul

=A0

From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Sat Aug 17 14:12:11 EDT 2013
To: "Paul E. Jones= " <paule= j@packetizer.com>
Cc: webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted=

=A0

=A0

=A0

On 9 August 2013 18:09, Pa= ul E. Jones <= paulej@packetizer.com> wrote:

Folks,

As we're trying to bring the WebFinger spec to a close, we publishe= d a new
version -17 with some changes the WG might want to consider.
=
Draft is:
http://tools.ietf.org/html/draft-ietf-appsaw= g-webfinger-17

Those changes are:

- Section 2, added a new last paragraph to ex= plain what URI syntax we use in
WebFinger
- Corrected error in sectio= n 3.2 ("Host:" line in example and quotes around
"3.2&quo= t;)
- We remove the words "absolute URI" since it's really redund= ant
- Added "query target" to 4.5 for clarity
- Introduced = a new section 8 that describes "WebFinger" applications. =A0This<= br> is a major new addition.
- Added a new section 10.3 and 10.4 to address = registration of link relation
types and properties. =A0Link relations ty= pes already have a registry and we
refer to existing procedures. =A0WebF= inger properties did not have a registry,
so we define one, primarily for the purpose of helping people avoid creatin= g
redundant definitions.

If you have any questions or comments, p= lease feel free to post to the list.


[[

=A0=A0 The order of elements in the "link=
s" array indicates an order of
=A0=A0 preferen=
ce.=A0 Thus, if there are two or more link relations having the
=A0=A0 same "rel" value, the first link relation would indic=
ate the user's
=A0=A0 preferred link.=

]]
=A0

Maybe remove this altogether, as I am unsure it can be guaranteed.

C= ase 1: Let's say I have a list of friends, how am I to determine as a s= erver the preferred friends?=A0 How am I to determine as a client whether t= he friends are ordered or not?

Case 2: Say I mash up data from two sourc= es, how do I then order the combined list?

=A0



Paul


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

=A0

=

=A0

=A0


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

=A0

=A0

=

=A0


--001a11336c2cdba40f04e454d16b-- From wmills@yahoo-inc.com Mon Aug 19 16:02: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 A123711E81A5 for ; Mon, 19 Aug 2013 16:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.598 X-Spam-Level: X-Spam-Status: No, score=-18.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] 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 6PGLBA4kEKtk for ; Mon, 19 Aug 2013 16:02:35 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id CF44E11E8175 for ; Mon, 19 Aug 2013 16:02:35 -0700 (PDT) Received: from GQ1-EX10-CAHT05.y.corp.yahoo.com (gq1-ex10-caht05.corp.gq1.yahoo.com [10.73.118.84]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r7JN24tS063598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 19 Aug 2013 16:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1376953329; bh=ZyrKYZJNi2ToGRHq/XyJyiFJu2bpZJqNO3fN55H6tmM=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=Z26F8vDuS158FPjZpCX3nS31H8qKPWx/lWqWJGGVT7boT1DE6P/cfAlKy7T+J7JZh 0RyzcmWULB+Pu4JtNiEtCpS7bjNhFn+QMLEhhzHK9e9C3Hkavf91ZWHzpeKq16azC2 jPaOwDJyuGhP8SNXT2kK4jwkYvt2O4r71JRCejF0= Received: from omp1068.mail.ne1.yahoo.com (98.138.226.167) by GQ1-EX10-CAHT05.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 19 Aug 2013 16:02:03 -0700 Received: (qmail 95791 invoked by uid 1000); 19 Aug 2013 23:02:02 -0000 Received: (qmail 70289 invoked by uid 60001); 19 Aug 2013 23:02:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1376953322; bh=LXlAd0WAAewRGU5xGmjna0GDT4C0bQaoXeVWM9ytg9w=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=C2t7+Byrm8i5Y1wgm1sCEzaHGxkaHxUsScEa9D8quYY4yYoj9FW/42L11YCSLX7clb4PHzxH4XsKhzolu20xPAbzNgy9q+9PzeYN5Kuy2bD1SnEkSrp4UHRjb9b1Mo5KH1QYlQpNWoRxbv7lH1/RfWOPw/dfrt+x6fp2gE4t+Qw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fQoZHxicQbWmMKqLBsTjFW1CxB/I72ipW04NMT7ACoIzsbmXSuV4TWrokEaCBgVdQ4d5N2x6+tKxNv0M+KhvCmfjlFIlaigt/YhdQLk7IdXxBAkrEIBP3XvLZyTzzx1dlT8cqzJrjSlvPmu7nnpOlunpJJw3QfW8cYYiWO3gyX0=; X-YMail-OSG: ..o8EoEVM1nIoXCMu5yd3ziOJwMOjPXqwPw.DoToFh.XcNc A9rcNhvf8M7P6dmMChqtVErR9IZ6fkLYnNfeuJAlQVSocEuL5Vcj7YXVXFY. vccw0B7t08zF1_W8EJqQQMVmqR67EiGy1v6Fz5rb6NfTnAJgpctZx3uxgD9q XZJJBQEo1BXaQ6PVjnf.NRbPuo4oLY4C0XXNBMrF1UV5NNaiZ0ohEfNTeUgF U7A6v.VccYgUXWck6gxq7DEjpt3FIt4qTioSdH7j.SupfalP5k048wh.AGLJ mIxcY1fM2rLFp3gP0CVOdaABR Received: from [66.228.162.36] by web125604.mail.ne1.yahoo.com via HTTP; Mon, 19 Aug 2013 16:02:02 PDT X-Rocket-MIMEInfo: 002.001, SWYgY2xpZW50cyBNQVkgaWdub3JlIG9yZGVyaW5nIHRoZW4gb3JkZXIgY2FuJ3QgYmUgdmVyeSBpbXBvcnRhbnQuwqAgT3JkZXIgYmVjb21lcyBhdCBtb3N0IGEgcmVxdWVzdGVkIHByZWZlcmVuY2UuCgoKwqAKLWJpbGwKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KV2lsbGlhbSBKLiBNaWxscwoiUGFyYW5vaWQiIFlhaG9vIQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IE1lbHZpbiBDYXJ2YWxobyA8bWVsdmluY2FydmFsaG9AZ21haWwuY29tPgpUbzogUGEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.155.576 References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <028601ce9cf7$74da6cd0$5e8f4670$@packetizer.com> <02c701ce9cfd$c441ab20$4cc50160$@packetizer.com> <033801ce9d11$696848d0$3c38da70$@packetizer.com> Message-ID: <1376953322.70192.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Mon, 19 Aug 2013 16:02:02 -0700 From: Bill Mills To: Melvin Carvalho , "Paul E. Jones" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-28972646-1376953322=:70192" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 953326003 Cc: Bob Wyman , Mike Jones , webfinger Subject: Re: [webfinger] New WebFinger Draft posted X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills 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, 19 Aug 2013 23:02:40 -0000 ---685807438-28972646-1376953322=:70192 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If clients MAY ignore ordering then order can't be very important.=C2=A0 Or= der becomes at most a requested preference.=0A=0A=0A=C2=A0=0A-bill=0A=0A=0A= =0A--------------------------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!= =0A=0A=0A=0A=0A________________________________=0A From: Melvin Carvalho =0ATo: Paul E. Jones =0ACc:= Bob Wyman ; Mike Jones ; webfin= ger =0ASent: Monday, August 19, 2013 3:54 PM=0ASubject= : Re: [webfinger] New WebFinger Draft posted=0A =0A=0A=0A=0A=0A=0A=0A=0AOn = 19 August 2013 21:22, Paul E. Jones wrote:=0A=0AMel= vin,=0A>=C2=A0=0A>If order is important, then why would the server not have= that information?=C2=A0 It either is or is not important, and I don=E2=80= =99t see how one can say order is important and then not consider order whe= n data is collected.=0A>=C2=A0=0A>I order everything as I enter information= into my database, but if there are items for which I have no preference I = just use the same priority value and don=E2=80=99t worry about the order in= which information is rendered.=0A=0AVery good point.=C2=A0 The term "impor= tant" seems to be a subjective evaluation.=0A=0A=0AMost data I have comes f= rom some kind of relational or nosql style DB.=C2=A0 =0A=0A=0ASo as a serve= r, when I'm getting data from a DB and serving it dynamically for webfinger= record, I'll need to =0AA) subjectively determine whether order is importa= nt =0AB) attempt to order the preferred items to the top=0A=0A=0AI dont nat= urally tend to keep lists ordered (except maybe by timestamp), but I can st= art to, where I think it matters.=C2=A0 Seems a slight extra implementation= challenge, but something probably doable when it matters ...=0A=0A=C2=A0= =0A=C2=A0=0A>Paul=0A>=C2=A0=0A>From:Melvin Carvalho [mailto:melvincarvalho@= gmail.com] =0A>Sent: Monday, August 19, 2013 1:29 PM=0A>=0A>To: Paul E. Jon= es=0A>Cc: Bob Wyman; Mike Jones; webfinger=0A>Subject: Re: [webfinger] New = WebFinger Draft posted=0A>=C2=A0=0A>=C2=A0=0A>=C2=A0=0A>On 19 August 2013 1= 9:01, Paul E. Jones wrote:=0A>Melvin,=0A>=C2=A0=0A>= Items in a JSON array are ordered by definition, so adding this language ac= tually does not change the fact that the list is ordered.=C2=A0 What it doe= s, though, is remind people that if they have information they would like t= o prioritize, they can take advantage of the fact that arrays are ordered.= =0A>=C2=A0=0A>So to answer your question, clients always know the links arr= ay is ordered :)=0A>=C2=A0=0A>If I have two avatars that I would like to ma= ke available, do I care which one is selected?=C2=A0 If I do, then I should= ensure the preferred avatar is first.=C2=A0 If I do not, then it does not = matter about order.=C2=A0 That said, it should be understood that some clie= nts are likely to select the first avatar it encounters and some clients mi= ght not even look further in the array to see if there are alternatives.=C2= =A0 Other clients, though, might actually offer all alternative avatars.=0A= >=C2=A0=0A>Thanks for the explanation, I think I get this.=0A>=0A>So, as a = client, lists are ordered by preference.=0A>As a server should order lists = according to the information it has.=C2=A0 If it has that information, or t= he preference order is not important, then we're good.=C2=A0 =0A>=0A>As a s= erver if the order *is* important and we dont have preference information, = probably best to send nothing?=C2=A0 =0A>=C2=A0=0A>=C2=A0=0A>>Paul=0A>>=C2= =A0=0A>>From:Melvin Carvalho [mailto:melvincarvalho@gmail.com] =0A>>Sent: M= onday, August 19, 2013 12:41 PM=0A>>To: Paul E. Jones=0A>>Cc: Bob Wyman; Mi= ke Jones; webfinger=0A>>=0A>>Subject: Re: [webfinger] New WebFinger Draft p= osted=0A>>=C2=A0=0A>>=C2=A0=0A>>=C2=A0=0A>>On 19 August 2013 18:16, Paul E.= Jones wrote:=0A>>Bob,=0A>>=C2=A0=0A>>I=E2=80=99m O= K with that change, if we=E2=80=99re permitted to make this type of change = now.=0A>>=C2=A0=0A>>I guess if it's too late it's not the end of the world.= =0A>>I do think Bob's change is an improvement.=C2=A0 But I still dont quit= e understand how the client is supposed to know if it's dealing with an ord= ered list or an unordered list.=C2=A0=C2=A0 =0A>>=C2=A0=0A>>=C2=A0=0A>>>Pau= l=0A>>>=C2=A0=0A>>>From:bobwyman@gmail.com [mailto:bobwyman@gmail.com] On B= ehalf Of Bob Wyman=0A>>>Sent: Saturday, August 17, 2013 5:05 PM=0A>>>To: Pa= ul E. Jones=0A>>>Cc: Melvin Carvalho; Mike Jones; webfinger=0A>>>=0A>>>Subj= ect: Re: [webfinger] New WebFinger Draft posted=0A>>>=C2=A0=0A>>>I would pr= efer if the wording didn't require that order of listing is required to ind= icate a necessary order of preference. Thus, I suggest the following wordin= g:=0A>>>The order of elements in the "links" array MAY be read as indicatin= g an order of preference.=0A>>>The idea is to permit readers to infer order= of preference, and to allow writers to express that order, without requiri= ng that a preferred order be determined or expressed. Where there is no pre= ferred order, there will be no harm. Where there is a preferred order, the = right thing will happen.=0A>>>bob wyman=0A>>>=C2=A0=0A>>>On Sat, Aug 17, 20= 13 at 4:29 PM, Paul E. Jones wrote:=0A>>>Why not ha= ve the client always offer items in the array in order? Any reason to rando= mly select items from the array?=0A>>>Paul=0A>>>=C2=A0=0A>>>=0A>>>_________= _______________________=0A>>> =0A>>>From:Melvin Carvalho =0A>>>Sent:Sat Aug 17 14:49:05 EDT 2013=0A>>>To: Mike Jones =0A>>>Cc: "Paul E. Jones" , we= bfinger =0A>>>=0A>>>Subject: Re: [webfinger] New WebFin= ger Draft posted=0A>>>=C2=A0=0A>>>=C2=A0=0A>>>=C2=A0=0A>>>On 17 August 2013= 20:45, Mike Jones wrote:=0A>>>When used, the= ordering can do good.=C2=A0 When not used, it does no harm.=C2=A0 Please l= eave it in.=0A>>>=C2=A0=0A>>>Mike, my question related to how the client ca= n *know* when it's used and when it's not used.=C2=A0 This seems unclear?= =0A>>>=C2=A0=0A>>>=C2=A0=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Thanks,=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -- Mike=0A>>>>=C2=A0=0A>>>>From:webfinger-bounces@ietf.org [mailto:w= ebfinger-bounces@ietf.org] On Behalf Of Melvin Carvalho=0A>>>>Sent: Saturda= y, August 17, 2013 11:40 AM=0A>>>>To: Paul E. Jones=0A>>>>Cc: webfinger=0A>= >>>=0A>>>>Subject: Re: [webfinger] New WebFinger Draft posted=0A>>>>=C2=A0= =0A>>>>=C2=A0=0A>>>>=C2=A0=0A>>>>On 17 August 2013 20:32, Paul E. Jones wrote:=0A>>>>Melvin,=0A>>>>We have been asked about th= is before. If we leave it in, it meets the needs of some. I admit there mig= ht be cases where it's hard to control order, but if it matters, there is a= t least a way.=0A>>>>In my own implementation, I assign an integer value to= each entry and sort on that.=0A>>>>I have no strong objection either way, = but I do think it's good to have for those who care.=0A>>>>=C2=A0=0A>>>>I u= nderstand the trade offs.=C2=A0 However, I can see that this is useful in m= any cases, particularly this would work well for openid, but other use case= s, eg to have a friends list, for something like a federated social web, wo= uld then be perhaps impractical with JRD (not the end of the world, though)= =0A>>>>=C2=A0=0A>>>>Paul=0A>>>>>=C2=A0=0A>>>>>=0A>>>>>_____________________= ___________=0A>>>>> =0A>>>>>From:Melvin Carvalho = =0A>>>>>Sent: Sat Aug 17 14:12:11 EDT 2013=0A>>>>>To: "Paul E. Jones" =0A>>>>>Cc: webfinger =0A>>>>>Subject= : Re: [webfinger] New WebFinger Draft posted=0A>>>>>=C2=A0=0A>>>>>=C2=A0=0A= >>>>>=C2=A0=0A>>>>>On 9 August 2013 18:09, Paul E. Jones wrote:=0A>>>>>Folks,=0A>>>>>=0A>>>>>As we're trying to bring the WebF= inger spec to a close, we published a new=0A>>>>>version -17 with some chan= ges the WG might want to consider.=0A>>>>>=0A>>>>>Draft is:=0A>>>>>http://t= ools.ietf.org/html/draft-ietf-appsawg-webfinger-17=0A>>>>>=0A>>>>>Those cha= nges are:=0A>>>>>=0A>>>>>- Section 2, added a new last paragraph to explain= what URI syntax we use in=0A>>>>>WebFinger=0A>>>>>- Corrected error in sec= tion 3.2 ("Host:" line in example and quotes around=0A>>>>>"3.2")=0A>>>>>- = We remove the words "absolute URI" since it's really redundant=0A>>>>>- Add= ed "query target" to 4.5 for clarity=0A>>>>>- Introduced a new section 8 th= at describes "WebFinger" applications. =C2=A0This=0A>>>>>is a major new add= ition.=0A>>>>>- Added a new section 10.3 and 10.4 to address registration o= f link relation=0A>>>>>types and properties. =C2=A0Link relations types alr= eady have a registry and we=0A>>>>>refer to existing procedures. =C2=A0WebF= inger properties did not have a registry,=0A>>>>>so we define one, primaril= y for the purpose of helping people avoid creating=0A>>>>>redundant definit= ions.=0A>>>>>=0A>>>>>If you have any questions or comments, please feel fre= e to post to the list.=0A>>>>>=0A>>>>>[[=0A>>>>>=C2=A0=C2=A0 The order of e= lements in the "links" array indicates an order of=0A>>>>>=C2=A0=C2=A0 pref= erence.=C2=A0 Thus, if there are two or more link relations having the=0A>>= >>>=C2=A0=C2=A0 same "rel" value, the first link relation would indicate th= e user's=0A>>>>>=C2=A0=C2=A0 preferred link.=0A>>>>>]]=0A>>>>>=C2=A0=0A>>>>= >Maybe remove this altogether, as I am unsure it can be guaranteed.=0A>>>>>= Case 1: Let's say I have a list of friends, how am I to determine as a serv= er the preferred friends?=C2=A0 How am I to determine as a client whether t= he friends are ordered or not?=0A>>>>>Case 2: Say I mash up data from two s= ources, how do I then order the combined list?=0A>>>>>=C2=A0=0A>>>>>=0A>>>>= >>=0A>>>>>>Paul=0A>>>>>>=0A>>>>>>=0A>>>>>>_________________________________= ______________=0A>>>>>>webfinger mailing list=0A>>>>>>webfinger@ietf.org=0A= >>>>>>https://www.ietf.org/mailman/listinfo/webfinger=0A>>>>>=C2=A0=0A>>>>= =C2=A0=0A>>>=C2=A0=0A>>>=0A>>>_____________________________________________= __=0A>>>webfinger mailing list=0A>>>webfinger@ietf.org=0A>>>https://www.iet= f.org/mailman/listinfo/webfinger=0A>>>=C2=A0=0A>>=C2=A0=0A>=C2=A0=0A=0A____= ___________________________________________=0Awebfinger mailing list=0Awebf= inger@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/webfinger ---685807438-28972646-1376953322=:70192 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
If client= s MAY ignore ordering then order can't be very important.  Order becom= es at most a requested preference.

&nbs= p;
-bill


--------------------------------
William = J. Mills
"Paranoid" Yahoo!


From:<= /b> Melvin Carvalho <melvincarvalho@gmail.com>
To: Paul E. Jones <paulej@packetizer.com>
<= span style=3D"font-weight: bold;">Cc: Bob Wyman <bob@wyman.us= >; Mike Jones <Michael.Jones@microsoft.com>; webfinger <webfing= er@ietf.org>
Sent:= Monday, August 19, 2013 3:54 PM
= Subject: Re: [webfinger] New WebFinger Draft posted
 =




On 19 August 2013 21:22, Paul E. Jones <paulej@packetizer.co= m> wrote:
=0A
=
Melvin,
=0A<= div class=3D"yiv6892543189MsoNormal"> 
If order is important= , then why would the server not have that information?  It either is o= r is not important, and I don=E2=80=99t see how one can say order is import= ant and then not consider order when data is collected.
=0A
 
I order ev= erything as I enter information into my database, but if there are items fo= r which I have no preference I just use the same priority value and don=E2= =80=99t worry about the order in which information is rendered.=0A

Very good point.  The= term "important" seems to be a subjective evaluation.

Mo= st data I have comes from some kind of relational or nosql style DB.  =
=0A
So as a server, when I'm getting data from a DB and s= erving it dynamically for webfinger record, I'll need to
A) subjectivel= y determine whether order is important
B) attempt to order the preferre= d items to the top
=0A
I dont naturally tend to keep lists= ordered (except maybe by timestamp), but I can start to, where I think it = matters.  Seems a slight extra implementation challenge, but something= probably doable when it matters ...
=0A
 
=
=0A
 
Paul
=0A
 
=0A
<= b>From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]
=0ASent: Monday, August 1= 9, 2013 1:29 PM

To:<= /b> Paul E. Jones
Cc: Bob Wyman; Mike Jones; webfinger
Subj= ect: Re: [webfinger] New WebFinger Draft posted
=0A<= /div>
 
 
 
=0AOn 19 August 2013 19:01, Paul E. Jones <= ;paulej@packetizer.com> wr= ote:
Melvin,=0A
 
Items in a JS= ON array are ordered by definition, so adding this language actually does n= ot change the fact that the list is ordered.  What it does, though, is= remind people that if they have information they would like to prioritize,= they can take advantage of the fact that arrays are ordered.=
=0A
 
So t= o answer your question, clients always know the links array is ordered :)
=0A
 
If I have two avatars that I would like to make available, do I car= e which one is selected?  If I do, then I should ensure the preferred = avatar is first.  If I do not, then it does not matter about order.&nb= sp; That said, it should be understood that some clients are likely to sele= ct the first avatar it encounters and some clients might not even look furt= her in the array to see if there are alternatives.  Other clients, tho= ugh, might actually offer all alternative avatars.=0A
 
Thanks for the explanation, I think I get this.

So,= as a client, lists are ordered by preference.
=0A
=
= As a server should order lists according to the information it has.  I= f it has that information, or the preference order is not important, then w= e're good. 
=0A
As a server if the order *is* important and we = dont have preference information, probably best to send nothing?  <= /u>
 <= /u>
= =0A
 
Paul
=0A
 
=0A
From: M= elvin Carvalho [mailto:melv= incarvalho@gmail.com]
=0ASent: Monday, August 19, 2013 12:41= PM
To: Paul E. Jones
Cc: Bob Wyman; Mike Jones; webfin= ger

Subject: Re: [webfinger] New WebFinger Draft posted=
=0A
 
 
 
On 19 August 2013 18:16, Paul E. Jones <paulej@packetizer.com> wrote:=
=0A
Bob,
 
=0A
I=E2=80=99m OK with = that change, if we=E2=80=99re permitted to make this type of change now.
=0A
 
I guess if it's too late it's not th= e end of the world.
=0AI do think Bob's change is an improvement.  But I stil= l dont quite understand how the client is supposed to know if it's dealing = with an ordered list or an unordered list.  
=
=0A 
 =0A
Paul
 =
=0A
From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] O= n Behalf Of Bob Wyman
=0ASent: Saturday, August 17, 2013 5:05= PM
To: Paul E. Jones
Cc: Melvin Carvalho; Mike Jones; = webfinger

Subject: Re: [webfinger] New WebFinger Draft posted<= /u>
=0A
 
I would prefer if the wording didn't require that order of listin= g is required to indicate a necessary order of preference. Thus, I suggest = the following wording:
=0A
The order of elements in the "links" array MAY be read as in=
dicating an order of preference.
The idea is to permit readers=
 to infer order of preference, and to allow writers to express that order, =
without requiring that a preferred order be determined or expressed. Where =
there is no preferred order, there will be no harm. Where there is a prefer=
red order, the right thing will happen.
=0A
bob wyman<=
/u>
 
=0AOn Sat, A= ug 17, 2013 at 4:29 PM, Paul E. Jones <paulej@packetizer.com> wrote:
= Why not have the client always offer items in the array in order? Any reaso= n to randomly select items from the array?
=0A
Paul<= u>
 
=0A=
From: Melvin Carvalho &l= t;melvincarvalho@gmail.com<= /a>>
=0A
Sent: Sat Aug 17 14:49:05 EDT 2013
=0ATo: Mike Jones= <Michael.Jones@mi= crosoft.com>
Cc: "Paul E. Jones" <paulej@packetizer.com>, webfinger <webfinger@ietf.org><= /div>=0A

Subject: Re: [webfinger] New WebFinger Draft post= ed
=0A
 
 
 
<= div class=3D"yiv6892543189MsoNormal">On 17 August 2013 20:45, Mike Jones &l= t;Michael.Jones@micro= soft.com> wrote:
=0A
When use= d, the ordering can do good.  When not used, it does no harm.  Pl= ease leave it in.
=0A
 
Mike, my question related to how the client can= *know* when it's used and when it's not used.  This seems unclear?=
=0A
 =
=0A
 
       = ;            &n= bsp;            = ;            &n= bsp;            = ;   Thanks,
=0A
  &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       -- Mike
=0A 
From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin= Carvalho
=0ASent: Saturday, August 17, 2013 11:40 AM
To: Paul E. Jones
Cc: webfinger

Subject: Re: [webfinger]= New WebFinger Draft posted
=0A
 
 
 =
On 17 August 2013 20:32, P= aul E. Jones <paulej@packetize= r.com> wrote:
=0A
Melvin,<= /div>
We have been asked about this before. If we leave it in, it meets= the needs of some. I admit there might be cases where it's hard to control= order, but if it matters, there is at least a way.
=0A<= div>In my own implementation, I assign an integer value to each entry and s= ort on that.
I have no strong objection either way,= but I do think it's good to have for those who care.
=0A
 
I understand the trade of= fs.  However, I can see that this is useful in many cases, particularl= y this would work well for openid, but other use cases, eg to have a friend= s list, for something like a federated social web, would then be perhaps im= practical with JRD (not the end of the world, though)
= =0A
 
=0A
Paul
 
=0A
From: Melvin Carvalho <melvincarvalho@gmail.com>
=0ASent: Sat Aug 17 = 14:12:11 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger &l= t;webfinger@ietf.org>
=0AS= ubject: Re: [webfinger] New WebFinger Draft posted=
 
 <= /div>
=0A 
On 9 August 2013 18:09, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,
=0A
As we're trying to bring the= WebFinger spec to a close, we published a new
version -17 with some cha= nges the WG might want to consider.

Draft is:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17<= br>=0A
Those changes are:

- Section 2, added a new last paragraph= to explain what URI syntax we use in
WebFinger
- Corrected error in = section 3.2 ("Host:" line in example and quotes around
"3.2")
=0A- We= remove the words "absolute URI" since it's really redundant
- Added "qu= ery target" to 4.5 for clarity
- Introduced a new section 8 that describ= es "WebFinger" applications.  This
=0Ais a major new addition.
-= Added a new section 10.3 and 10.4 to address registration of link relation=
types and properties.  Link relations types already have a registr= y and we
refer to existing procedures.  WebFinger properties did no= t have a registry,
=0Aso we define one, primarily for the purpose of hel= ping people avoid creating
redundant definitions.

If you have any= questions or comments, please feel free to post to the list.=
=0A
[[
   The order of elements in the "links" array indicates a=
n order of
   preference.  Thus, if =
there are two or more link relations having the
=0A
=
   same "rel" value, the first link relation would indicate the u=
ser's
   preferred link.
]]
 
=0AMaybe remove this altogether, as I am unsure it can be guaranteed.
Case 1: Let's say I have a list of friends, how am =
I to determine as a server the preferred friends?  How am I to determi=
ne as a client whether the friends are ordered or not?
=
=0A
Case 2: Say I mash up d=
ata from two sources, how do I then order the combined list?<=
/div>
 <=
/div>
=0A


=
Paul


_______________________________________________
webfinge=
r mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger
=0A
 
=
 
=0A 

____= ___________________________________________
webfinger mailing list
webfinger@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/webfinger
 
<= /div>
=0A
 
 
=0A


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


---685807438-28972646-1376953322=:70192-- From gsalguei@cisco.com Wed Aug 21 16:38: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 BEB6521F95DD for ; Wed, 21 Aug 2013 16:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 yddyduBSYLNF for ; Wed, 21 Aug 2013 16:38:14 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 594C221F93C4 for ; Wed, 21 Aug 2013 16:38:14 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7LNcBF7023632 for ; Thu, 22 Aug 2013 01:38:12 +0200 (CEST) Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7LNcAkx009859 for ; Wed, 21 Aug 2013 19:38:10 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> Date: Wed, 21 Aug 2013 19:38:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <087c01ce951a$e32da1f0$a988e5d0$@packetizer.com> To: webfinger X-Mailer: Apple Mail (2.1508) Subject: Re: [webfinger] New WebFinger Draft posted 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, 21 Aug 2013 23:38:18 -0000 Folks -=20 The last DISCUSS has finally been cleared!! A new version (-18) will be = published in the next few days addressing the final minor edits that = came from this final round of IESG review. This is a final plea to = please review the document (particularly the new Section 8 and = sub-sections 10.3 and 10.4) to ensure that you agree with us that = everything is in order and the document is in fact ready to go to the = RFC Editor for publication. As we get through this final hurdle, I'm reminded to thank all of you = for your continued dedication throughout this long (and sometimes = arduous) journey.=20 Gonzalo On Aug 9, 2013, at 12:09 PM, Paul E. Jones = wrote: > Folks, >=20 > As we're trying to bring the WebFinger spec to a close, we published a = new > version -17 with some changes the WG might want to consider. >=20 > Draft is: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 >=20 > Those changes are: >=20 > - Section 2, added a new last paragraph to explain what URI syntax we = use in > WebFinger > - Corrected error in section 3.2 ("Host:" line in example and quotes = around > "3.2") > - We remove the words "absolute URI" since it's really redundant > - Added "query target" to 4.5 for clarity > - Introduced a new section 8 that describes "WebFinger" applications. = This > is a major new addition. > - Added a new section 10.3 and 10.4 to address registration of link = relation > types and properties. Link relations types already have a registry = and we > refer to existing procedures. WebFinger properties did not have a = registry, > so we define one, primarily for the purpose of helping people avoid = creating > redundant definitions. >=20 > If you have any questions or comments, please feel free to post to the = list. >=20 >=20 > Paul >=20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 From paulej@packetizer.com Wed Aug 21 19:24: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 C1D3511E81A5 for ; Wed, 21 Aug 2013 19:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 HjeeIw9-Pba0 for ; Wed, 21 Aug 2013 19:23:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4430611E8172 for ; Wed, 21 Aug 2013 19:23:58 -0700 (PDT) Received: from sydney (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 r7M2NvvY013407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 21 Aug 2013 22:23:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1377138237; bh=YWWoA5JmWgcC21TOmgqJenDL1e8V1oxaxPhqaULXNw8=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=FlzdQn6ecpeEgs0Qke/owsoAXa4OFrVXks6xmA1YiqdwA4w5v0LqRtW+79X5naoft ckyxVRmaA28WzRKEYUYpCrltKKqEoYqs3Isz2F5YbO1xCNoMhzcjdM6d6/CEfHJPas DsL/mDH9pxdaOWkMUWlgtEr56+BLDoBJneVanQ9E= From: "Paul E. Jones" To: "'webfinger'" Date: Wed, 21 Aug 2013 22:24:13 -0400 Message-ID: <068401ce9ede$b199d460$14cd7d20$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: Ac6e3rFEf/XUv/OATyC2YmNOgddEkQ== Content-Language: en-us Subject: [webfinger] Proposed changes for WebFinger draft -18 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, 22 Aug 2013 02:24:09 -0000 Folks, As Gonzalo mentioned, the last blocking DISCUSS points were cleared for WebFinger. However, a few additional changes were suggested for the WebFinger draft. Some are just editorial and I do not think people will object, though you are certainly welcome to comment on any change once we post the new version. The proposed changes I think might be of concern, I want to mention now. In section 4, this change is suggested: OLD: the host to which the WebFinger query is issued MUST be NEW: the host to which the WebFinger query is issued SHOULD be In section 8.5, this change is suggested: OLD: not fully understood SHOULD be ignored and MUST NOT cause NEW: not fully understood SHOULD be ignored and SHOULD NOT cause Any objection to these MUSTs changing to SHOULD? Paul From Michael.Jones@microsoft.com Wed Aug 21 20:20: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 76F5D11E818C for ; Wed, 21 Aug 2013 20:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.403 X-Spam-Level: X-Spam-Status: No, score=-3.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, 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 XkUdMf5TDm0h for ; Wed, 21 Aug 2013 20:20:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2F45711E817C for ; Wed, 21 Aug 2013 20:20:33 -0700 (PDT) Received: from BLUPR03CA036.namprd03.prod.outlook.com (10.141.30.29) by BLUPR03MB003.namprd03.prod.outlook.com (10.255.208.37) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 22 Aug 2013 03:20:27 +0000 Received: from BN1AFFO11FD022.protection.gbl (2a01:111:f400:7c10::26) by BLUPR03CA036.outlook.office365.com (2a01:111:e400:879::29) with Microsoft SMTP Server (TLS) id 15.0.745.25 via Frontend Transport; Thu, 22 Aug 2013 03:20:27 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD022.mail.protection.outlook.com (10.58.52.82) with Microsoft SMTP Server (TLS) id 15.0.745.15 via Frontend Transport; Thu, 22 Aug 2013 03:20:26 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.178]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Thu, 22 Aug 2013 03:18:54 +0000 From: Mike Jones To: "Paul E. Jones" , 'webfinger' Thread-Topic: [webfinger] Proposed changes for WebFinger draft -18 Thread-Index: Ac6e3rFEf/XUv/OATyC2YmNOgddEkQAB7nuQ Date: Thu, 22 Aug 2013 03:18:54 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436B7CC841@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <068401ce9ede$b199d460$14cd7d20$@packetizer.com> In-Reply-To: <068401ce9ede$b199d460$14cd7d20$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464003)(189002)(199002)(377454003)(6806004)(51856001)(47976001)(19580395003)(66066001)(50986001)(46102001)(55846006)(77982001)(74366001)(59766001)(44976005)(33656001)(83322001)(76796001)(81816001)(76786001)(81686001)(19580385001)(63696002)(19580405001)(83072001)(23726002)(4396001)(47776003)(79102001)(74876001)(69226001)(54356001)(53806001)(50466002)(81542001)(74706001)(49866001)(65816001)(80022001)(46406003)(47736001)(56816003)(20776003)(77096001)(74662001)(47446002)(80976001)(76482001)(54316002)(81342001)(56776001)(31966008)(74502001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB003; H:mail.microsoft.com; CLIP:131.107.125.37; 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: 0946DC87A1 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 131.107.125.37 X-MS-Exchange-CrossPremises-AuthSource: BN1AFFO11FD022.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: BLUPR03MB003.namprd03.prod.outlook.com Subject: Re: [webfinger] Proposed changes for WebFinger draft -18 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, 22 Aug 2013 03:20:40 -0000 Fine by me -----Original Message----- From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Paul E. Jones Sent: Wednesday, August 21, 2013 7:24 PM To: 'webfinger' Subject: [webfinger] Proposed changes for WebFinger draft -18 Folks, As Gonzalo mentioned, the last blocking DISCUSS points were cleared for Web= Finger. However, a few additional changes were suggested for the WebFinger= draft. Some are just editorial and I do not think people will object, tho= ugh you are certainly welcome to comment on any change once we post the new= version. The proposed changes I think might be of concern, I want to mention now. In section 4, this change is suggested: OLD: the host to which the WebFinger query is issued MUST be NEW: the host to which the WebFinger query is issued SHOULD be In section 8.5, this change is suggested: OLD: not fully understood SHOULD be ignored and MUST NOT cause NEW: not fully understood SHOULD be ignored and SHOULD NOT cause Any objection to these MUSTs changing to SHOULD? Paul _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger From melvincarvalho@gmail.com Wed Aug 21 20:45: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 60E9C11E8244 for ; Wed, 21 Aug 2013 20:45:10 -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 Slk4-jQpMtUl for ; Wed, 21 Aug 2013 20:45:09 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BB33F11E822F for ; Wed, 21 Aug 2013 20:45:05 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id eh20so991823lab.32 for ; Wed, 21 Aug 2013 20:45:03 -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=SMl+JOoE2Vmnz8Oxq7KQe/b7gR9MDZ4HJgOW8gUcu0k=; b=YAF4H8J0uNci6sjjLQ4iL+UPlJ/TMrt/t+qIriH3AUnsj5HHnJGodKS11BdT0QAZ6f /2YmCrMlrFTjVh2eYrctBk/YoXPHzQBKbuurL67QZrGfsGVfYzvJlhU+DBqzCn4NnkNg ZIQo0cZZcBAbHmL+cMFFej9OaJP1CvzSrWfljgKexNMjj+li5KKy31Hs+mmDaNBdF45K B8AmVfj8erBKQBgHh6lPzjAoLXq694njxOwzAXpTMnJdClBvGFKg+Q00RwC1WzVL8g/V uK466Hj47bIIaSFarwIIy5tXu+C4lxUGTHkeTQsVMCHxyiCjIzzpi9t10v3dljL2X61D VuXQ== MIME-Version: 1.0 X-Received: by 10.152.3.42 with SMTP id 10mr8880646laz.22.1377143103399; Wed, 21 Aug 2013 20:45:03 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Wed, 21 Aug 2013 20:45:03 -0700 (PDT) In-Reply-To: <068401ce9ede$b199d460$14cd7d20$@packetizer.com> References: <068401ce9ede$b199d460$14cd7d20$@packetizer.com> Date: Thu, 22 Aug 2013 05:45:03 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e013d14b27bac4604e4811da3 Cc: webfinger Subject: Re: [webfinger] Proposed changes for WebFinger draft -18 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, 22 Aug 2013 03:45:10 -0000 --089e013d14b27bac4604e4811da3 Content-Type: text/plain; charset=ISO-8859-1 On 22 August 2013 04:24, Paul E. Jones wrote: > Folks, > > As Gonzalo mentioned, the last blocking DISCUSS points were cleared for > WebFinger. However, a few additional changes were suggested for the > WebFinger draft. Some are just editorial and I do not think people will > object, though you are certainly welcome to comment on any change once we > post the new version. > > The proposed changes I think might be of concern, I want to mention now. > > In section 4, this change is suggested: > > OLD: > the host to which the WebFinger query is issued MUST be > NEW: > the host to which the WebFinger query is issued SHOULD be > > In section 8.5, this change is suggested: > > OLD: > not fully understood SHOULD be ignored and MUST NOT cause > NEW: > not fully understood SHOULD be ignored and SHOULD NOT cause > > Any objection to these MUSTs changing to SHOULD? > +1 > > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > --089e013d14b27bac4604e4811da3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 22 August 2013 04:24, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:
Folks,

As Gonzalo mentioned, the last blocking DISCUSS points were cleared for
WebFinger. =A0However, a few additional changes were suggested for the
WebFinger draft. =A0Some are just editorial and I do not think people will<= br> object, though you are certainly welcome to comment on any change once we post the new version.

The proposed changes I think might be of concern, I want to mention now.
In section 4, this change is suggested:

OLD:
=A0 =A0the host to which the WebFinger query is issued MUST be
NEW:
=A0 =A0the host to which the WebFinger query is issued SHOULD be

In section 8.5, this change is suggested:

OLD:
=A0 =A0 not fully understood SHOULD be ignored and MUST NOT cause
NEW:
=A0 =A0 not fully understood SHOULD be ignored and SHOULD NOT cause

Any objection to these MUSTs changing to SHOULD?

+= 1
=A0

Paul


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

--089e013d14b27bac4604e4811da3-- From nick@silverbucket.net Thu Aug 22 07:13: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 3E18621F9E9C for ; Thu, 22 Aug 2013 07:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 XnKhdR7UURNa for ; Thu, 22 Aug 2013 07:13:04 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7950C21F8C72 for ; Thu, 22 Aug 2013 07:13:03 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ea20so1469095lab.27 for ; Thu, 22 Aug 2013 07:13:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aqKtr3x6Z8QuAX1IsHS37zhsgIDJAvFfRHX8NPAgeMM=; b=cbOp/L/KilObyXVgdqNkIRacHOGe0Vv6cHZEIskcYI59dcVHskssBtmRPbOcQeyVx7 S9+XZTYOt1dCktkbPU2AyOvdke8e/hantq8Xx8sXNXUiYG+xba3PFfM3LLbYsAaGKKNP QcpAMV9ddtWjWxLGB41R5x1rhkf0aWxQMyGoVRylAUzLw4JvkL/fnpKQhJX8BN3eIAy7 YwQDNRXRM/PYubnAfII8A6JBj37A/qBhTp7jmYcaBYk72ilwkiUQ8Yrafo2ovA/iiCy2 bmmShxrsvATA+Z1XfMmFw76kYOv9eQnmapM5+8ZCopfTP3Ps6g5UxQPQe5cNRf35tPwJ KW3g== X-Gm-Message-State: ALoCoQmLZxowrb41DcPdMmWBrXJxOptyusQNPVLylemrofwkTdLaoP3bI64+pP2LmVWahaFkcOxq X-Received: by 10.152.115.176 with SMTP id jp16mr10891380lab.17.1377180782084; Thu, 22 Aug 2013 07:13:02 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [2a00:1450:4010:c03::232]) by mx.google.com with ESMTPSA id u18sm5073915lbp.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Aug 2013 07:13:01 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ek20so1418598lab.23 for ; Thu, 22 Aug 2013 07:13:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.37.103 with SMTP id x7mr2284809laj.28.1377180780733; Thu, 22 Aug 2013 07:13:00 -0700 (PDT) Received: by 10.112.42.109 with HTTP; Thu, 22 Aug 2013 07:13:00 -0700 (PDT) Received: by 10.112.42.109 with HTTP; Thu, 22 Aug 2013 07:13:00 -0700 (PDT) In-Reply-To: <068401ce9ede$b199d460$14cd7d20$@packetizer.com> References: <068401ce9ede$b199d460$14cd7d20$@packetizer.com> Date: Thu, 22 Aug 2013 16:13:00 +0200 Message-ID: From: Nick Jennings To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e0160b5e43a2ce204e489e349 Cc: webfinger Subject: Re: [webfinger] Proposed changes for WebFinger draft -18 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, 22 Aug 2013 14:13:08 -0000 --089e0160b5e43a2ce204e489e349 Content-Type: text/plain; charset=UTF-8 Looks good On Aug 22, 2013 4:24 AM, "Paul E. Jones" wrote: > Folks, > > As Gonzalo mentioned, the last blocking DISCUSS points were cleared for > WebFinger. However, a few additional changes were suggested for the > WebFinger draft. Some are just editorial and I do not think people will > object, though you are certainly welcome to comment on any change once we > post the new version. > > The proposed changes I think might be of concern, I want to mention now. > > In section 4, this change is suggested: > > OLD: > the host to which the WebFinger query is issued MUST be > NEW: > the host to which the WebFinger query is issued SHOULD be > > In section 8.5, this change is suggested: > > OLD: > not fully understood SHOULD be ignored and MUST NOT cause > NEW: > not fully understood SHOULD be ignored and SHOULD NOT cause > > Any objection to these MUSTs changing to SHOULD? > > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > --089e0160b5e43a2ce204e489e349 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Looks good

On Aug 22, 2013 4:24 AM, "Paul E. Jones&quo= t; <paulej@packetizer.com&g= t; wrote:
Folks,

As Gonzalo mentioned, the last blocking DISCUSS points were cleared for
WebFinger. =C2=A0However, a few additional changes were suggested for the WebFinger draft. =C2=A0Some are just editorial and I do not think people wi= ll
object, though you are certainly welcome to comment on any change once we post the new version.

The proposed changes I think might be of concern, I want to mention now.
In section 4, this change is suggested:

OLD:
=C2=A0 =C2=A0the host to which the WebFinger query is issued MUST be
NEW:
=C2=A0 =C2=A0the host to which the WebFinger query is issued SHOULD be

In section 8.5, this change is suggested:

OLD:
=C2=A0 =C2=A0 not fully understood SHOULD be ignored and MUST NOT cause
NEW:
=C2=A0 =C2=A0 not fully understood SHOULD be ignored and SHOULD NOT cause
Any objection to these MUSTs changing to SHOULD?

Paul


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger
--089e0160b5e43a2ce204e489e349-- From paulej@packetizer.com Mon Aug 26 20:56:09 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 CD6AF11E8133 for ; Mon, 26 Aug 2013 20:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.034, 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 qmS7vd0mitau for ; Mon, 26 Aug 2013 20:56:02 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0163721F9DB8 for ; Mon, 26 Aug 2013 20:55:44 -0700 (PDT) Received: from sydney (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 r7R3tdNa010076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 26 Aug 2013 23:55:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1377575739; bh=UlSedKGMN9bAZUSvdPpr0MW4VLMzMOMU8VMBx12Fg2Q=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=JG1Pnso8sS+EBTdNTu7zyytAzCWorJapDi9D6aH+JhZV9NjAVdbn4jSQcMgM/pLTd GgmUnWPRRcO3fEBJXs4VTJCCP7l2efzWt9Np/0hkrBe1XP8JxuBChZEGqnK80P8Ixp gWFfNRFryjhCJiPOtqdux9nK1mxuG9ZzSgKhqCrI= From: "Paul E. Jones" To: "'webfinger'" References: <20130827035003.7204.68870.idtracker@ietfa.amsl.com> In-Reply-To: <20130827035003.7204.68870.idtracker@ietfa.amsl.com> Date: Mon, 26 Aug 2013 23:55:43 -0400 Message-ID: <027c01cea2d9$4db2ced0$e9186c70$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVw0aZaYjuZio+Y7JkvjfqkW9QXpkaKz2Q Content-Language: en-us Subject: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-18.txt 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, 27 Aug 2013 03:56:10 -0000 Folks, We just posted a new version of the WebFinger spec. I highlighted some of the more important issues previously, but please do have a look over the current text and make sure it looks OK. I'm hoping this might be the last set of significant changes. Note that Mike Jones is now listed as a co-author. He has been doing a lot of work on this document and I'm pleased that he was able to be properly credited as a co-author. Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: Monday, August 26, 2013 11:50 PM > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-18.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : WebFinger > Author(s) : Paul E. Jones > Gonzalo Salgueiro > Michael B. Jones > Joseph Smarr > Filename : draft-ietf-appsawg-webfinger-18.txt > Pages : 25 > Date : 2013-08-26 > > Abstract: > This specification defines the WebFinger protocol, which can be used > to discover information about people or other entities on the > Internet using standard HTTP methods. WebFinger discovers > information for a URI that might not be usable as a locator > otherwise, such as account or email URIs. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-18 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-18 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From barryleiba@gmail.com Tue Aug 27 07:11:55 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 16C5011E80FA; Tue, 27 Aug 2013 07:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.983 X-Spam-Level: X-Spam-Status: No, score=-101.983 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 npyIaO0X3agf; Tue, 27 Aug 2013 07:11:54 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7F95711E8312; Tue, 27 Aug 2013 07:11:54 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id f6so2599158qej.19 for ; Tue, 27 Aug 2013 07:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=sukUIGXRSI6vvS2kn5qRBHcfAT1FvknlRzZ8HYBS4yU=; b=JjAGRyr6YPb2MajALzoNK0s+mCVrSbKy2dNtrUaDDifBSyGI5U9wf2dZD+26EZpZCr SAnGzWS9EeSXVzoycDNlXCY1qphPRC1FIMm3t2q37KbUvxU8J7Bz7LqNUUQcXpgfkyKW 5xlVPuLavhGpt6Tpyt4EKUyQjbJTOdlqSUMdIqu3dImoTNbaG1KZe8Cgmxgrc3NQdfPo 8q/2sYs4P6dpgIBUr6OBr7l69o4HsRf62h6wgiYsLz/2M1GYmylwB3mCCPQ/scmhW/YC 8IYSuy3T3cymbsNFc8UGU9x8YBb0znDrWpRi6iLEFLs+onse5g+kaz1ZXZKAwZuFiBjt R2dQ== MIME-Version: 1.0 X-Received: by 10.49.106.226 with SMTP id gx2mr15423149qeb.67.1377612713662; Tue, 27 Aug 2013 07:11:53 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Tue, 27 Aug 2013 07:11:53 -0700 (PDT) Date: Tue, 27 Aug 2013 10:11:53 -0400 X-Google-Sender-Auth: AfzahSKszS4LEwQ1LygOoY9XFHw Message-ID: From: Barry Leiba To: IESG Content-Type: text/plain; charset=ISO-8859-1 Cc: "webfinger@ietf.org" , Apps Discuss Subject: [webfinger] Approved: draft-ietf-appsawg-webfinger-18 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, 27 Aug 2013 14:11:55 -0000 IESG Secretary (bcc), with FYI to the webfinger and apps-discuss lists: The subject draft is ready for approval, with all DISCUSSes cleared, non-blocking comments reasonably addressed, and final reviews and cross-checks done. No RFC Editor notes needed. Please send out the approval notice, and thanks. Barry From stpeter@stpeter.im Tue Aug 27 08:38: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 EA9A621E808C for ; Tue, 27 Aug 2013 08:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, 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 4-tK0Vi+TmmW for ; Tue, 27 Aug 2013 08:38:03 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3E99411E8357 for ; Tue, 27 Aug 2013 08:37:39 -0700 (PDT) Received: from sjc-vpn5-164.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9231241554; Tue, 27 Aug 2013 09:41:19 -0600 (MDT) Message-ID: <521CC7C0.2070206@stpeter.im> Date: Tue, 27 Aug 2013 09:37:36 -0600 From: Peter Saint-Andre 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: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [webfinger] Approved: draft-ietf-appsawg-webfinger-18 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, 27 Aug 2013 15:38:12 -0000 Congratulations to the editorial team for completing this work! On 8/27/13 8:11 AM, Barry Leiba wrote: > IESG Secretary (bcc), with FYI to the webfinger and apps-discuss lists: > > The subject draft is ready for approval, with all DISCUSSes cleared, > non-blocking comments reasonably addressed, and final reviews and > cross-checks done. No RFC Editor notes needed. Please send out the > approval notice, and thanks. From perpetual-tripper@wwelves.org Tue Aug 27 14:52: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 242EC11E824C for ; Tue, 27 Aug 2013 14:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 5FTQZrzkQi9r for ; Tue, 27 Aug 2013 14:52:19 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCF811E8238 for ; Tue, 27 Aug 2013 14:52:16 -0700 (PDT) Received: from mfilter13-d.gandi.net (mfilter13-d.gandi.net [217.70.178.141]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id E9ED4172095 for ; Tue, 27 Aug 2013 23:52:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter13-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter13-d.gandi.net (mfilter13-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 05fcKFQ1MqAu for ; Tue, 27 Aug 2013 23:52:01 +0200 (CEST) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 12B2517209F for ; Tue, 27 Aug 2013 23:52:01 +0200 (CEST) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: webfinger In-reply-to: <521CC7C0.2070206@stpeter.im> References: <521CC7C0.2070206@stpeter.im> Date: Tue, 27 Aug 2013 21:51:58 +0000 Message-Id: <1377640201-sup-8065@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Subject: Re: [webfinger] Approved: draft-ietf-appsawg-webfinger-18 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, 27 Aug 2013 21:52:26 -0000 Excerpts from Peter Saint-Andre's message of 2013-08-27 15:37:36 +0000: > On 8/27/13 8:11 AM, Barry Leiba wrote: > > IESG Secretary (bcc), with FYI to the webfinger and apps-discuss list= s: > >=20 > > The subject draft is ready for approval, with all DISCUSSes cleared, > > non-blocking comments reasonably addressed, and final reviews and > > cross-checks done. No RFC Editor notes needed. Please send out the > > approval notice, and thanks. > > Congratulations to the editorial team for completing this work! >=20 +1 i must admit that observing this process seamed like never ending stor= y ;) CONGRATULATIONS!!!