W3C home > Mailing lists > Public > uri@w3.org > February 2004

Re: Comments on draft-fielding-uri-rfc2396bis-0x

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 16 Feb 2004 00:36:05 -0800
Cc: uri@w3.org
To: "Kay, Michael" <Michael.Kay@softwareag.com>
Message-Id: <28F07BFA-605B-11D8-8468-000393753936@gbiv.com>

On Tuesday, August 5, 2003, at 08:04  AM, Kay, Michael wrote:

> This is clearly a great improvement on RFC 2396.
> It is disappointing, but not really surprising, that the document 
> still contains so many words like "should", "recommended", "unwise", 
> "generally counterproductive", "discouraged", and "abnormal", which 
> all tend to give the impression that handling URIs is a black art 
> rather than a precise science.


> The document retains one ambiguity from RFC 2396: is the zero-length 
> string a valid relative URI reference? The ABNF syntax seems to 
> suggest that it isn't, but sections 4.4 and 5.4.1 assigns semantics to 
> this case, saying this is an "abnormal" case which URI parsers 
> "should" be capable of handling. I think that the use of "" as a 
> relative self-reference should be treated as being wholly respectable. 
> (What does "abnormal" actually mean?)

The ABNF for URI can be empty.  "" has been moved to the normal 

> I'm disappointed to see that the term "current document" still appears 
> in section 4.4, and is nowhere defined. In 5.4.2 it appears in 
> residual form as "current base URI". Are "current document" and 
> "current base URI" the same thing as "the resource identified by the 
> base URI"? If so, say so.


> The section heading of 4.2 is "Relative URI", but in fact a relative 
> URI reference is not a URI, so this term should not be used.

That water passed the bridge ten years ago.

> In 4.4 the statement "the dereference should not result in a new 
> retrieval" seems to contradict section 1.2.2, which strongly suggests 
> that the semantics of the dereferencing operation are outside the 
> scope of the RFC.

It is a common operation.

> It's much clearer now that a string is not a URI unless all the 
> special characters have been properly escaped. Nevertheless, there is 
> still some residual language that hints that the input to the escaping 
> algorithm might also be referred to as a URI. 2.4.2 says "characters 
> within a URI string are escaped". What exactly is a URI string? 
> Similarly, "Once generated, a URI is always in an escaped form" hints 
> that there are other circumstances in which a URI might not be in 
> escaped form. It might be useful to define some formal term for the 
> unescaped representation of a URI, for example a "URI-rendition", so 
> that we can talk about this string without referring to it as a URI.


> The discussion is useful, but it would also be useful to define a 
> preferred (and named) default algorithm for comparing URIs that other 
> specifications can refer to.

Doing so would contradict the purpose of describing it as a ladder.
I have changed the discussion to be more actionable rather than

Received on Monday, 16 February 2004 03:34:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:07 UTC