Re: Last Call: IANA Charset Registration Procedures to BCP

[ned.freed@INNOSOFT.COM]

> > Good to hear. I'm basically looking at this as "do the ones that are
> > OK to handle as last call comments". Stuff that requires discussion or
> > a new last call needs to wait for the next time around.

> Makes sense. But I don't agree on all points with your classification.

That may well be, but without substantive support from other quarters --
support I've seen no signs of -- I'm not going to accomodate your
positions on these points.

> > > - Section 3.1, 'All registered charsets MUST note whether or not they
> > >     are suitable for use in MIME text.' and Sec. 6, 'Suitability for
> > >     use in Mime text:': As recent discussion has shown, this may
> > >     benefit from some careful clarification, but I guess this already
> > >     is on your todo list.

> > It is on my to-do list, but it isn't something I want to address in this
> > registration procedure update.

> It seems to be the case that:
> - There is consensus (in the IETF sense) on the meaning of the
>    above sentences.
> - It was shown that the interpretation of the above sentences
>    may pose some problems.

> This seems to be a typical case for a last call correction.

I don't agree. This is a much bigger problem and the registry needs to be
cleaned up before it gets addressed. (Work to clean up the registry is already
underway, but I don't want to wait for it to finish before getting this update
out.)

> > >- 'All registered charsets MUST be specified in a *stable*':
> > >    What about extensions, such as for ISO 10646? What about
> > >    variants, such as for Shift_JIS (vendor extensions as well
> > >    as mapping variants, for the later see
> > >    e.g. http://www.w3.org/TR/japanese-xml/).

> > What about them? The requirement is for a stable specification and nothing
> > more. Updating the specification is OK as long as whatever rules that
> > specification gives for updating are followed. (We have a detailed set of
> > such rules for UTF-8, for example.)

> > The primary point here is that we don't want a definition based on a
> > pointer to a document which then vanishes, leaving us with a name and
> > nothing else.

> Thanks for giving the interpretation of 'stable'. This is a reasonable
> interpretation, but there are others, and the doc should make clear
> what interpretation is intended.

I'll see what I can do as a RFC editor note, but I note in passing
that you seem to be the only one who was confused by this.

> > >- 3.3 talks about names, and a primary name. The registry uses
> > >    the terms 'name', 'alias', and also 'preferred MIME name'.
> > >    It would be very helpful if the terminology were unified.

> > That's an issue for the registry, not for the present document.

> Well, if it cannot be unified, it would at least be helpful
> to point out that there are differences, and which terms
> correspond to which.

I'd much rather correct the problem than try to work around it.

> >>- [ISO-10646]: Please update this to refer to the 2000 version!
> >
> >The ISO catalogue doesn't list it yet so I didn't update it. If I
> >get a reference before publication I'll handle it as an author edit.

> Below is an excerpt from a mail from mike Ksar, convener of the
> WG responsible for ISO 10646:

I'll make the change as an RFC Editor note.

				Ned