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

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

From: Bruce Lilly <blilly@erols.com>
Date: Sun, 7 Nov 2004 10:44:35 -0500
To: uri@w3.org
Cc: "Roy T. Fielding" <fielding@gbiv.com>
Message-Id: <200411071044.36422.blilly@erols.com>

On Fri November 5 2004 16:10, Roy T. Fielding wrote:

> They weren't dismissed out of hand -- they were considered and rejected
> because they are unsupported by the text that appears in the 
> specification.

Let's look again at Graham's comments:
I tend to agree that this paragraph that you mentioned is not especially 
URI producing applications should percent-encode data octets that 
correspond to characters in the reserved set. However, if a reserved 
character is found in a URI component and no delimiting role is known for 
that character, then it should be interpreted as representing the data 
octet corresponding to that character's encoding in US-ASCII.

If late editorial changes are being considered, I would suggest deleting 
this paragraph completely, since the first sentence can be read as 
contradicting the content of section 2.4, and as far as I can tell the 
second sentence repeats material already given at the beginning of section 2.

The paragraph consists of two sentences, one dealing with
generation of URIs and the other regarding interpretation of
a received URI.  I agree with Graham's specific critique of
each sentence. [And I would add that section 2.4 needs
some work; in particular "Implementations must not
percent-encode or decode the same string more than once"
makes no sense -- if a string is encoded or decoded, the
result is not "the same string" -- and there is no reason to
prohibit encoding "the same string" multiple times for the
purpose of obtaining multiple copies of an encoded
representation (e.g. for use in separate contexts such
as text/plain vs. text/html); that is a perfectly reasonable
thing to do.]

Graham's specific comment regarding the first sentence is that
its prescription that all data octets corresponding to any reserved
character should be unconditionally encoded contradicts the
specific conditions discussed in the portions of section 2.4 (first
two sentences (but not the third) of the first paragraph, and the
entire third paragraph (but not the second)) which discuss
encoding considerations when generating URIs. [It should be
clear that some reorganization of 2.4 is advisable, given the
back-and-forth change in topic between generating and parsing
evident from the above parenthetical description.]  I do not see
how one can reasonably claim that that specific critique about
the contradiction between various parts of the draft text is
"unsupported by the text that appears in the specification"; it is
precisely that text that is the subject of the critique!   Likewise
for the critique of the second sentence as repetitive and
redundant [granted, redundant repetition is a less serious
problem than self-contradiction].

> That has no bearing on the status of the mailto specification.

It has no *direct* effect on the *status* of the mailto *specification*
RFC.  RFC 2368 is a Proposed Standard, the lowest rung on the
Standards Track ladder, so resetting the status of the URI syntax
specification from Draft Standard to Proposed -- and the number
and scope of changes in the draft under discussion from 2396
certainly should result in a reset to Proposed -- cannot have a
secondary effect on the status of 2368 (neither Draft Standards
nor full Standards can depend on a Proposed Standard as a
normative reference, so it is possible that RFCs other than 2368
may have to change status).  The change in the set of URI reserved
characters does however have a substantial effect on
*implementations* of the mailto specification, since that
specification explicitly makes reference to the set of URI reserved
characters defined (differently!) in RFC 2396 and the draft under
discussion, and prescribes specific treatment for that set of

> If you had been reading the uri mailing list, you would know that
> draft 07 was created to resolve the editorial issues identified in
> the IESG last call of draft 06 so that the IESG would have a clean
> document to review on October 13 and subsequently approve for
> publication as a Full Standard on October 18.  Note that all of
> those dates are in the past -- the document is already in the
> RFC editor's queue as of 2004/10/19.

I became aware of the existence of the draft on October 25,
when it was referenced in a revision of another draft regarding
an issue raised in February related to (a non-mailto-specific)
RFC 2396 syntax.  I downloaded draft-07 that day, began
reviewing its implications, and joined the uri list mentioned
in that draft as the place to address comments on November
1 (after scanning recent discussion to see if mailto URI issues
had been discussed for draft-07) in preparation for submission
of my comments.

It appears from the discussion that has since taken place that
the implications of the substantive changes from RFC 2396
have not been fully recognized or addressed. Indeed Appendix
D which is supposed to be a summary of changes fails even to
mention the fact that whereas '@' was explicitly not "reserved"
in the path component in RFC 2396, it is now "reserved"
unconditionally. Aside from apparent failure to consider and
address the implications of the changes w.r.t. RFC 2368 (mailto
specification), it is unclear whether or not the implications for
other specifications which use URI syntax have been considered
(RFCs 2017, 2369, and 2557 come immediately to mind,
no doubt there are many others). If those implications have
not been fully considered, then publication of the draft as a
Standards Track RFC ("no known technical omissions" -- RFC
2026) may be premature (that requirement can of course
be explicitly waived for a Proposed Standard, but it does not
absolve the authors from having to address those omissions
before the specification can advance to Draft Standard
> Likewise, you should know that all standards-track specifications
> must be revised, obsoleted, or moved to historical within a reasonable
> time after their dependencies have progressed on the standards-track.
> The mailto specification will be revised, with or without the original
> authors, and you should address your comments to that effort when
> it takes place.

The mailto RFC refers to RFC 1738, which was updated by RFC 2396
when the latter was published in August 1998, one month after the
publication of RFC 2368 (1738 was a Proposed Standard, 2396 is a
Draft Standard, so that was certainly progress on the Standards Track).
More than six years later, 2368 still hasn't been revised, as you say
"with or without the original authors"; nor has it been obsoleted or
moved to historical status.  One might wonder just what constitutes
"a reasonable time" (or perhaps whether there is a disconnect
between what is supposed to happen and reality).

Returning to Graham's comments: publishing the text as it stands
as an RFC is likely to elicit similar comments in response to that
Request For Comments -- the "head-in-the-sand" approach works
no better for RFC authors than it does for ostriches.  If it remains
your opinion that Graham's suggestion "is not an editorial change",
then you should consider that that implies that the status may
have to be reset to Proposed Standard when the issue is
eventually addressed.  That reset can occur sooner or later and it
can occur multiple times -- the later it occurs, the later it will be
until a viable full Standard is reached.
Received on Sunday, 7 November 2004 19:01:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:35 GMT