Re: [webfinger] Registration of a URN for WebFinger Properties

"Paul E. Jones" <> Thu, 10 October 2013 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D38DA21E8084 for <>; Thu, 10 Oct 2013 15:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.189
X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZDgvuq4IPWif for <>; Thu, 10 Oct 2013 15:34:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2E41621E8132 for <>; Thu, 10 Oct 2013 15:34:07 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id r9AMY4jV007235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Oct 2013 18:34:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=dublin; t=1381444445; bh=j9trCzF0f1zynafJBAZn1zd/JtEuzP5hbWHGcSmJh9Q=; h=From:To:Subject:Cc:Date:Content-Type:In-Reply-To:Message-Id: Mime-Version:Reply-To; b=rdSppE3ym71KWrFCQVIAMicMohbmtvuz0pV3v9Y3yKeuDJ8/NYgH1ILNja8IRiwIO r1EsQXBcRsZITTWHldv523TBo1ose3IK5S4+GrSCXQYShKTADr4DCMn81uMuwzgf8N I8aS/Zov4QzRYYY8JdAjaUf4dZJNdhP9MNDAGsz8=
From: "Paul E. Jones" <>
To: Will Norris <>
Date: Thu, 10 Oct 2013 22:34:17 +0000
Content-Type: multipart/alternative; boundary="------=_MB78F8CBF5-659F-47B9-B8B6-6C625B1048EC"
In-Reply-To: <>
Message-Id: <emc6f90b62-06ec-46e9-8b46-c7292c288130@sydney>
Mime-Version: 1.0
User-Agent: eM_Client/5.0.18661.0
Cc: webfinger <>, Melvin Carvalho <>
Subject: Re: [webfinger] Registration of a URN for WebFinger Properties
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "Paul E. Jones" <>
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, 10 Oct 2013 22:34:14 -0000


The reason is to have one set of identifiers that people can agree to 
use.  There are two types of identifiers, too:
     * Link relations types
     * Properties

As you point out, there are several link relations already defined.  
I've cataloged some of them:

Some that are interesting to me did not exist,  so I made up values.

There are also properties, and I've not seen any described formally 
anywhere.  I've defined a ones I find useful:

There are more defined out there, I'm sure.  And it's perfectly OK for 
applications to define whatever they want.

However, there are a few that I think really should be defined by the 
IETF.  If we don't do that, then we at least need to have an informal 
agreement on, for example, how to get a person's name.  Otherwise, some 
link relation types or property identifiers are likely to get defined 
with 10 different identifiers, yet carry the same semantics.


------ Original Message ------
From: "Will Norris" <>
To: "Paul E. Jones" <>
Cc: "Melvin Carvalho" <>; "webfinger" 
Sent: 10/10/2013 1:48:59 PM
Subject: Re: [webfinger] Registration of a URN for WebFinger Properties
>There irony here is that WebFinger itself was created to solve the 
>problem of resolving an otherwise unresolvable URI (originally mailto 
>and later acct URIs).  URNs have the same problem, and since they have 
>no well-defined host, you can't even use WebFinger to resolve them.  I 
>know there have been some efforts to define URN resolution (rfc2483 et 
>al), but as far as I know none are very well adopted.  Using HTTP URIs 
>makes the most sense to me.
>But do we really need yet another registry of properties, the vast 
>majority of which I'm sure have been defined in a dozen other places?  
>Is there a reason why reusing one of these existing namespaces would 
>not work?  (and if something WebFinger specific really is desirable, 
>then we can continue using, which has already been used 
>for and 
>  That was kind of the idea of 
>running it as a static site out of the GitHub "webfinger" org; it's 
>very easy to give others access to everything.  That's what we've done 
>with for several years now)
>On Sun, Oct 6, 2013 at 8:16 AM, Paul E. Jones <> 
>>Yes, any URI can be used to identify a property. However, there has to 
>>be some agreed scheme and structure for things defined in the IETF. 
>>The point of the suggestion was to specify that.
>>We could use HTTP, but I've never seen that scheme used in IETF 
>>documents for this type of thing. I've seen URNs, though.
>>From: Melvin Carvalho <>
>>Sent: Sun Oct 06 09:19:42 EDT 2013
>>To: "Paul E. Jones" <>
>>Cc: webfinger <>
>>Subject: Re: [webfinger] Registration of a URN for WebFinger 
>>On 5 October 2013 03:22, Paul E. Jones <> wrote:
>>>As you know, properties (both link and subject-specific properties) 
>>>are identified via a URI.  For applications that are defined outside 
>>>the IETF, those organizations are able to define any URI they wish to 
>>>use.  For any we might define within the IETF, however, we need 
>>>In anticipation of having such a need, I think we should create a 
>>>document along the lines of RFC 6755 for WebFinger.  Specifically, we 
>>>would define a URN sub-namespace as:
>>>    urn:ietf:params:webfinger
>>>One such potentially-useful subject-specific properties are "name", 
>>>which would be the the subject's name intended for human consumption. 
>>>  If you've queried my WebFinger server, you would know I currently 
>>>advertise my name in English and Chinese.  For the "default" name, 
>>>the URN might be:
>>>    urn:ietf:params:webfinger:name
>>>For language-specific variants, it might be:
>>>    urn:ietf:params:webfinger:name:zh-CN
>>>Defining the various properties and their meaning is an exercise for 
>>>another day, but I hope you see the value in defining the URN 
>>Cant this be done using traditional HTTP keys.  The advantage being 
>>that they can be systematically dereferenced using http GET, rather 
>>than having to look it up in a central registry in a non machine 
>>readable way.  This is what has been going on for 10+ years, with 
>>FOAF,, open graph protocol and others.  Have I missed 
>>>webfinger mailing list
>>webfinger mailing list