Re: [apps-discuss] Webfinger

"Paul E. Jones" <paulej@packetizer.com> Mon, 14 November 2011 14:07 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 93B4711E81D3 for <apps-discuss@ietfa.amsl.com>; Mon, 14 Nov 2011 06:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level:
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, 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 wFpumVo++YOr for <apps-discuss@ietfa.amsl.com>; Mon, 14 Nov 2011 06:07:46 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEAF11E819E for <apps-discuss@ietf.org>; Mon, 14 Nov 2011 06:07:46 -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 pAEE7hSm004182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Nov 2011 09:07:45 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321279665; bh=/Ytk+L4vufYqZr2GpK0Xom0BFN/R5bKqqiwJZ5c/i9E=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Xo6FUp/n02NAq7/frv8dho4XIlUy31c6pPUKLVCPYxbR8ZBeioEbfHDGhMvm417+y +5p+5f37xkNB0wDgOIM9dFEOo646dZkf9OQ+NklWMU7TLNfFF3bdTmTiCl1X/q5Vd9 pO6dIl2pLye7A+l11dXoCRXnEXEt+Lad4D5pbMZs=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "=?UTF-8?Q?'=22Martin_J._D=C3=BCrst=22'?=" <duerst@it.aoyama.ac.jp>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <4EBD6266.6030307@gmail.com> <023801cca0ca$d9860a20$8c921e60$@packetizer.com> <4EBE04C7.5090400@gmail.com> <015301cca232$75ea36d0$61bea470$@packetizer.com> <4EC0BFAD.8060501@it.aoyama.ac.jp>
In-Reply-To: <4EC0BFAD.8060501@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 09:07:35 -0500
Message-ID: <02eb01cca2d6$c36a81e0$4a3f85a0$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQFe+7+KAmEa8QsCfngenQIEt9zYAdF9rjiUdYda4A==
Content-Language: en-us
Cc: apps-discuss@ietf.org
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: Mon, 14 Nov 2011 14:07:47 -0000

Martin,

That's actually where I started, but decided to narrow the definition to addr-spec only, since we do not want a lot of the other syntax associated with "mailto".  However, feedback I got was that addr-spec might even be too broad.  Do we need anything more than acct:user@domain?  If not, I think RFC 3986 might define enough.  Would we lose anything?

Paul

> -----Original Message-----
> From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp]
> Sent: Monday, November 14, 2011 2:14 AM
> To: Paul E. Jones
> Cc: "'\"Mykyta Yevstifeyev (М. Євстіфеєв)\"'"; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Webfinger
> 
> Hello Paul,
> 
> You can also have a look at RFC http://tools.ietf.org/html/rfc6068 and
> http://tools.ietf.org/html/draft-duerst-eai-mailto-01.
> 
> If I understand the acct: scheme correctly, it should be possible to
> make the syntax a subset of mailto:.
> 
> Regards,    Martin.
> 
> On 2011/11/14 3:31, Paul E. Jones wrote:
> > Mykyta,
> >
> >
> >
> > I fear this might get complicated with references to the email
> documents.  Those documents are trying to solve a real problem, but
> Webfinger does not have some of those historical constraints.
> >
> >
> >
> > Here’s my proposal: let’s not reference 5335 or 5322.  Rather, let’s
> only reference the generic URI syntax spec (RFC 3986).  Let’s define the
> URI scheme using the syntax found there:
> >
> >     acctURI   = "acct:" userinfo "@" host
> >
> >
> >
> > The productions “userinfo” and “host” are already defined.  Perhaps
> the one thing I don’t like is that “host” might be an IP address, but
> perhaps some people prefer that.
> >
> >
> >
> > RFC 3986 already says that these components are UTF-8 encoded and then
> percent-escaped when a character is outside the ASCII character set
> range.
> >
> >
> >
> > Would this be a suitable replacement for the current text?
> >
> >
> >
> > With respect to your comments on link relations and URIs, I still do
> not understand.  You say that “nobody will benefit from link relation
> types defined by URIs”, but why not?  There are several already define
> and used today.  In any case, I would prefer that all link relation
> values (URI or simple strings) be defined outside of the Webfinger
> draft.  As I mentioned, there is already a registry, so one can be
> proposed any time.
> >
> >
> >
> > Paul
> >
> >
> >
> > From: "Mykyta Yevstifeyev (М. Євстіфеєв)" [mailto:evnikita2@gmail.com]
> > Sent: Saturday, November 12, 2011 12:32 AM
> > To: Paul E. Jones
> > Cc: apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] Webfinger
> >
> >
> >
> > 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 http://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-13.  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.
> >
> >
> > Thanks.
> >
> >
> >
> >
> >
> >
> > 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?
> >
> >
> >> 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
> > http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00,
> > 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: 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.t
> > xt
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss