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 Friday, 3 October 2003 00:47:55 UTC