- From: McDonald, Ira <imcdonald@sharplabs.com>
- Date: Sun, 5 Oct 2003 15:53:49 -0700
- To: "'Larry Masinter'" <LMM@acm.org>, "McDonald, Ira" <imcdonald@sharplabs.com>, "'Roy T. Fielding'" <fielding@apache.org>
- Cc: "'Mike Brown'" <mike@skew.org>, uri@w3.org
Hi Larry, You're right of course. URI (as names) are NOT subject to RFC 2277. I was unfortunately conflating them with (any other) _textual_ human-readable protocol elements, which certainly ARE subject to RFC 2277. Thanks for straightening me out. By the way, shouldn't RFC 2396bis (URI) at least informatively reference the IRI work? Cheers, - Ira McDonald High North Inc -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Friday, October 03, 2003 12:45 AM To: 'McDonald, Ira'; 'Roy T. Fielding' Cc: 'Mike Brown'; uri@w3.org Subject: RE: encoding related phrasing Ira, you left out the important part of RFC 2277 where it talks about scope. Names are a problem, because people feel strongly about them, many of them are mostly for local usage, and all of them tend to leak out of the local context at times. RFC 1958 [RFC 1958] recommends US-ASCII for all globally visible names. This document does not mandate a policy on name internationalization, but requires that all protocols describe whether names are internationalized or US-ASCII. In the context of RFC 2277, URIs are "names". I don't think any waiver is necessary. Rather, there is separate work (http://www.w3.org/International/iri-edit/ ) to define a new protocol element (IRI) that is internationalized. > -----Original Message----- > From: uri-request@w3.org [mailto:uri-request@w3.org] On > Behalf Of McDonald, Ira > Sent: Sunday, September 28, 2003 6:51 PM > To: 'Roy T. Fielding'; McDonald, Ira > Cc: 'Mike Brown'; uri@w3.org > Subject: RE: encoding related phrasing > > > > Hi Roy, > > Actually, the IETF can and is enforcing that no document remains > _on_ the standards track at all that doesn't support or mandate > use of UTF-8 in all human readable protocol elements. See the > highlighted line in the verbatim quote from RFC 2277 below. I > assure you from personal experience that a waiver for a variance > is _not_ likely. > > If RFC 2396 is revised and republished (as now underway), then > RFC 2396 bis MUST conform to RFC 2277 or else get a waiver. > > "Protocols MAY specify, in addition, how to use other charsets or > other character encoding schemes for ISO 10646, such as UTF-16, but > lack of an ability to use UTF-8 is a violation of this policy; such a > violation would need a variance procedure ([BCP9] section 9) with > clear and solid justification in the protocol specification document > >> before being entered into or advanced upon the standards track. > > For existing protocols or protocols that move data from existing > datastores, support of other charsets, or even using a default other > than UTF-8, may be a requirement. This is acceptable, but UTF-8 > support MUST be possible." > > Sorry I can't propose the right wording. I just observe that the > URI being pre-existing does not preclude applicability of RFC 2277. > > ...and hope Martin (for example) will suggest the best wording... > > Cheers, > - Ira McDonald > High North Inc > > > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@apache.org] > Sent: Saturday, September 27, 2003 7:52 PM > To: McDonald, Ira > Cc: 'Mike Brown'; uri@w3.org > Subject: Re: encoding related phrasing > > > > Please keep in mind that the URI technology predates UTF-8 by at > least 5 years, and the IETF policies on identifying charset in use > are even later than that. As such, they do not apply. We are > way beyond the design phase. > > The hardest part of editing a spec towards standard status is > recognizing what can be tweaked without breaking all of the deployed > implementations that justify it being a standard. New ideas need > to be proposed as separate specifications and deployed to the > point where they attain equal status with the standard. > > That doesn't mean change is impossible -- it is simply slow and not > always correct (some of the changes I made for RFC 2396 simply did > not work out in practice and were not universally deployed). > > ....Roy > > BTW, I have 56 stored requests for changes to the next draft, so > please accept my apologies if I don't respond to all of the > commentary. I read them all, but suggestions that include text > get first dibs because they are simply easier to enact or respond > to directly. >
Received on Sunday, 5 October 2003 18:54:49 UTC