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

[Melvin Carvalho <[e-mail]>]

On 20 October 2012 17:37, Evan Prodromou <[e-mail]> wrote:

>  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?
>
>
HTTP GET is generally recommended to get more information from an HTTP
URI.  HEAD may not contain the information you need.  Of course, it may
become popular to deference an HTTP URI using webfinger.  Though there may
be issues with the correct response codes, consistency of information etc.


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