Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11

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

Dave,

On 3/22/2013 5:32 AM, Dave Cridland wrote:
> >
> > So, you are OK with the restriction?
> >
>
> Restricting it to a single link relation type (as defined by RFC 5988, 
> and the <relation-type> ABNF production therein) is perfectly fine.

OK

>
> >
> > > However, if you're changing the definition of link relation types, 
> then:
> > >
> > > a) I'm deeply concerned. Redefining a standards-track specification
> > > seems worryingly close to NIH. There's horrible confusion lurking when
> > > someone says "Link relation type" and then has to qualify which
> > > definition.
> > >
> > > b) You need to make this absolutely clear in the document; it 
> reads like
> > > you're restating, not redefining.
> > >
> > > c) The only distinction you claim above that appears to me to be an
> > > actual distinction is that fragments are disallowed. Yet no such
> > > restriction exists in the current draft.
> >
> > I'm still missing something.  How are we changing the definition of 
> a link
> > relation type, aside from restricting rel to having a single value 
> that is
> > either an absolute URI or a single link relation type?
> >
>
> So, you said, broken apart for readability:
>
> >>> RFC 5988 allows for multiple values like 'rel="shortcut icon"', 
> but WebFinger does not.
>
> I see that RFC 5988 allows its 'rel' parameter to hold multiple Link 
> Relation Types, yes. I agree that restricting this is reasonable. (I 
> have no view on whether it's sensible). However, that's referring to 
> the RFC 5988 "rel" parameter (or attribute), and absolutely not the 
> definition of Link Relation Type, which is always a single registered 
> token or an absolute URI (which itself SHOULD be lowercased).

RFC 5988 says that "extension relation types are REQUIRED to be absolute 
URIs in Link headers".  However, we cannot simply assume that "Link 
Headers" also means "Link Relation Objects" in WebFinger.

That's why we make it clear:

'The value of the "rel" member is a string that is either an absolute 
URI or a registered relation type [10] (see RFC 5988 [4]).'

So, I don't see an issue with that sentence.  The rest of the first 
paragraph in the WF spec (up to the point where I'm proposing the 
paragraph break) would then read:

"The value of the "rel" member MUST contain exactly one URI or 
registered relation type.  The URI or registered relation type 
identifies the type of the link relation."

Any concern with this part?

> >>> RFC 5988 also allows URIs with fragments, but WebFinger does not.
>
> Your current draft makes no restriction on whether a Link Relation 
> Type may have a fragment or not. It stipulates an absolute URI, which 
> in RFC 3986 may have a fragment; therefore this restriction is not in 
> the draft as written. Neither is it in RFC 5988; however if you do 
> intend adding this restriction then this represents a deviation.

The WF spec says link relation types MUST be either absolute URIs or 
registered a registered relation type.  Per RFC 3986, absolute URIs do 
not have fragments (See Section 4.3).  RFC 5988 also requires use of 
absolute URIs when used in Link Headers.  Perhaps the intent was to 
always require absolute URIs?  I don't know, since the text limits the 
statement to "Link Headers".  WebFinger wants the same restriction, so 
we inserted an explicit statement.

> >>> Valid URIs must conform to Section 4.3 of RFC 3986 (Absolute URIs).
>
> I'm not sure if you considered this a difference or not; as far as I 
> can tell RFC 5988 only allows absolute URIs (of the extended relation 
> types), though it explicitly calls out this requirement for the Link 
> header itself. Either way this seems reasonable, and not a deviation.

It does, but the document is scoped for HTTP headers.  We need an 
explicit statement for WEbFinger, since it's not HTTP headers and RFC 
5988 limits the absolute URI wording to Link headers.

>
> >
> > We had no intention of changing the definition of a link relation type,
> > though we do have the stated restrictions in 4.4.4.1 
> <http://4.4.4.1>: "rel" is exactly one
> > of either an absolute URI or a registered relation type.
> >
>
> Right, which is a Link Relation Type as defined in RFC 5988.
>
> Either you have changed the definition (or at least, rel doesn't hold 
> a link relation type), in which case my opinion remains that this is a 
> bad thing, but in any case needs to be made abundantly clear in the 
> document...
>
> ... or you haven't, in which case I don't understand why you won't 
> simply reference RFC 5988 instead of referencing it piecemeal.

We tried referencing RFC 5988 as much as we could.  But, since that text 
speaks explicitly of HTTP Link Headers and places restrictions only 
there in the text, while the ABNF is more relaxes, we felt it was 
necessary to state more-or-less the same "absolute URI" requirement in 
WebFinger.

I don't see this as a re-definition.  I do think it's valuable, as it 
makes it clear.

So, we have these two paragraphs now in that section:

The value of the "rel" member is a string that is either an absolute URI 
or a registered relation type [10] (see RFC 5988 [4]).  The value of the 
"rel" member MUST contain exactly one URI or registered relation type.  
The URI or registered relation type identifies the type of the link 
relation.

The other members of the object have meaning only once the type of link 
relation is understood.  In some instances, the link relation will have 
associated semantics enabling the client to query for other resources on 
the Internet.  In other instances, the link relation will have 
associated semantics enabling the client to utilize the other members of 
the link relation object without fetching additional external resources.

The first paragraph has to do with the "rel" values, leaning on RFC 
5988, but being explicit in applying the same "absolute URI" 
requirement.  It does add the restriction of not allowing more than one 
value inside "rel" (whereas RFC 5988 allow for an unlimited number).  
The second paragraph as WF-specific, talking about the other members of 
the "link relation object", which is something specific to WF.

> >
> > > I have no clue what the possible impacts of using webfinger on a 
> message
> > > id URI might be, nor do I wish to even think about it.
> >
> > Likely a 404.
> >
>
> I don't think whether it works is the sole consideration.
>

Agreed.

> >
> > > I'm pretty sure that mailto has some corner cases we've not yet 
> thought
> > > about; it's not just an email address after all.
> >
> > On my server, that returns a JRD in the form of the example you do 
> not like
> > so much. :-)
> >
>
> I said corner cases. Please read RFC 6068; you appear to be labouring 
> under the assumption that a mailto URI is identical to an acct URI 
> except for the scheme.
>

I make no assumption.  With WF, a URI of any form is just a "resource" 
identifier.  Given that identifier, one gets back a JRD.

> >
> > It would be entirely reasonable to also return the same JRD as the acct:
> > URI.  We struggled several years with whether to use mailto or acct. 
>  Given
> > that some services do not have email (notably, Twitter), there were 
> a push
> > for acct.  That's fairly well adopted at this point, but I would not 
> dismiss
> > the use of mailto if that is the identifier one has in hand.
> >
>
> I don't think mailto is nearly as simple as you seem to think it is. I 
> don't know enough about other URI schemes to know whether other 
> schemes have the same problem.

I'm quite familiar with mailto URIs and recognize that they're complex, 
or can be.

>
> My issue here is not a matter of the good things that might reasonably 
> happen from careful use of simple URIs with arbitrary schemes; my 
> concern is that there may be bad things with odd cases and there's no 
> evidence that these have been thought through.

Nothing "bad" can happen.  Either a WF query returns useful information 
or it does not.  Use of any particular URI scheme will come about either 
through common usage or through standardization efforts.

>
> So for mailto, for example, I'd think you want to restrict the URI 
> form used to being, using RFC 6068's ABNF, '"mailto:" to', and avoid 
> any other forms. What I don't know - and given the way URIs can have 
> entertaining corner cases like this, what worries me - is not only 
> whether the whole thing works if you have an odd URI construct (mailto 
> or no), but whether it's safe.
>
> I think as you look deeply into various URI schemes, there'll be cans 
> of worms in a number of places, and the safer thing to do is to 
> restrict the schemes and URI forms that are - currently - allowed. 
> Look on the bright side, you'll have the fun of specifying what a 
> telnet URI should give you back from WF.

URI schemes can have many forms, have parameters, etc.  They range from 
simple to complex.  However, a WF server that accepts any given URI 
scheme will understand that URI scheme and will return useful 
information.  If it does not understand the scheme (or does not have 
information for the particular URI), it will return a 404.

I strongly believe we should allow use of any URI scheme.  Any 
complexities that arise will either be addressed through common usage or 
as part of a standardization effort.

>
> At the very least, I'd suggest that you add a security consideration

What should we add?  I'm not seeing any new or different security issues 
arising from use of any particular URI scheme.  Every URI returns either 
a JRD or it does not.  What would be different with mailto, http, sip, 
tel, gopher, or any other scheme?

Paul