Re: [webfinger] New WebFinger Draft posted

"Paul E. Jones" <> Mon, 19 August 2013 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C9A911E812B for <>; Mon, 19 Aug 2013 10:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.498
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FVaOBlRSrvnx for <>; Mon, 19 Aug 2013 10:01:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 700C711E80DF for <>; Mon, 19 Aug 2013 10:01:27 -0700 (PDT)
Received: from sydney ( []) (authenticated bits=0) by (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;; 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$> <> <> <> <> <> <> <> <028601ce9cf7$74da6cd0$5e8f4670$> <>
In-Reply-To: <>
Date: Mon, 19 Aug 2013 13:01:36 -0400
Message-ID: <02c701ce9cfd$c441ab20$4cc50160$>
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-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



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.




From: Melvin Carvalho [] 
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:



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.   





From: [] 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 <>

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




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?




                                                            -- Mike


From: [] 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:


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)





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:


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:

Those changes are:

- Section 2, added a new last paragraph to explain what URI syntax we use in
- Corrected error in section 3.2 ("Host:" line in example and quotes around
- 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?



webfinger mailing list




webfinger mailing list