Fwd: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-01

[Melvin Carvalho]

FYI: Some proposed changes to webfinger, including, among other things, CORS ...

---------- Forwarded message ----------
From: Evan Prodromou <ev...@status.net>
Date: 20 October 2012 17:37
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-01
To: apps-d...@ietf.org

Paul,

Thanks for the update! I really like what I see; take the following notes as suggestions and not absolute rules.

• It's long. With RFC 6415 as a basis, the requirements of this specification are actually quite small (add CORS, resource, and rel; JRD required, XRD optional). It would be nice if the document length and complexity reflected that.
• The introduction in section 1 would be better if it ignored "finger" entirely. Just say what Webfinger does: lets a host define links and properties for an URI.
  
• The first three paragraphs of section 3 are unnecessary and confusing. This is what references are for. Starting at "Thus the framework..." (without the "thus") is a lot clearer.
  
• Section 4 is unnecessary and confusing. Also, as applications are built using Webfinger, it will probably become obsolete and incorrect. I think it should be struck entirely out.
• Section 5.1 makes the order of queries (HTTPS, HTTP) a MUST on behalf of clients. The client should determine the level of authenticity they need from the server. I suggest a SHOULD here, with similar language as RFC 6415 for
  
• Section 5.2 says that servers MUST support "resource" "as a means of improving performance and reducing client complexity". I think the performance improvement is debatable, and maybe even the reduction in client complexity. So, maybe just strike this language? By which I mean: leave the requirement, but don't try to justify it.
  
• Section 5.2 suggests that the server should literally make an HTTP request to fetch the LRDD link. That is the hard way to do it. Can we just assume that the server can figure out its own implementation details?
• Section 5.2 recommends using host-meta.json, which I think is excellent.
• Section 5.3 uses space-separated "rel" parameters. There is some precedent for using space separation for a single rel in HTML ("alternate feed"), which makes this a little tricky. How about comma (",") instead?
  
• Section 5.4 should probably also call out the "tag" URI scheme.
• Section 5.4 should make special mention of "http" and "https" URIs. There are other discovery methods that can be used with this kind of URI; is there a recommended order for using Webfinger versus, say, doing a HEAD request and looking at the Link: headers? Doing a GET request with Accept set to "text/html" and parsing for <meta> and <link> elements?
• I'm not convinced we need "acct" rels (section 6). At the very least, the name is confusing w/r/t the acct: URI scheme.
  
• Section 7 makes support for CORS a MUST and then turns around and said if you have a good reason not to support it, you SHOULD NOT. I suggest that support for CORS should just be a SHOULD. I can figure out myself whether I want to be the exception.
  
• Section 8 should recommend a base representation for host and resource descriptors be available with no authentication, and enhanced representations available with authentication. Host meta is the initial introduction for clients and servers that don't otherwise know each other; there should always be some information available - even if it's just the information on how to authenticate to get more information.
  
• Section 9 is implementation detail that should probably be out of scope. I realize that these configurations are why we support 3xx redirects, but maybe figuring out the topology of those redirects is best left as an exercise for implementers.
• Section A seems unnecessary, since it's already covered in RFC 6415. Am I missing something?
  

Overall I think the protocol itself is great, with some minor tweaks between MUSTs and SHOULDs. Shortening the document will make it clearer and easier to implement.

-Evan

_______________________________________________
apps-discuss mailing list
apps-d...@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

[Melvin Carvalho]

On 21 October 2012 00:47, Melvin Carvalho <melvinc...@gmail.com> wrote:

FYI: Some proposed changes to webfinger, including, among other things, CORS ...

Update on this:

So far 3 people (including Blaine Cook) have expressed support for CORS as a MUST requirement.