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

Will Norris <> Fri, 11 October 2013 18:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C39DA21F9DE1 for <>; Fri, 11 Oct 2013 11:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8jb0egbHkIoC for <>; Fri, 11 Oct 2013 11:58:04 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::234]) by (Postfix) with ESMTP id 34FF311E819F for <>; Fri, 11 Oct 2013 11:57:39 -0700 (PDT)
Received: by with SMTP id m15so4713215wgh.7 for <>; Fri, 11 Oct 2013 11:57:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=P3pgsJA9XuGZe5TnIU9gSob7fl2agRgQU43Z1mfafqo=; b=PXcs3AfaKWHCN38hHhIMlRGgimUv7LYyh8JP45nidtdZ/OmQ89xxPOu9aE/PvPaz7Q b3cwrQPdFDDfQKn8+zdw/cLWMSumleF3KWP5JqshShZyUyJ0izpyZGfc5oONSUJBbGnp zr5maJ2uJuu0lqcwxh0Tm9UFX4D5Pply2AmqQ+rw6zIfnzpoDMEuESMdMXpbJEQRaH3Z RwFdQZFQv8x0Dz5jYJwWEr0AaADsVXLo6I9kPLvnQLw/NGjzSxplxEeGIuXgj4ZZuqjD 7uRbnpxK/aN+15V32VgSxVyDWld01HjIUFPUOdx5q7p5fVRE32mnHBR7akOSTIaxj0ik 5qBg==
X-Received: by with SMTP id ma2mr4428236wic.52.1381517859104; Fri, 11 Oct 2013 11:57:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 11 Oct 2013 11:57:09 -0700 (PDT)
In-Reply-To: <>
References: <> <em19baa0e5-7a97-44ab-874e-b084b9645052@sydney> <> <>
From: Will Norris <>
Date: Fri, 11 Oct 2013 11:57:09 -0700
X-Google-Sender-Auth: XTEFeqWdWGf0dWiGq39NxpqzDRQ
Message-ID: <>
To: "Paul E. Jones" <>
Content-Type: multipart/alternative; boundary="001a11c38dfc3e33e704e87bb1ea"
Cc: webfinger <>, Melvin Carvalho <>
Subject: Re: [webfinger] Registration of a URN for WebFinger Properties
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: Fri, 11 Oct 2013 18:58:13 -0000

On Fri, Oct 11, 2013 at 10:07 AM, Paul E. Jones <>wrote:

>  Melvin,
> See comments below:
> On 10/11/2013 11:01 AM, Melvin Carvalho wrote:
>  I agree, though none of these are designed for use in WebFinger.  So, I
>> created my own.  You can't point to something 5 years old and declare I'm
>> reproducing it because there is some syntax scribbling that has the word
>> "name" associated with it.
>> What I defined in the link above for "name", for example, is somewhere
>> between foaf:name and the one related to vcard.  WebFinger has a registry
>> for identifiers now.  It would be good to see that get populated with
>> useful items, though I would not recommend putting everything one might
>> possibly put into a vcard in there.  If a vcard is essential, the vcard
>> link relation should be published in a WF JRD and a client query that.
>> However, there are basic things like "name" that are very useful, such as
>> when you log into a web site and that site would like to display
>> your avatar and name.  The avatar already has a defined LR value under
>>  The person's name does not have a defined property
>> identifier anywhere, except the one I specified under
>  Ah I see what you've done, you've added some internationalization, ie
> one URI for each language?  Apart from that are there any differences to
> FOAF (by the way FOAF already has standards for internationalization)
>  Wouldnt this lead to potentially dozens of new URIs, per term, for
> example, for a different one for every language supported?
> FOAF does not define a set of URI.  Rather, it's XML-based markup.
> WebFinger uses URIs as identifiers.  I don't really care where those
> identifiers are defined, but at present there is no standard property
> identifer in URI form that means "name".
> ?  Of course that doesn't have the language
fragment, though as you point out below, there's an argument it may not be
needed anyway.  /shrug

> Using the URI fragment to indicate the language does introduce a number of
> distinct URIs, but having the language tag would need to be *somewhere*if we want to allow the language to be specified as part of the property.
> Unlike XML, we do not have additional attributes we can apply.  Arguably,
> we do not need to specify the language and we allow a user to advertise
> just a single name.  However, I've found it beneficial to allow people to
> advertise names in at least two different character sets.  I can't read
> Chinese, Japanese, or Korean, for example, so allowing a western alphabet
> is helpful to be used in parallel with the native alphabet is nice.
> Paul