Re: Raising a few issues in fielding-uri-rfc2396-0x

> 2. 1.2 - the spec says it deprecates the terms URL and URN and I'm not 
> sure it really does.  What it's really deprecating is the notion of a 
> clean useful separation between locators and names.  I've never seen 
> "URN" used in this sense anyhow, in fact I've never seen it used aside 
> from a reference to what the URN RFC defines, which is hard to argue 
> against.  If you want to deprecate

The specification refers to the IETF working group discussions that can 
be
found in the URI archive and the set of specifications thereafter 
produced
that created separate standardization tracks for URL versus URN.  Maybe 
I am
getting too old, but I assure you that the term URN existed long before 
the
"urn" scheme as defined by the IETF.

>  the term URL that's at least consistent, although once again I have 
> some nervousness about trying, in the Academie Francaise style, to 
> stop people from using words they want to use.  Potential reword of 
> the paragraph:
>
> 'An individual scheme does not need to classified as being just one of 
> "name" and "locator".  Instances of URIs from any given scheme may 
> have the characteristics of names or locators or both, often depending 
> on the persistence and care in the assignment of of identifiers by the 
> naming authority, rather than any quality of the scheme.  For this 
> reason, this specification deprecates the use of the term URN for 
> anything but URIs in the "urn" scheme as described in RFC 2141.  This 
> specification also deprecates the term "URL".'

I prefer the wording established by the IAB group, but I will look to 
see
if it can be better explained.

> 3. 1.2, fourth para; the phrase "just like any identifier" is 
> superfluous.

I've added these to issue 019-URI-URL-URN.

> 4. Section 3
>
> This section is awfully short of examples.  I would think the 
> usefulness would be improved by including at least one example for 
> each of 3.1, 3.2.1, 3.2.2, 3.3, and 3.4.  If others agree, I would 
> volunteer to cook up the examples.

Sure.  It would be best if they covered the range of variance, so that 
the
folks who try to implement according to examples (and not BNF) are not
led too far astray.  [I have seen plenty of cases where implementers of
RFC 2616 looked at the examples and implemented only the cases 
described,
ignoring the actual syntax specification.]

New issue: 032-syntax-examples

> 5. Section 4.
>
> "URI-reference" is hyphenated the first time it appears and I don't 
> see why.

Because it is a BNF term.

> 6. Section 4.
>
> I think the first paragraph is kind of convoluted.  Let me try to boil 
> it down a bit; if I've misunderstood what it's trying to say that in 
> itself would be a useful diagnostic I think.
>
> 'The term "URI Reference" describes a commonly-used syntax for 
> resource identifiers, which may be absolute or relative and may 
> include additional information in the form of a fragment identifier.  
> Each URI Reference may be mapped to a URI by converting it (if 
> relative) to its absolute form and removing the fragment identifier.  
> While this specification's discussion of syntax and semantics is 
> mostly concerned with the absolute form of URIs, it is recognized that 
> most usages of URIs take the form of references.'

This is tied up with the URI vs URIref issue and will be rewritten 
anyway.

> 7. Section 4.
>
> As to "." and "..", I agree with TimBL that it is violently 
> inconsistent to restrict the special meaning of these syntaxes to the 
> relative form of URIs.

Historically speaking [1993-1994], implementations of such were entirely
inconsistent.

>  If I am given the URI http://example.com/a/./b/../c I will always, 
> 100% of the time, regard that as http://example.com/a/c. I have just 
> verified that the first two randomly-picked web browsers I picked in 
> fact do this.  So the assertion that this only applies to the relative 
> form is, I assert, simply wrong and should be removed.

I think you need to look more closely at what the browsers are doing.
They send the /../ and /./ stuff to the server, whereupon an Apache 
httpd
will respond with a redirect to the correct URI.  Other HTTP servers may
do the same, others may not redirect and just serve it as a separate
resource (leading to a large number of security holes), and still others
will simply respond with 404 not found.

I don't have an objection to changing it in the specification, but
no existing browsers that I know about do this canonicalization on
the browser side.  Spiders often do.  Furthermore, HTTP servers do
consider them to be different resources at the present time -- the
redirect is for the sake of back-end security and to help-out ancient
versions of the lynx browser with relative URI (which in early days
simply concatenated the relative URI to the base URI), not because
we think of them as equivalent identifiers.

I'll place this under the issue TimBL raised when I add it to issues.

> 8. Section 5.
>
> Same as comment #4 above; examples would improve this, and if others 
> agree, I'll cook some up.

As it says, "Resolution examples are provided in Appendix C."  There is
another issue 021-relative-examples calling for more examples (using
a different base URI), but none have been suggested so far.

Thanks for your comments,

....Roy

Received on Tuesday, 25 February 2003 23:07:32 UTC