RE: draft-nottingham-site-meta-03

[Eran Hammer-Lahav <eran at hueniverse.com>]

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot at mnot.net]
> Sent: Tuesday, October 13, 2009 6:24 PM
> To: Alfred HÎnes
> Cc: Eran Hammer-Lahav; apps-discuss at ietf.org
> Subject: Re: draft-nottingham-site-meta-03
> 
> Hello,
> 
> Thanks for the feedback; responses below.
> 
> On 13/10/2009, at 8:29 PM, Alfred HÎnes wrote:
> >
> > (1)  Scope / Applicability
> >
> > Despite the motivation given in the Introduction, Appendix B.3
> > clarifies that the draft does not only target the 'http' and
> > 'https' URI schemes, but Section 3 does not contain any indication
> > regarding applicability.
> >
> > The proposal thus interferes with the specification of the majority
> > of existing and in-progress URI scheme definitions, in particular
> > those URI schemes that specify "actions" (like 'mailto', 'telnet',
> > 'sip'/'sips', 'sms', 'go', etc.), are somehow transaction-oriented
> > (like 'im', 'ipp', 'dict', 'mupdate', 'snmp', 'iris.*', 'aaa'/'aaas',
> > 'msrp'/'msrps') or otherwise identify non-retrievable or even non-
> > networked resources (like 'mid', cid', 'urn', 'doi', 'info', 'tel',
> > 'fax'/'modem' [deprecated], 'tv').
> > Also, the protocols bound to many URI schemes do only allow the
> > exchange of well-specified messages and not the retrieval of
> > arbitrary media types, and as such are not amenable to the kind
> > of information you have in mind for this proposal.
> >
> > Therefore, I would greatly appreciate if the scope of the proposal
> > could be restricted and more clearly specified in the normative part
> > of the draft.
> >
> > Here's a rough first attempt to capture what might be said better
> > in the first paragraph of Section 3:
> >
> > OLD:
> >
> > |  A well-known URI is a URI [RFC3986] whose path component begins
> > with
> > |  the characters "/.well-known/".
> >
> > NEW:
> >
> > |  A well-known URI is a URI [RFC3986] with a URI scheme that
> supports
> > |  retrieval of generic network-based resources like the 'ftp',
> > 'http',
> > |  or 'https' scheme, and whose path component begins with the
> > |  characters "/.well-known/".  The specific syntax requirements of
> > |  the URI scheme used MUST admit this form and instance of a path
> > |  component.
> >
> > [[ The three example URI schems are given in alphabetical
> > order. :-) ]]
> 
> The intent of "whose path component begins" was to have the effect of
> restricting the URI schemes well-known is applicable, but a closer
> reading of 3986 (and your comment, of course) shows that this isn't
> the case.
> 
> I'd very much like to use language and concepts from 3986 if possible,
> rather than minting yet another classification of URIs (even though
> the one you suggest is intuitive and obvious). Would 'hierarchical
> paths' serve this purpose well enough? I suspect it may not, but it's
> worth consideration.

This might not be needed if we limit to just a few schemes. But limiting to schemes with an authority (per 3986) and a hierarchical path might also work. Are there examples where it doesn't?

> > However, I would prefer a definite list of allowed URI schemes here.
> > Any new URI scheme definition (or update to an existing definition)
> > that wants to admit/support this mechanism would then have to state
> > that precisely -- which would be very good for clarity.
> 
> This would probably be simpler. Eran, your thoughts -- would it be
> enough to just specify for FTP, HTTP and HTTPS, allowing other schemes
> to opt into it if they desire to?

I don't have any use cases beyond HTTP and HTTPS and any registration for one must also be applied to the other due to the way the two are often used together. FTP seems reasonable but are there actual use cases for it? Not sure about others. Are there known cases of well-known locations used with schemes other than HTTP(S)?
 
> > Furthermore, following the spirit of B.3, I strongly suggest that,
> > for clarity and precision, the registration template should include
> > a specific, mandatory clause, "Applicable URI schemes:".
> 
> This gives me pause. Would someone be able to register "foo" for
> protocol A, and someone else the same token for protocol B? Would they
> have to update it for protocols that are added later? Won't the common
> case be that registrations will want it to apply to all protocols
> (indeed, will there be any other case)?

If we end up with a limited set of applicable schemes, this might not be an issue anymore. But given the wide namespace available within the well-known path, I would rather each protocol mint their own well-known prefix, even if it is only used for a subset of the possible URI schemes. This seems to be a safer approach, and if anything, will encourage better well-known paths.
 
EHL