Re: [webfinger] New WebFinger Draft posted

Bill Mills <wmills@yahoo-inc.com> Mon, 19 August 2013 23:02 UTC

Return-Path: <wmills@yahoo-inc.com>
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 <webfinger@ietfa.amsl.com>; 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 <webfinger@ietfa.amsl.com>; 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 <webfinger@ietf.org>; 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 <webfinger@ietf.org>; 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> <CAKaEYh+i38utNp=ML3Qnut2OeoKPRPKhpquUOx5UUqp1Y+Pyiw@mail.gmail.com> <ac5fdc3a-01e3-4af6-a013-1b1a90b17a0e@email.android.com> <CAKaEYhK-AZ8D40p92aon1m338q4nHNegsx5PyK-dKJtyXVCjbQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739436B7A8D1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <CAKaEYhK6JR5TW8JuRMwe-84MGXdeek7pgQZTC1CGB_8oyuct8Q@mail.gmail.com> <dc25a47b-6249-4165-86ec-762a24177d49@email.android.com> <CAA1s49X5_q-ZuD0GymuNQOdkyqE81yZW9=FRyVGgca6uk+zJ6Q@mail.gmail.com> <028601ce9cf7$74da6cd0$5e8f4670$@packetizer.com> <CAKaEYhJhrwGFhq_rdwrK3tFPztQ1wde-N6WZH5WqcSK8SJ=SaQ@mail.gmail.com> <02c701ce9cfd$c441ab20$4cc50160$@packetizer.com> <CAKaEYhJjhHK-636qv6UFW=SyNopYzNMk1UnvWy+uXmyBQ1kkpQ@mail.gmail.com> <033801ce9d11$696848d0$3c38da70$@packetizer.com> <CAKaEYhK=4G48t3DDAbwUEvNUQ73RdfAO=YkbJnQ=1th6HtV_YA@mail.gmail.com>
Message-ID: <1376953322.70192.YahooMailNeo@web125604.mail.ne1.yahoo.com>
Date: Mon, 19 Aug 2013 16:02:02 -0700
From: Bill Mills <wmills@yahoo-inc.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>, "Paul E. Jones" <paulej@packetizer.com>
In-Reply-To: <CAKaEYhK=4G48t3DDAbwUEvNUQ73RdfAO=YkbJnQ=1th6HtV_YA@mail.gmail.com>
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 <bob@wyman.us>, Mike Jones <Michael.Jones@microsoft.com>, webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] New WebFinger Draft posted
X-BeenThere: webfinger@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Bill Mills <wmills@yahoo-inc.com>
List-Id: Discussion of the Webfinger protocol proposal in the Applications Area <webfinger.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webfinger>, <mailto:webfinger-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/webfinger>
List-Post: <mailto:webfinger@ietf.org>
List-Help: <mailto:webfinger-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webfinger>, <mailto:webfinger-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Aug 2013 23:02:40 -0000

If clients MAY ignore ordering then order can't be very important.  Order becomes at most a requested preference.


 
-bill



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




________________________________
 From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Paul E. Jones <paulej@packetizer.com> 
Cc: Bob Wyman <bob@wyman.us>; Mike Jones <Michael.Jones@microsoft.com>; webfinger <webfinger@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.com> 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’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.

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 <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
>> 
>> 
>> 
>>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
>>> 
>>>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>
>>>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
>>>>> 
>>>> 
>>> 
>>>
>>>_______________________________________________
>>>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