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