W3C home > Mailing lists > Public > uri@w3.org > January 2000

RFC 2732, [], and XPointer (was: ACTION:draft-ietf-ipngwg-url-literal-03.txt)

From: Martin J. Duerst <duerst@w3.org>
Date: Sun, 09 Jan 2000 16:29:00 +0900
Message-Id: <200001100020.JAA23357@sh.w3.mag.keio.ac.jp>
To: Larry Masinter <masinter@attlabs.att.com>
Cc: Bob Hinden <hinden@iprg.nokia.com>, jg@w3.org, uri@w3.org, Brian E Carpenter <brian@hursley.ibm.com>
At 08:16 00/01/07 -0600, Brian E Carpenter wrote:
> It's now Proposed Standard RFC 2732

E.g. at http://www.ietf.org/rfc/rfc2732.txt

Thanks! This clears up the situation re. what document is relevant.

Now on to the more technical matters. I am copying uri@w3.org
and www-xml-linking-comments@w3.org, two public mailing lists,
because I think it's good to get feedback and mutual understanding
from the uri list, and because this immediately affects XPointer
(see http://www.w3.org/TR/xptr, in particular http://www.w3.org/TR/xptr#escaping
and my comments at

I much earlier wrote:

> > > - [] are moved to reserved. Does this mean that in other parts
> > >   of the URI (reference), they can also be used that way?

The RFC also says: "It defines a syntax
for IPv6 addresses and allows the use of "[" and "]" within a URI
explicitly for this reserved purpose."

Because 'fragment' includes 'reserved', the answer to the above question
seems to be 'yes'. On the other hand, 'explicitly for this purpose'
seems to indicate a no. But I'm interested in actual legacy issues
much more than in legal hairsplitting.

> > >   There are proposals to use [] e.g. in the fragment identifier
> > >   syntax for XML http://www.w3.org/TR/WD-xptr. There may be
> > >   several legacy issues here.

I'm having somewhat of a bad feeling here, but I'm not sure there
is a problem. I'll try to write down my thoughts, and would be
very happy about comments of any kind.

Unwise means: Always escape.
Reserved means: Distinction between escaped and non-escaped is
    very important.

When typing [ or ] in a browser address field, an old impl will
change them to %something, a new one won't. An old impl obviously
doesn't know about IPV6 (except if the URI pivot knows about them,
but the browser UI doesn't), so this may not be a big problem.
Strange things may happen; I just entered one of the examples
in the RFC, http://[2010:836B:4179::836B:4179], into my Netscape
4.7 (Japanese), and got to 
telling me in French that I should check 2010836b4179836b4179 in
Larousse, the most renowned French dictionary.

When sending URIs over mail, some mailers will have difficulties
to allow selecting these new URIs, both for IPV6 and for XPointer,
because the [] confuse the heuristic algorithms. This will have
to be updated. But it's probably not that big of a problem.

When URI references including [] get passed around, some part
somewhere may change the [] to %hh by old implementations.
For XPointer, that doesn't look like a problem, because
XPointer was designed under the assumption that [ and ] would
have to be escaped anyway. XPointer currently has no need
to distinguish between a 'reserved' [ or ] and a nonreserved
[ or ], and unless that would be changed in the future, we are
fine here. So the way to think here is that the (new) infrastructure
will preserve the distinction between [/] and their escaped
form, but XPointer won't need that, and will just fold the
distinction back together. *This should be explained carefully
in the XPointer spec*.

Related to this, XPointer thought they needed an additional way
of escaping for ( and ), for which the draft proposed to used
^( and ^) (and ^^ for ^), but because these are in the 'reserved'
category already, the distinction between their 'reserved' role
(delimiting pointer schemes) and a potential unreserved role
inside a scheme (if unbalanced) can be done by using (/) for the
first role, and %hh for the second role.

Regards,   Martin.

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:duerst@w3.org   http://www.w3.org
Received on Sunday, 9 January 2000 19:21:30 UTC

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