Re: [apps-discuss] Webfinger

["Martin J. Dürst" <[e-mail]>]

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:[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.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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>
>
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss