- From: <ned.freed@innosoft.com>
- Date: Mon, 17 Jul 2000 09:09:17 -0700 (PDT)
- To: "Martin J. Duerst" <duerst@w3.org>
- Cc: ietf-charsets@iana.org
> > 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
Received on Monday, 17 July 2000 12:21:58 UTC