Subject: draft-nottingham-site-meta-03

From: Alfred Hönes <[email-masked]>
Date: Tue, 13 Oct 2009 11:29:25 +0200 (MESZ)

Hello,
I've taken a look at draft-nottingham-site-meta-03 and would like
to submit a few comments, grouped into two topics.
(Otherwise, the editorial quality of the draft is very good!)

(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. :-) ]]

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.

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 proposal slighrly changes the semantics of the affected URI
schemes, part of which have been specified in Standars Track RFCs.
Consequentially, the Intended Status and metadata of the draft
should be reconsidered: it perhaps should formally 'Update' those
RFCs and must try to go the Standards Track as well.

(2)  Terminology

Please use precise terminology as established in the IETF and
elsewhere.  The colloquial sloppy truncation of the precise term,
"header field[s]" to "header[s]" should be avoided in RFCs-to-be.
Please adjust the 2nd paragraph in Section 1 accordingly.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Oct 2009 12:24:08 +1100

Hello,

Thanks for the feedback; responses below.

> [[ The three example URI schems are given in alphabetical  

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.

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

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

> RFCs and must try to go the Standards Track as well.

It is going attempting to go to Standards Track; see Lisa's last call  
(ignore the in-document status) <https://datatracker.ietf.org/idtracker/draft-nottingham-site-meta/ 
 >.

I agree it needs to update some documents; depending on how the above  
discussion goes, it needs to update either 3986 or the specific  
protocols in question.

> Please adjust the 2nd paragraph in Section 1 accordingly.

Given that it's the introduction and non-normative, and that it's  
clear to readers, I'm not inclined to change this. "Headers" is widely- 
used (e.g., in 2616) and understood.

Regards and thanks again,

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Oct 2009 18:43:31 -0700

> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Tuesday, October 13, 2009 6:24 PM
> To: Alfred HÎnes
> Cc: Eran Hammer-Lahav; [email-masked]
> Subject: Re: draft-nottingham-site-meta-03
> 
> Hello,
> 

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?

> 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)?
 
> (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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Oct 2009 14:40:59 +1100

HTTP(S) works for me.

On 14/10/2009, at 12:43 PM, Eran Hammer-Lahav wrote:

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