- From: Roy T. Fielding <fielding@apache.org>
- Date: Wed, 1 May 2002 13:53:24 -0700
- To: <LMM@acm.org>
- Cc: <hardie@oakthorn.com>, <uri@w3.org>, "'Tim Berners-Lee'" <timbl@w3.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. ....Roy
Received on Wednesday, 1 May 2002 16:53:04 UTC