Re: [apps-discuss] Webfinger

"Paul E. Jones" <paulej@packetizer.com> Fri, 11 November 2011 23:37 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECFB11E8098 for <apps-discuss@ietfa.amsl.com>; Fri, 11 Nov 2011 15:37:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level:
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 FNpmyHCOAVpt for <apps-discuss@ietfa.amsl.com>; Fri, 11 Nov 2011 15:37:24 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D365811E8088 for <apps-discuss@ietf.org>; Fri, 11 Nov 2011 15:37:23 -0800 (PST)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pABNbJ1O028104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Nov 2011 18:37:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321054641; bh=/8Xmz/sVueGsdGQoswZ00nZZ0VN9ByE1Dd6E/pDnvBI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=R6MwXKVGU2bqiDnuQ0OU1lGTwo7DtFXBHGqCEE9EX9sN+xKJbV8Ub1jwx+7XKKUi2 6MPuFEZ3+XbiT2S9JKwlva47fJHVBMlzzKuPjn0zuZv8SxxZUeDdjPEIcevWsn4n6f 40nNB8+Y2vkkB0ahXMaGKJJzrMHls2jYyoPZ6cno=
From: "Paul E. Jones" <paulej@packetizer.com>
To: =?UTF-8?B?JyJNeWt5dGEgWWV2c3RpZmV5ZXYgKNCcLiDQhNCy0YHRgtGW0YTQtQ==?= =?UTF-8?B?0ZTQsikiJw==?= <evnikita2@gmail.com>, <apps-discuss@ietf.org>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <4EBD6266.6030307@gmail.com>
In-Reply-To: <4EBD6266.6030307@gmail.com>
Date: Fri, 11 Nov 2011 18:37:15 -0500
Message-ID: <023801cca0ca$d9860a20$8c921e60$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0239_01CCA0A0.F0B1FDF0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQFe+7+KlLcGQ7A=
Content-Language: en-us
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Nov 2011 23:37:25 -0000

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.

 

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?

 

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., paulej@packetizer.com), 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?

 

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

 

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.

 

Thanks!

Paul

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of "Mykyta Yevstifeyev (?. ?????????)"
Sent: Friday, November 11, 2011 12:59 PM
To: apps-discuss@ietf.org
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 http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 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:

http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

 

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
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss