Re: [apps-discuss] Webfinger

"Mykyta Yevstifeyev (М. Євстіфеєв)" <> Sat, 12 November 2011 05:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72B0721F8497 for <>; Fri, 11 Nov 2011 21:31:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.338
X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4MyyBdSlgJeG for <>; Fri, 11 Nov 2011 21:31:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4611421F8496 for <>; Fri, 11 Nov 2011 21:31:06 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so4799072bkb.31 for <>; Fri, 11 Nov 2011 21:31:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Eb1Xj2XMeZIF7J4d99MFRN8f5Bwa1Jj7vN2JV9cNgBQ=; b=A6rXXAytbmTRLPYkifN7VTZPHaTR84Ua1pp+Wayty7lVwPGO+V8EbAlUCdBU/OAwVJ sFeg74z1Q8rMxq10U4yuFbHqMV5wSaLb4QIH9sm2sn72Di6yOU46BLAR4ETodLaqu/3K fPcn28dBAvKJbV+/i8H19pN+ZcQhhWdQECDEs=
Received: by with SMTP id u23mr3196106bkv.105.1321075865168; Fri, 11 Nov 2011 21:31:05 -0800 (PST)
Received: from [] ([]) by with ESMTPS id a4sm5614591bkq.13.2011. (version=SSLv3 cipher=OTHER); Fri, 11 Nov 2011 21:31:02 -0800 (PST)
Message-ID: <>
Date: Sat, 12 Nov 2011 07:31:51 +0200
From: "\"Mykyta Yevstifeyev (М. Євстіфеєв )\"" <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul E. Jones" <>
References: <032101cc9288$e3a06910$aae13b30$> <> <023801cca0ca$d9860a20$8c921e60$>
In-Reply-To: <023801cca0ca$d9860a20$8c921e60$>
Content-Type: multipart/alternative; boundary="------------050706020201070302070605"
Subject: Re: [apps-discuss] Webfinger
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 12 Nov 2011 05:31:08 -0000

Hello Paul,

12.11.2011 1:37, Paul E. Jones wrote:
> Mykyta,
> Thanks for your positive response.
> To your specific questions…
> We would definitely want to ensure that Unicode is properly 
> supported.  In wasn’t aware of RFC 5335, so I’m glad you brought that 
> to my attention.  Do you have a pointer to the bis draft so I can see 
> exactly what is there?  I’d be fully in favor of using utf8-addr-spec.

This is  But 
please note that this document, unlike RFC 5335, introduced UTF-8 
additions to *base* RFC 5322 productions.  This means that <addr-spec> 
will be defined as follows now:

>     addr-spec       =   local-part "@" domain
>     local-part      =   dot-atom / quoted-string / obs-local-part
>     domain          =   dot-atom / domain-literal / obs-domain
>     domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
>     dtext           =   %d33-90 /          ; Printable US-ASCII
>                         %d94-126 /         ;  characters not including
>                         obs-dtext          ;  "[", "]", or "\"
>     dtext           =/  UTF8-non-ascii     ; from 5335bis
>     dot-atom        =   [CFWS] dot-atom-text [CFWS]
>     dot-atom-text   =   1*atext *("." 1*atext)
>     atext           =/  UTF8-non-ascii     ; from 5335bis

So everything you will have to do is to have a note on 'acct' RI being 
possible to carry UTF8 characters and therefore being possibly IRIs.

> Link relation types might be names like “copyright” or they might be 
> URIs.  The definition of the link relation types is outside the scope 
> of the Webfinger document itself.  RFC 6415 defines the structure of 
> the documents and provides examples of some link relations and the 
> order of processing.  RFC 5988 defines the link relations more 
> generically and establishes the registry for them.  Do you think we 
> need to say more about link relations beyond what those documents cover?

I mean that Webfinger will have to operate on a variety of link 
relations in LRDD documents, and nobody will benefit from link relation 
types defined by URIs used there, as this eliminates the possibility for 
automatic processing.  So I ask whether we'll have to define non-URI 
link relation types for all the possible Webfinger use-cases?

> On section 4: noted.  We’ll try to clearly separate the normative and 
> non-normative pieces better.


> On  CORS, there are some who have strongly advocated for it.  It would 
> be very useful to allow JavaScript code to perform these queries.  
> Otherwise, the queries would have to be pushed to server-side code.  
> Let’s wait on deciding what to do until we get a definitive answer on 
> CORS from the W3C.  I think Peter was going to do some investigating 
> there.
> Putting Webfinger into vcard: isn’t that circular?  The idea with 
> Webfinger is that you have the identity of the user (e.g., 
> <>), but you want to 
> find more information.  If you have a vcard, then you have the user’s 
> identity (via the email tag).  Or are you suggesting that we formally 
> introduce the acct URI in vcard?  That might make sense to do.  Can 
> you clarify your proposal?

 From RFC 6350, Section 6.4.2:

> 6.4.2. EMAIL
>    Purpose:  To specify the electronic mail address for communication
>       with the object the vCard represents.

...and the use might have email address different from Webfinger ID.  
I've already pointed to, which 
VCARDDAV WG works on, and so you may try to introduce some similar 
property for Webfinger IDs.  (You see, vCards may not carry all the 
variety of information, though some people actually think in other way, 
and thus it would be a good idea to provide a means of accessing some 
additional info.)

> For comments on particular sections, I’ve added notes to each one to 
> revise them as you suggest: they’re all good suggestions.

Yes, thanks as well.

> I would very much like to make this a WG item, of course, but none of 
> the authors will be present at this IETF meeting.  Perhaps hallway 
> dialog might take place, but not sure.  In any case, we can do this 
> via the mailing list, too.

See Barry's note on this.

> Thanks!
> Paul

All the best,
Mykyta Yevstifeyev

> *From:* 
> [] *On Behalf Of *"Mykyta 
> Yevstifeyev (?. ?????????)"
> *Sent:* Friday, November 11, 2011 12:59 PM
> *To:*
> *Subject:* Re: [apps-discuss] Webfinger
> Hi Paul and all,
> I think you contributed a very interesting proposal indeed.  Really, 
> RFC 1288 finger protocol is now outdated, and you're right claiming 
> that it provides no means of automatic processing.  BTW, RFC 1288 is 
> currently at Draft Standard maturity level, which has been abandoned 
> by RFC 6410, and we should therefore undertake something with this 
> respect, as should we with respect of other Apps-related DSs, but that 
> is what is to be discussed separately.
> With respect to proposed 'acct' URI scheme:  how are you going to 
> handle internationalization (i18n)?  We have RFC 5335 defining 
> <utf8-addr-spec> (Experimental RFC) and IESG has already approved EAI 
> 5335bis, that will be Standards Track.  So will <utf8-addr-spec> be 
> allowed in 'acct' URIs in some way?
> Webfinger implies use of some link relations.  Is it anticipated that 
> URIs will be used as link relations types, or we'll need to define 
> link relation types for all possible use-cases of Webfinger?
> Your Section 4 seems to be somewhat narrative.  I propose to divide it 
> into normative specification and examples.
> With regard to CORS - I'm not actually acquainted with this 
> technology, but I see it is currently documented as W3C working draft, 
> so I don't suspect it is now widely-used (I may of course be wrong, so 
> please feel free to correct me), and I think there is no use putting 
> MUST requirement on its use in Webfinger.  You could better remove 
> your section on CORS from the document at all.
> I think we should also provide some means of mentioning Webfinger 
> accounts in vCards.  You could please see VCARDDAV document 
> which Webfinger elements may also be incorporated.
> In Abstract, you should be more specific about what your document 
> defines.  I propose mentioning directly that the document is the 
> specification of Webfinger protocol, not "procedures for dicovering 
> information about people".
> In Section 7 you should clearly state that Webfinger (so as finger 
> itself) is intentionally left w/o any means of controlling access to 
> information (unless we want to produce *such* protocol).
> I see the document is on APPSAWG agenda on the meeting, so I 
> anticipate it will soon become APPSAWG item doc.  I won't be on 
> meeting, but if you discuss the adaptation of Webfinger draft please 
> also take into account I'm in favor of such adaptation (consider this 
> as my 2p).
> Mykyta Yevstifeyev
> 24.10.2011 23:09, Paul E. Jones wrote:
> Folks,
> We just submitted this:
> The tools for Webfinger are now defined, but the procedures need to be 
> clearer with respect to what most of us understand as “webfinger”.  
> This is just a first stab at making that happen and we hope to 
> progress this to publish an RFC in the application area.
> We welcome any comments you have on the topic, either privately or 
> publicly.
> Paul
> _______________________________________________
> apps-discuss mailing list
>  <>