Re: UTF-8 revision

[Ned Freed <Ned.Freed@INNOSOFT.COM>]

> > (2) I think you're going to have a significant problem getting this through
> >     the IETF process unless you take a stand on what happens should the
> >     character assignments in some future Unicode version change in an
> >     incompatible way. Yes, I know that promises have been made that this will
> >     never happen again, but that's all they are: Promises. The IETF has a
> >     policy that it must retain change control over its own standards, and
> >     this is a case where someone else effectively has change control over
> >     the actual technical core of this specification. I therefore think that
> >     this specification needs to say that it aligns automatically with
> >     all future versions of Unicode that don't make incompatible changes, but
> >     the minute one is made it stays aligned with the old version until and
> >     unless the IETF specifically decides otherwise.

> 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.

				Ned