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

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

Evan,

 

Please see my comments inline in green:

 

 

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Evan Prodromou
Sent: Saturday, October 20, 2012 11:37 AM
To: [e-mail]
Subject: Re: [apps-discuss] WebFinger Draft Updated -
draft-ietf-appsawg-webfinger-01

 

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.

PEJ: You're correct that it is a bit lengthy and you're right that the
length does not represent the complexity.  It is a simply protocol.  Much of
the length comes from examples and a desire to make each step unambiguous.
If there is material we should remove, we can do that, but I don't want to
reduce the length only for the sake of length and risk introducing
ambiguity.

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

PEJ: We could do that, but it only occupies a bit of space and helps explain
the history of the name.

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

PEJ: I agree that "thus" should go.  I've removed it from my copy.  But, I
do think the previous paragraphs are useful.

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

PEJ: Section 4 is only examples.  There is nothing to make obsolete.  I
think it's always good to provide examples, as this helps people understand
better than just the normative wording.  I would really prefer to keep all
examples.

*	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 

PEJ: A server is not required to run using HTTPS, but I do think we should
require consistent behavior.  So, I picked "try HTTPS first and fall back to
HTTP".  We could change the wording to say that clients SHOULD try "HTTPS"
first, but I would prefer consistency in implementations.  What would be a
reason for not doing that?  What do others think on this one?

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

PEJ: While I do agree that both objectives are reached, I will remove "as a
means of improving performance and reducing client complexity" as you
suggest because we do not need to give justification.  It's just required.
:-)

*	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?

PEJ: On my server, I don't make an HTTP query.  I just pull the data from
the database and return it.  I fully agree that how the server returns the
information is an implementation matter.  That said, we do not want a server
returning an LRDD link relation that forces the client to resolve it.  How
about this modified paragraph:

"It is not the responsibility of the WebFinger server to verify, for
example, that a URI pointing to a person's avatar is a valid URI.  If the
WebFinger server needs to query an LRDD resource to collect additional
resource-specific information, any errors (e.g., 500 or 404) MUST be ignored
by the server.  When a request for an LRDD fails, the server MUST NOT
attempt to augment missing resource information or return a "template" type
link relation to a client that utilizes the "resource" parameter.  Note that
a WebFinger server might be implemented such that all LRDD resource-specific
information can be resolved without issuing HTTP requests.  How a WebFinger
collects and expands such resource-specific link relations is an
implementation matter."

*	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?

PEJ: It was the fact that HTML uses a space-separated list that I specified
it this way.  I like consistency.  Is there a technical reason for not
trying to have a consistent syntax with HTML's <Link> syntax?

*	Section 5.4 should probably also call out the "tag" URI scheme.

PEJ: My only concern is that it is an informational RFC, is it not?  I'd
prefer to avoid having normative text referring to informational material.

*	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?

PEJ: Trying to discuss how WebFinger might be used in relation to any other
discovery protocol will start getting messy and we will never get consensus
:-)

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

PEJ: The name should not be confusing, since the "acct" link relation is
intended to be used only with the "acct" URI. However, since we moved out
the "acct" URI, we could also move out the "acct" link relation text to a
different Internet Draft.  Do others have a preference? Any volunteers to
take that action?

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

PEJ: You're entirely right about that and that text bugged me, too.  There
was a strong desire for CORS to the point I was asked to make it a MUST, yet
there was the desire to allow an enterprise do something more restrictive.
I have no strong preference, myself, but I do think that if we make it a
SHOULD, though, that it will make it impossible to build a client in a
browser.  What does the group want here?

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

PEJ: This one is hard.  We might debate a year on what a baseline document
should contain :-)  Is a server name?  Is it a copyright date?  I think an
empty document should be OK. :-)  We'll know if WF is working simply based
on a valid response. I'd prefer to not make requirements on baseline
documents. 

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

PEJ: This is all new text because there were folks who said we need to have
a means of allowing the WF services to be hosted.  We talked about using 3xx
and we talked about introducing a URI DNS record.  The latter is a cool
idea, but the spec is not finalized.  It also introduces one more code path
in the client.  The 3xx must already be handled.  We could make this section
non-normative if folks prefer, but I think having this content will help
people understand how they can re-locate and outsource WF services.

*	Section A seems unnecessary, since it's already covered in RFC 6415.
Am I missing something?

PEJ: That's part of why it is in an appendix.  I wanted to have this here
since it provides an XRD example of the exact same example in Section 4.1.
I thought this might be useful for people.  Even if they do not implement
XRD in a client or server, it helps to illustrate in this document what an
RFC 6415-compliant server would do.  I could remove it, but I think it's
educational and it's already marked as non-normative.

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.

 

PEJ: I do hope we're getting closer.  I'm challenged to see how we can make
it much shorter and also keep it in a form that makes it perfectly clear to
implemeners.  (Of course, somebody will still misinterpret something, but I
do aim to avoid misinterpretation.)  Consider my comments above.  I've made
a few changes and I could try to get a -02 published before the deadline
Monday.

 

PEJ: Thanks for the thorough review!

 

Paul



-Evan