- From: Luc Rooijakkers <luc@opus.spc.nl>
- Date: Fri, 06 Aug 1993 18:59:49 +0100
- To: Masataka Ohta <mohta@necom830.cc.titech.ac.jp>
- Cc: Harald Tveit Alvestrand <harald.t.alvestrand@delab.sintef.no>, luc@opus.spc.nl, ietf-charsets@INNOSOFT.COM, luc@spc.nl
> > One possible labelling scheme when short octet strings must be labelled > > is to use ISO 2022 escape sequences, but require that all character > > set designation and invocation is done in the beginning of the string, > > before any "real" character occurs. > > > > This is a relatively compact method that does not require developing new > > standards. It does not allow the use of the ISO-2022-JP method, however. > > If you use ISO2022, it does not differ so much whether you use > an announcer only once at the beginning or you switch during > text. This is true, but you are still going from a stateless encoding to a stateful encoding, which may have other disadvantages. > > I'm not suggesting this at present, just mentioning it as one possible > > mechanism. > > ISO 2022 is not so bad as an unofficial intermediate encoding method, if > it is compatible both to ASCII and to the ultimate encoding, that is, it > must be, practically, 7 bit. No 8 bit 8859 please. There are ways to use something like ISO 2022 (or rather, the ISO registration mechanism) in a stateless encoding. > In ASCII only environment, we didn't need any labelling. With the > ASCII compatible ultimate encoding, we also don't need any labelling. > > But, if you introduce some official intermediate encoding, we > must support labelling, we must support conversion from the > intermediate to the ultimate encoding during the transition > period. > > Moreover, during the transition period, we can't assume good > properties of encoding shared by ASCII and the ultimate encoding, > which makes the transition to the intermediate encoding quite > difficult and transition to the ultimate encoding meaningless. > > So, we should not introduce an intermediate encoding. I agree with Otha here. Most current protocols do *not* support labeling (MIME is an exception here, and its designers didn't like it, witness the excerpt I posted earlier). It would be better to design an encoding that has *internal* room for extension, in an upward compatible way, rather then extending the number of encodings. > > If DNS dies when there's an ESC in a TXT record, > > It does not. No; in fact DNS is supposed to handle binary labels, though it *will* attempt case-insensitive matching. There may be implementations out there that have some restrictions, however (for example, BIND cannot handle NUL characters). -- Luc Rooijakkers Internet: lwj@cs.kun.nl SPC Company, the Netherlands UUCP: uunet!cs.kun.nl!lwj --Boundary (ID uEbHHWxWEwCKT9wM3evJ5w)
Received on Friday, 6 August 1993 10:49:03 UTC