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

[Dave Cridland <[e-mail]>]

On Fri, Mar 22, 2013 at 2:50 AM, Paul E. Jones <[e-mail]>
wrote:
>
> Dave,
>
> > > > 1) I note that §4.4.4.1 describes a 'rel' such that it redefines and
> > > > repeats RFC 5988's §4; I think this should be deferred explicitly to
> RFC
> > > > 5988 in entirety, rather than specifically only for registered link
> > > > relation types.
> > > >
> > > > The good news is that this should simplify the text rather a lot:
> > > >
> > > > """
> > > > The value of the "rel" member is a string containing a link relation
> > > > type (see RFC 5988 [4]). Both registered and extended relation types
> are
> > > > permitted.
> > > >  """
> > >
> > > I do not think we can simplify the text so much.  There is an explicit
> > > limitation in the WebFinger draft that a "rel" value must either be a
> single
> > > absolute URI or a registered link relation type.  RFC 5988 allows for
> > > multiple values like 'rel="shortcut icon"', but WebFinger does not.
 RFC
> > > 5988 also allows URIs with fragments, but WebFinger does not.  Valid
> URIs
> > > must conform to Section 4.3 of RFC 3986 (Absolute URIs).  These
> decisions
> > > were intended to avoid ambiguity.
> >
> > Link relation types are a single one of those values, the
> > <relation-type> ABNF production, as opposed to the rel, which contains a
> > <relation-types>. I'm entirely with you on why you want to restrict your
> > rel to a single link relation type. Worth calling it out the difference,
> > but it's not a deviation from RFC 5988.
>
> 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.

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

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

>
> 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: "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.

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

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

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

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.

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.

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

>
> It might also be that aggsrv uses mailto to query for a JRD that has links
> pointing to aggsrv documents.  I outlined two ways WF could be used to
make
> that happen during the BoF.  (But I did it with lightning speed due to
time
> constraints, so people might have blinked and missed it.)
>

I listened to your presentation with interest, I've not yet formed a view
on how aggsrv ought to work, and I've personally not ruled out that
WebFinger ought to play a role in it. I've no "anti WF" axe to grind here;
in fact I'd have unequivocally supported using WF if it weren't for the
lack of SRV, which leaves me undecided.

I'm just concerned that this has the potential to be sidestepping the
standardization process inadvertently.

Dave.