Re: [webfinger] New WebFinger Draft posted

Melvin Carvalho <melvincarvalho@gmail.com> Sun, 18 August 2013 05:14 UTC

Return-Path: <melvincarvalho@gmail.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 E8B5A11E81C9 for <webfinger@ietfa.amsl.com>; 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 <webfinger@ietfa.amsl.com>; 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 <webfinger@ietf.org>; Sat, 17 Aug 2013 22:14:07 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id er20so2530071lab.35 for <webfinger@ietf.org>; 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: <CAA1s49X5_q-ZuD0GymuNQOdkyqE81yZW9=FRyVGgca6uk+zJ6Q@mail.gmail.com>
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>
Date: Sun, 18 Aug 2013 07:14:05 +0200
Message-ID: <CAKaEYhJMCY0Rz99-TdCuvi1tQ+1hd11js_=xPsDLqLQ7iEcZmw@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Bob Wyman <bob@wyman.us>
Content-Type: multipart/alternative; boundary=001a11c379ec8a5b3b04e431e457
Cc: "Paul E. Jones" <paulej@packetizer.com>, 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
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: Sun, 18 Aug 2013 05:14:11 -0000

On 17 August 2013 23:04, Bob Wyman <bob@wyman.us> 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 no 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 <paulej@packetizer.com>wrote;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>om>, 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
>>
>>
>