Re: [apps-discuss] Webfinger

["Paul E. Jones" <[e-mail]>]

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:[e-mail]]
> Sent: Monday, November 14, 2011 2:14 AM
> To: Paul E. Jones
> Cc: "'\"Mykyta Yevstifeyev (М. Євстіфеєв)\"'"; [e-mail]
> 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:[e-mail]]
> > Sent: Saturday, November 12, 2011 12:32 AM
> > To: Paul E. Jones
> > Cc: [e-mail]
> > 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.,
> [e-mail]), 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: [e-mail] [mailto:apps-discuss-
> [e-mail]] On Behalf Of "Mykyta Yevstifeyev (?. ?????????)"
> > Sent: Friday, November 11, 2011 12:59 PM
> > To: [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > apps-discuss mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/apps-discuss