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

Re: Comments on draft-fielding-uri-rfc2396bis-07

From: Mike Brown <mike@skew.org>
Date: Tue, 9 Nov 2004 19:08:39 -0700 (MST)
Message-Id: <200411100208.iAA28dWH099923@chilled.skew.org>
To: uri <uri@w3.org>

Bruce Lilly wrote:
> The discussion has never been about "rfc2396bis specifies that
> mailto URIs [...]"; obviously the draft under discussion does not
> specify mailto URI syntax directly. Rather the discussion has
> been about (possibly unintended) implications for mailto URI
> and other specifications caused by the massive changes in the
> generic URI syntax draft, one of which is the change of '@'
> from being explicitly not "reserved" in a path component to
> its being unconditionally "reserved".

I think Roy's position is that rfc2396bis does not impact the current (RFC 
1738) mailto scheme, so you only need to worry about the changes introduced in 
rfc2396bis when someone gets around to updating the mailto scheme to be based 
on it.

However, even if you apply rfc2396bis's definition of 'reserved' to scheme 
specs that simply say "percent-encode all reserved characters in data", they 
are not broken by the changes, as there's no harm in percent-encoding in most 
cases. It may not always be necessary to percent-encode reserved characters, 
is all rfc2396bis is saying, because it's possible that they do not have a 
reserved purpose in the URI component in which they appear.

The danger, I think, is in the assumption that a literal reserved character 
necessarily has a reserved purpose in the component in which it appears.

Nevertheless, I think one could write a book that explains, more thoroughly 
than rfc2396bis, the nuances of percent-encoding and of representing data 
characters & octets with URI characters and percent-encoded octets.

I just had a lightbulb moment about it a few weeks ago and am now working on 
redoing my Python language API for percent-encoding, as I made some critical 
mistakes that I think pretty much anyone would make, given the ambiguities in 
existing specs that deal with the subject.

Received on Wednesday, 10 November 2004 02:08:38 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:46 UTC