Re: draft-fielding-uri-rfc2396bis-03

> 1. Sect. 1.1.2. Support Dan's rejection of listing a 'gopher' URI as a
> real-life example. Suggest that a 'urn' URI would instead make an 
> excellent
> candidate.

I have removed it for the next rev.

> Gets us further along the road that not all URIs are clickable.

All URNs are clickable -- they are just less likely to result in a
useful retrieval, at least until a resolution mechanism is deployed.

> Would it also make any sense to include an 'x-' style URI to recognize
> alternative trees, apart from the IETF tree? I'm not sure if there's 
> any
> implication of alternative trees in this document, although maybe 
> that's
> just an administrative matter for registrations.

There are no successful alternative trees at this time and I would
personally forbid the use of 'x-' prefixes if that were possible.

> 2. Sect 1.1.3. Glad to see that the URL/URN deprecations have been 
> dropped -
> not that I'm against (far from it) just that I do think equal weight 
> should
> be given to both terms URL and URN. Thus I wonder if it's striclty 
> correct
> to imply that the term URN refers to 'urn' URIs only, and whether some
> alternate wording could be used to say that URN refers to 'the subset 
> of
> URIs that provide a persistent means of naming a resource' (I'm sure 
> Larry's
> got a better definition) and to mention that specifically all URIs 
> under the
> 'urn' scheme are by this dedfinition of type 'URN'. My concern is that 
> if
> the term URN is applied to 'urn' only that does play badly with the
> 'locator' and 'name' roles that a given URI scheme may assume. There 
> may be
> other schemes that will have all the hallmarks of URN but are not 
> included
> under the 'urn' namespace.

I have added more text to explain it better (hopefully I won't get 
shot).

> 3. Sect 1.1.3. I wonder if it might be helpful to reference RFC 3305 
> 'Report
> from the Joint W3C/IETF URI Planning Interest Group' to refer readers 
> to
> contemporary clarifications and recommendations on URI, URL, URN.

Done.

> 4. Sect. 3.2.2. The 'host' production lists the terms (ipv6, ipv4, 
> hostname)
> in the opposite order in which they are dealt with in the text. Should 
> the
> production order be changed or alternatively the text order?

Done (I was trying to avoid section number change, but I agree it is
better to get it right).

> 5. Annex A. Is there any reason why the collected productions are 
> listed in
> alphabetical order, rather than logical order? Makes it difficult to 
> follow.

To make it easier to follow. *shrug*  Why else would we have that 
section?

> 6. Annex C. In the sentence 'Using <> angle brackets around each URI is
> especially recommended as a delimiting style for a URI that contains
> whitespace.' suggest adding word 'embedded' before 'whitespace' as it 
> could
> imply that the whitespace are legal charcters in the URI.

Done.

> 7. Annex D, 4th para. Shouldn't 'DAV:' properly be referred to as 
> 'dav:' if
> this is the canonical capitalization?

Done.

> 8. Annex D, 4th para. And shouldn't the phrase 'and the "about:" URI' 
> be
> changed to something like 'and the "about:" proxy URI' or somesuch. 
> 'about'
> is not a registered scheme.

No, it doesn't need to be registered to become a scheme.

> 9. Annex D, 6th para. 'The ABNF of qualified has been'. Something 
> missing?

The next page of the specification?  It should continue -- the automated
formatting leaves something to be desired, but I see no problems with
the files.

....Roy

Received on Friday, 19 September 2003 21:57:00 UTC