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

Re: URI Generic Syntax doc (draft-fielding-uri-rfc2396bis-03)

From: by way of Martin Duerst <klensin@jck.com>
Date: Sat, 07 Feb 2004 17:31:23 -0500
Message-Id: <>
To: uri@w3.org


Thanks.  I think this is very good progress, and I look forward to reading 
the new draft.   A few comments...

(1) If specifying what must be specified in specific URI definitions is 
"the role of RFC 2718 and BCP 35 (RFC 2717)...", which may be quite 
reasonable, I think those docs should be crossreferenced in 2396bis.  A 
sentence like "There are specific requirements that these per-scheme 
characteristics be defined for the schemes, see [RFC2718bis, RFC2717bis]" 
may be a forward pointer but is not normative, since it provides references 
for additional reading about a related topic, rather than information 
needed to understand/implement 2396bis.

(2) The IPv6 syntax issue.  RFC 2821 does not provide a variant/ different 
IPv6 syntax (although changes by the IPv6 folks may require some slight 
retuning in 2821bis).  What it does is to specify that, if the addressing 
scheme isn't IPv4, then the scheme must be tagged with what it is, rather 
than deduced by heuristics on the address syntax chosen.  Think of it as a 
wrapper around whatever the IPv6 folks specify, rather than a different 
syntax.  On that basis, I think you can do exactly the same thing and that 
a "no heuristics" or at least "no heuristics if there is any possible 
alternative" principle will generally serve URIs and the web well. If, due 
to other pressures and considerations, you need to permit IPv6 addresses 
without any qualification, it seems to me that it would be useful to 
identify an identified/tagged form, make it normative, and then define the 
IPv6 address form without the tag as a permitted abbreviated syntax 
variation.  That at least puts the right future stake in the ground.  That 
stake is necessary if we see URIs outliving the Internet as we know it, and 
some of the other W3C-derived architecture documents and public 
presentations clearly anticipate that.


--On Saturday, 07 February, 2004 01:08 -0800 "Roy T. Fielding" 
<fielding@gbiv.com> wrote:

>On Wednesday, July 9, 2003, at 12:04  PM, John C Klensin wrote:
>>The document is a considerable improvement over RFC 2396, but
>>I've  ended up with two major problems and a few nits.
>>(1) There are a number of places in which the document seems
>>to go to  such efforts to be general and to avoid
>>over-constraining particular  URI schemes that it has
>>achieved a level of abstraction  indistinguishable from
>>incomprehensibility and, occasionally, internal
>>contradictions.   Examples below, but I think either some
>>rewriting or  _very_ careful consistency review is needed, if
>>not both.
>In almost all of the cases you note, this has been due to a
>between wishing to remain consistent with prior UR*
>and yet reflect how these things have actually been
>implemented in
>the real world.  This has been a particular problem with
>characters.  I agree that the balance isn't working, so I have
>the sections such that all of the reserved characters are
>as delimiters (assigned or available to be assigned by
>schemes) and
>all of the unreserved characters are always data.
>>(2) The problem I think we got into with MAILTO, and perhaps
>>with  other URI schemes, is that it is tempting to refer to a
>>generic URI  document and say, about syntax and escaping, "do
>>what it says there".   Unfortunately, what this says is very
>>general and non-specific, and  some of the terms don't mean
>>quite what one would assume on casual  reading.   I believe
>>the document would benefit significantly from a  short
>>section titled, e.g., "Specification Requirements for URI
>>schemes" and that would then include, in very specific terms,
>>a list  of things that a URI scheme description/ standard
>>must specify.  I  would expect that list to include an exact
>>list of characters that  must be escaped within the context
>>of that scheme.
>>I believe that is the role of RFC 2718 and BCP 35 (RFC 2717),
>will be revised as soon as I get this one off my plate.
>>(3) Details...
>>(i) Section 2.1.  I understand, I think, the reasoning behind
>>the  "maybe it is ASCII and maybe it is not" language here.
>>But, if URI  appears in machine-readable form, and the scheme
>>name is not (or might  not be) in ASCII (or any other
>>pre-specified character set), how is a  URI parser or other
>>processor to recognize it?   Put differently,  there is a
>>bootstrapping problem: one must know the character set of
>>the scheme name before one can figure out how to parse or
>>process  anything else. I might be wrong about this but, if I
>>am, this section  needs a bit more explanation.
>I think it is generally true that one must know the character
>of any document before one can process it (or at least a
>defined mechanism
>for discovering the character encoding prior to reaching the
>I have added: "When a URI appears in a protocol element, the
>encoding is defined by that protocol; absent such a
>definition, the
>URI is assumed to be encoded in the same character encoding as
>surrounding text."
>>(ii) Section 2.2.   Normally, "reserved" means "always", and
>>"can't be  used for anything else".  It isn't the meaning
>>here (or actually, is  partially the meaning).  Things would
>>be much more clear if the  production/definition were broken
>>up into
>>  reserved = Subcomponent-Delimiter-Role /
>>             Other-Often-Reserved
>>  Subcomponent-Delimiter-Role = "/" / "?" / "#"
>>      (and colon (":") ???)
>>  Other-Often-Reserved = <the rest of the list>
>>Some small rearrangement of the paragraphs below would then
>>make  things much more clear.
>Done, though I use the names gen-delims and sub-delims.  I
>have also
>moved the unsafe mark characters to the reserved set, since
>that is
>how they are used in practice and the source of most of the
>>Also, "URI's origin" should be precisely defined somewhere
>>(it isn't  in the index).  A naive reader could interpret the
>>term as either "the  definition of the URI type/scheme" or
>>"the author/ process that  produces some particular URI
>>instance".  A similar comment applies to  "URI creator" which
>>appears at the end of section 3.2.2.
>Replaced with "the implementation-specific syntax of a URI's
>dereferencing algorithm".
>>(iii) Section 2.5. As with "reserved", "excluded" doesn't
>>seem to have  its normal English meaning of absolutely
>>forbidden.  I read this  section to say that "excluded"
>>characters should be avoided if  possible and escaped
>>otherwise.  If that is the intended meaning, it  should
>>appear in so many words.    But I'm not sure it is.  For
>>example, the exclusion of characters outside the ASCII range
>>would  appear to prohibit UTF-8, even in %-encoded form, and,
>>given other  text in the document, that clearly is not the
>Yes, I'll work on a better way of describing excluded glyphs
>than excluded characters.
>>(iv) Section 3 introduction.  The first sentence lists a
>>"path"  component.  There is no "path" component in the
>>syntax productions,  although I assume that "hier-part" is
>>more or less the same thing.   And then the next sentence
>>says that the "path components" (not  plural) is required.
>>Either more explanation is needed here or  "hier-path" should
>>be renamed to "path-component" or equivalent.  It  would also
>>be useful to explicitly note that the productions for
>>scheme, authority, etc. are defined in subsequent subsections.
>>The last sentence of the second paragraph says "a
>>non-hierarchical  path will be treated as opaque data...".
>>But, from the productions,  there appears to be no such thing
>>as a non-hierarchical path".
>These will be fixed before the next revision due to other
>comments received.
>>(v) Sectin 3.2.2 and IPv6.  I don't know if there is a future
>>version  of IP beyond v6, but please don't dig us into a
>>corner by having only  the IPv4 and IPv6 forms and no way to
>>move beyond that.  Consider the  RFC 2821 solution, in which
>>address literals for other than the  (historical) IPv4 ones
>>must be explicitly identified by a  protocol-specific keyword.
>Unfortunately, I have no control over the syntax supplied and
>by the IPv6 working groups, and it is difficult for me to
>invent one and
>also provide the implementations necessary for a Draft
>Standard status.
>>In the fourth paragraph, please insert "and should be
>>followed by one"  before "if it is necessary to distinguish".
>>I.e., the trailing "." is  always permitted but, if there is
>>any question about whether the  domain is an FQDN or a
>>fragment of some sort, it should (or even must)  be present.
>>(vi) Section 3.3.  The distinction between "path" and
>>"authority"  needs to be more clearly drawn.  This section
>>clearly defines mailto  as using a path, but the authority
>>discussion and syntax in 3.2 might  be construed as having
>>mailto consisting of an empty opaque path and  an authority.
>>Since the syntax for net-path in 3 seems to suggest  that, if
>>it were an authority, mailto would have to be
>>  mailto://fred@example.com rather than
>>  mailto:fred@example.com
>>I think the text is correct and consistent.  But it is
>>exceptionally  confusing.
>I will try to make it less confusing with the next revision
>due to the
>other changes with path.
>>(vii) Section 4.5 on Suffix References.  We all know this
>>practice is  common.  We also know that it leads to trouble,
>>especially when  "heuristics change over time".   I think the
>>section should be a bit  more clear about the problems, and
>>then clearly recommend avoiding  these if possible, rather
>>than circling around the issues. It should also note that the
>>"suffix" often contains only part of a  DNS hostname ("foo"
>>in the expectation that the processor will turn it  into
>>"http://www.foo.com" or something equivalent and that form is
>>very high-risk behavior.  See RFC1535 and/or for discussion
>>of some of  the downsides of these games.
>I have changed it to:
>While this practice of using suffix references is common, it
>be avoided whenever possible and never used in situations
>where long-term
>references are expected.  The heuristics noted above will
>change over time,
>particularly when new URI schemes are introduced, and are often
>incorrect when used out of context.  Furthermore, they can
>lead to
>security issues along the lines of those described in
><xref target="RFC1535"/>.
>>(viii) Section 7.5.  But this is where a careful distinction
>>between  "authority" and "path" becomes important, along with
>>clarity about  types of "reserved" characters.  An only
>>slightly confused reader  could conclude that it was possible
>>to define a MIXER URI type in > which
>>  mixer:/I=J/S=Linnimouth/GQ=5/@Marketing.Widget.COM
>>Was valid.  I don't think it is, but it takes much too long
>>to prove  this from 2396bis.
>That is a valid URI.  It is a weird one, but I've seen worse
>Roy T. Fielding
>Chief Scientist, Day Software
Received on Sunday, 8 February 2004 10:09:12 UTC

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