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, 28 September 2003 21:51:33 UTC