RE: General policy

[Masataka Ohta <mohta@necom830.cc.titech.ac.jp>]

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

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

Fixing state 'before any "real" character occurs' is, as I use the
phrase "Fixing state", by definition, stateful encoding.

The encoding is just as bad as external labeling and has most of the vice
of stateful encoding.

> There are ways to use something like ISO 2022 (or rather, the ISO
> registration mechanism) in a stateless encoding.

True, if proper profiling is done.

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

The most serious problem with external labeling , including MIME, is,
it does not allow mixing character sets with different labels. That's
why hacks like RFC for ISO-2022-JP was required. MIME is OK for the
requirements of 3 or 5 years ago. But, as the ultimate solution, not.

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

Characters in TXT records and characters in labels are unrelated. See
RFC103[45].

						Masataka Ohta