Re: UTF-8 revision

On Tue, 2 Sep 1997, Ned Freed wrote (quite some time ago):

(John Klensin wrote):
> > While I think that "aligns with future versions of 10646" might
> > be acceptable (and even there I see problems, as I don't know
> > how to organize a flag day), aligning with future versions of
> > Unicode is problematic as I don't think the Unicode consortium
> > meets the informal IETF criteria for openness and due process
> > that might lead us to partially hand over change control (even
> > at that, it would be largely unprecedented). The history has
> > been that we reference a particular version of some external
> > document and, if the external document changes, we have to
> > explicitly go through a new document, review, and last call
> > process to change the normative reference.
> 
> Sigh. My thinly veiled intent (as it probably took you all of two seconds to
> figure out) here was to try and keep the IETF from having a change control
> problem that could only be solved either by tieing the definition of the UTF-8
> charset to a specific version of 10646/Unicode or else having to vet every
> change/amendment/whatever that comes along. This is because I think most if not
> all of the additions will be Good Things and also that there will be a lot of
> them. As such, I attempted to craft an approach that effectively cedes IETF
> change control over genuine additions but retains it for actual changes to or
> removal of existing characters.  And frankly, my intent was also to completely
> gloss over the very sticky issue of whether or not the act of deunifying a
> Kanji character would count as a change that would have to be explicitly
> blessed by the IETF.
> 
> It simply didn't occur to me that handing over control over additions to the
> UC/UTC folks would be a process issue. But now that you mention it, I of course
> see that it is. So I would therefore suggest that we tie this to 10646 rather
> than to Unicode directly. I hope this fixes things to the point where we can
> get this through the process, because it it doesn't, the only alternatives I
> see are fairly unpalatable.

Tying it to 10646, and wording it as Francois has done in his proposal,
are the best way to go also in my eyes.

In the case there should be objections to this based on process,
I would suggest the following trick: All relevant amendments to ISO
10646 are listed in the IANA charset registry (e.g. amendment 27,
Klingon Additions, 1999). The listing of a new amendment has to
be requested on the "charsets" list, and is treated in the same
way as other requests for charset registration procedurally.
The moment there is a serious problem, that process is stopped,
and the process is resumed on a higher level (UTF-8 RFC or whatever).

Just an idea, but I really think this shouldn't be necessary.

Regards,	Martin.

P.S.: I almost finished a list of comments to the 01 UTF-8 draft
	from Francois. In particular, it contains some problems
	with respect to Unicode/UCS-2/UTF-16. I hope to be able
	to complete that mail soon.


--Boundary (ID uEbHHWxWEwCKT9wM3evJ5w)

Received on Sunday, 12 October 1997 18:04:49 UTC