Re: [apps-discuss] Webfinger

["Mykyta Yevstifeyev (М. Євстіфеєв)" <[e-mail]>]

13.11.2011 20: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
>

Again, if you re-use RFC 3986 productions, please have a look at RFC 
3987, a companion doc., defining IRIs and i18ned variants of <userinfo> 
and <host>.  I really doubt you'll manage to avoid i18n issues anyway :-)

> 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.
>

Yes, and that is also an issue.  RFC 5322/i18n addition defined a very 
suitable production for this case, I think, so please re-consider 
returning to them.

> 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.
>

Shouldn't we allow direct UTF-8?

> 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.
>

How will there be an automatic processing if URI relation types are only 
suitable for humans as they need to follow that URI to know out the 
meaning of the rel.?  Moreover, is that possible to define that variety 
of ever possible link relations for Webfinger?

Mykyta Yevstifeyev

> 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] <mailto:[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]> 
> [mailto:[e-mail]] *On Behalf Of *"Mykyta 
> Yevstifeyev (?. ?????????)"
> *Sent:* Friday, November 11, 2011 12:59 PM
> *To:* [e-mail] <mailto:[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]  <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/apps-discuss
>