Subject: [apps-discuss] WGLC feedback on webfinger-09

From: Mark Nottingham <[email-masked]>
Date: Tue, 5 Feb 2013 17:58:02 +1100

Had a quick read of this draft. Overall this looks pretty good; the points I raise are fairly minor.

1) The introduction seems to be missing a vital bit of information: that the Whole Point -- the Big Trick -- that WebFinger performs is (AIUI) that you can use an identifier that might not be usable as a locator (e.g., a mailto: uri, an acct: uri) as a locator. In that sense, it's really just a more real-world-usable URN lookup facility*.

This is really important to include in the abstract as well as the introduction, because without it, WF just seems like a silly indirection mechanism on top of HTTP.

2) The examples use unregistered link relations types <http://www.iana.org/assignments/link-relations/link-relations.xml>; specifically, "blog" and "vcard". Naughty.

3) The text in section 4.1 isn't precise enough; consider the "=" and "&" characters, which are NOT required to be percent-encoded by RFC3986 section 2.1. Also, the things that section is defining are not "URI parameters" (which is things after a semicolon in a path segment); it's a query string format. Really, what you want to do is either: a) reference or re-define <http://www.w3.org/html/wg/drafts/html/master/forms.html#application/x-www-form-urlencoded-encoding-algorithm>, or b) define a subset of it that's simple yet precise.

4) Section 4.2 would be a lot clearer if you just said that the well-known location is ONLY defined for the HTTPS URI scheme.

5) Why not define a media type for JRD? You can instruct clients to also accept application/json if you're worried about bad server configurations.

6) What's the motivation for expires, given that HTTP caching information is already available? Have you considered the interaction between them?

7) Section 4.4.5 "user's preferred link relation." --> "user's preferred link relation type." (and likely elsewhere).

8) RFC5988 defines the "target IRI" as what's at the end of the link; here, "linked resource" is used (e.g., 4.4.5.[2,3]). Suggest "target resource" as a way to tie them together conceptually.

9) Similarly, an important concept in 5988 is the "context" of the link; suggest saying that the context of all of these links is the subject(s).

10) What if a target resource supports multiple media types for the same relation? Suggest allowing multiple values in "type."

11) 4.5 says "WebFinger requests can include a parameter specifying..." What kind of parameter? Tie it back to what happens in 4.1.

12) 4.5 says "WebFinger is agnostic regarding the scheme of such a URI..."   I think you mean "neutral", unless the protocol really believes that the scheme is unknowable.

Lucky 13) "For resources associated with a user account at a host..." --> "To perform a webfinger lookup on an account specific to the host being queried..."

14) In section 7 (and likely elsewhere), you should use the full URL, not just the path /.well-known/webfinger, to make it clear that this is just over HTTPS.

Cheers,

* I'm not INTENTIONALLY trolling here; if it starts a fight, it's not my fault.

--
Mark Nottingham   http://www.mnot.net/

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 6 Feb 2013 01:18:11 +0100

On 5 February 2013 07:58, Mark Nottingham <[email-masked]> wrote:

> 1) The introduction seems to be missing a vital bit of information: that
> the Whole Point -- the Big Trick -- that WebFinger performs is (AIUI) that
> you can use an identifier that might not be usable as a locator (e.g., a
> mailto: uri, an acct: uri) as a locator. In that sense, it's really just
> a more real-world-usable URN lookup facility*.
>
> This is really important to include in the abstract as well as the
> introduction, because without it, WF just seems like a silly indirection
> mechanism on top of HTTP.
>

+1

>
> 2) The examples use unregistered link relations types <
> http://www.iana.org/assignments/link-relations/link-relations.xml>;
> specifically, "blog" and "vcard". Naughty.
>
> 3) The text in section 4.1 isn't precise enough; consider the "=" and "&"
> characters, which are NOT required to be percent-encoded by RFC3986 section
> 2.1. Also, the things that section is defining are not "URI parameters"
> (which is things after a semicolon in a path segment); it's a query string
> format. Really, what you want to do is either: a) reference or re-define <
> http://www.w3.org/html/wg/drafts/html/master/forms.html#application/x-www-form-urlencoded-encoding-algorithm>,
> or b) define a subset of it that's simple yet precise.
>
> 4) Section 4.2 would be a lot clearer if you just said that the well-known
> location is ONLY defined for the HTTPS URI scheme.
>
> 5) Why not define a media type for JRD? You can instruct clients to also
> accept application/json if you're worried about bad server configurations.
>

Why application/json?  I can understand this argument for "informational",
but for "proposed standard" I would have thought that the serialization
ought to a media type?

>
> 6) What's the motivation for expires, given that HTTP caching information
> is already available? Have you considered the interaction between them?
>
> 7) Section 4.4.5 "user's preferred link relation." --> "user's preferred
> link relation type." (and likely elsewhere).
>
> 8) RFC5988 defines the "target IRI" as what's at the end of the link;
> here, "linked resource" is used (e.g., 4.4.5.[2,3]). Suggest "target
> resource" as a way to tie them together conceptually.
>
> 9) Similarly, an important concept in 5988 is the "context" of the link;
> suggest saying that the context of all of these links is the subject(s).
>
> 10) What if a target resource supports multiple media types for the same
> relation? Suggest allowing multiple values in "type."
>
> 11) 4.5 says "WebFinger requests can include a parameter specifying..."
> What kind of parameter? Tie it back to what happens in 4.1.
>
> 12) 4.5 says "WebFinger is agnostic regarding the scheme of such a URI..."
>   I think you mean "neutral", unless the protocol really believes that the
> scheme is unknowable.
>
> Lucky 13) "For resources associated with a user account at a host..." -->
> "To perform a webfinger lookup on an account specific to the host being
> queried..."
>
> 14) In section 7 (and likely elsewhere), you should use the full URL, not
> just the path /.well-known/webfinger, to make it clear that this is just
> over HTTPS.
>
> Cheers,
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 Feb 2013 11:28:33 +1100

On 06/02/2013, at 11:18 AM, Melvin Carvalho <[email-masked]> wrote:

> Why application/json?  I can understand this argument for "informational", but for "proposed standard" I would have thought that the serialization ought to a media type?  

I think it ought to have its own media type, but I could understand if folks were concerned that strictly requiring clients to expect only it might lead to deployment problems.

Cheers,

---

From: Tim Bray <[email-masked]>
Date: Tue, 5 Feb 2013 19:20:00 -0800

One more voice in favor of a media type but, like Mark, not terribly
passionate. -T

On Tue, Feb 5, 2013 at 4:28 PM, Mark Nottingham <[email-masked]> wrote:

> > Why application/json?  I can understand this argument for
> "informational", but for "proposed standard" I would have thought that the
> serialization ought to a media type?
>
> I think it ought to have its own media type, but I could understand if
> folks were concerned that strictly requiring clients to expect only it
> might lead to deployment problems.
>
> Cheers,
>
> --

---

From: Dave Cridland <[email-masked]>
Date: Wed, 6 Feb 2013 10:33:07 +0000

On 6 Feb 2013 00:28, "Mark Nottingham" <[email-masked]> wrote:
> > 5) Why not define a media type for JRD? You can instruct clients to
also accept application/json if you're worried about bad server
configurations.

SHOULD use a media type of X, MUST accept media types of X or Y would
satisfy me.