Re: [webfinger] New WebFinger Draft posted

Melvin Carvalho <melvincarvalho@gmail.com> Mon, 19 August 2013 17:28 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 0652D11E8130 for <webfinger@ietfa.amsl.com>; 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 <webfinger@ietfa.amsl.com>; 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 <webfinger@ietf.org>; Mon, 19 Aug 2013 10:28:39 -0700 (PDT)
Received: by mail-lb0-f180.google.com with SMTP id a16so826622lbj.25 for <webfinger@ietf.org>; 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> <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>
Date: Mon, 19 Aug 2013 19:28:37 +0200
Message-ID: <CAKaEYhJjhHK-636qv6UFW=SyNopYzNMk1UnvWy+uXmyBQ1kkpQ@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Content-Type: multipart/alternative; boundary=089e0160bab0481b7604e45045c6
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
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 17:28:42 -0000

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