RE: General policy

[Luc Rooijakkers <luc@opus.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