RE: draft-fielding-uri-rfc2396bis-03

Roy:

Some (mostly minor) comments:

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. Gets us further along the road that not all URIs are clickable.
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.

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.

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.

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?

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.

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.

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

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.

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

Tony
 

Tony Hammond

Advanced Technology Group, Elsevier Ltd
32 Jamestown Road, London, NW1 7BY, UK

<tel:+44-20-7424-4445>
<mailto:t.hammond@elsevier.com>

> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@apache.org]
> Sent: 10 June 2003 05:38
> To: Dan Kohn
> Cc: uri@w3.org
> Subject: Re: draft-fielding-uri-rfc2396bis-03
> 
> 
> 
> > Roy, latest draft looks great, except for the following issues (all
> > minor):
> 
> Thanks.
> 
> > Under no reasonable definition of the phrase "in common 
> use" could the
> > gopher URI fit.  It should be removed.
> 
> It is pretty common in historical documents. ;-)  Seriously, though,
> gopher is still in common use in Universities.  I'd prefer to find a
> replacement example, such as imap or urn -- suggestions are welcome.
> 
> > In Appendix D, please consider putting the names of rules in 
> > <brackets>,
> > as recommended in RFC 2234, Section 2.1.
> 
> I actually tried that while working on 03 and the result was butt-ugly
> and much harder to read.
> 
> Unless there is a strong objection, I'd prefer to keep it clean.
> 
> > There's not enough information to dereference [Siedzik]. 
> The symbolic
> > name [UTF-8} should be changed to [RFC2279] for consistency.  Also,
> > please change <?rfc sortrefs="no"?> to yes to make it 
> easier to review
> > the references.
> 
> Hmm, I guess we should be consistent.  Personally, I prefer symbolic
> names like UTF-8 except when we are referring to a specific 
> RFC number.
> 
> http://www.giac.org/practical/gsec/Richard_Siedzik_GSEC.pdf
> 
> Unfortunately, the xml2rfc doesn't know much about non-RFC references.
> 
> ....Roy
>

Received on Wednesday, 11 June 2003 06:26:00 UTC