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

Re: update RFC 2396

From: Roy T. Fielding <fielding@apache.org>
Date: Wed, 1 May 2002 13:53:24 -0700
Cc: <hardie@oakthorn.com>, <uri@w3.org>, "'Tim Berners-Lee'" <timbl@w3.org>
To: <LMM@acm.org>
Message-Id: <7AB07E3B-5D45-11D6-BD02-000393753936@apache.org>
On Wednesday, May 1, 2002, at 01:27  PM, Larry Masinter wrote:

> Trying to redefine "URI" as the "same" protocol element
> leads to insanity, since there's no versioning.
> The only way of cutting the knot (after several years of
> discussion) was to be clear that an "IRI" was a different
> protocol element as a "URI".

I don't understand.  The vast majority of stuff in IRI is simply how
to display one.  We don't need to include that.  The only thing I want
to include is the default: %xx means the character encoded as xx in
UTF-8.  That is already the default for MSIE and should be for other
browsers as well, and will simplify the specification.

> IRI would recycle us at Proposed. I'm opposed to
> including IRI in the URI draft if we're trying to
> move URI to Standard.

The deciding factor on when a change causes a reversion of status is
still very unclear to me even after all of these years.  All I know is
that this clarifies how the server component should generate and
interpret encoded URI characters outside of the iso-latin-1 subset
of utf-8.  In other words, it doesn't change the parsers.  It is
certainly far less of a change than introducing [IPv6] notation
within the authority component.

> The IRI draft still has several unresolved issues,
> which I hope can be resolved quickly. They may be
> obscure, but still can't be left open, e.g., RTL languages
> in IRIs: if they're allowed, what is the bidi algorithm
> to be used in rendering them?

Those kinds of things should still be specified elsewhere.

Received on Wednesday, 1 May 2002 16:53:04 UTC

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