W3C home > Mailing lists > Public > uri@w3.org > November 2002

Re: Ambiguity of Allowed/Recommended URI Syntax and Escaping

From: Jim Correia <correia@barebones.com>
Date: Mon, 18 Nov 2002 15:30:46 -0500
Cc: "Roy T. Fielding" <fielding@apache.org>
To: URI List <uri@w3.org>
Message-Id: <9E1E4010-FB34-11D6-844A-003065B10AEA@barebones.com>

On Monday, November 18, 2002, at 02:50  AM, Roy T. Fielding wrote:

> Yes (see note regarding "/" in query).
>>  According to the spec, is it valid for them to be left un-escaped?
> Yes, since only the generator knows why they are being used.
>> (In the context of the query, what is the meaning of the reserved 
>> purpose?
>>  The usual reserved purpose of / is as a hierarchy separator, and 
>> when used as data in the query part it is no longer a hierarchy 
>> separator, correct?)
> The generic syntax does not consider it as a hierarchy separator in
> the query.  However, that does not prevent the URI generator from
> considering it a hierarchy separator, or even a foo-bar separator.
> The purpose of reserved characters is to give components some 
> characters
> that can be safely used as delimiters within that component.  Whether
> or not the generator uses those characters is unknown, and doesn't
> matter to other parsers.

(Sorry if I appear to be obtuse, but I want to make sure I am clearly 
understanding what you are saying.)

Going back to the original example


the generic syntax doesn't consider a / a hierarchy separator, only 

So if it is mean to be presented to the redir cgi (in this case) as 
data, it should be encoded.

If it is meant to be presented to the redir cgi as its reserved meaning 
(whatever that may be) it should be left unencoded.

The only two parties that can determine whether it should or should not 
be encoded is the party writing the URI knowing how it should and will 
be interpretted by redir, and redir itself since it has defined the 
reserved purpose?

Am I following what you have written, or reading right past what you've 

Received on Monday, 18 November 2002 15:30:47 UTC

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