> > > Also, please note that
> > > ISO-2022-JP is not in fact conformant to ISO 2022, despite its name,
> > > because it uses designations only, anew on each line, whereas
> > > the basic idea of ISO 2022 is to use designations once, or once on
> > > each line, and then only invocations. This is clearly stated in
> > > the new version of JIS 208, namely JIS X 0208:1997, Appendix 2
> > > (normative), Note to item 1.
> >=20
> > ISO-2022-JP swaps different character sets in and out of G0.
> > While this may not be the best practice in some sense, it seems
> > unlikely to me that it's actually forbidden.
>
> The swapping of different character sets in and out of G0 is
> not at all forbidden. It is one of the core features of ISO
> 2022, called designation. But some other details of ISO-2022-JP
> are wrong, at least as far as JIS X 0208:1997 goes. I would
> have to find out what these details are.
I don't see any problem in ISO-2022-JP with conformance to ISO-2022;
the only questionable use may be that it implies that the G0 designation
is reset at MIME line boundary. This is not really a problem w.r.t.
MIME processing, as it is simply saying that conversion should occur
on the granularity of individual lines. This consititutes an application
layer protocol on top of ISO-2022. Of course this does pose some problems
for treating ISO-2022-JP in non-MIME contexts or quasi-MIME contexts
that don't adhere to MIME CRLF rules (like HTTP). I think actual practice
ignores this whole issue anyway and simply does not reset the G0
designation at all. I recently spoke with Mark Crispin about his
implementation, and he does not do such resets.
Regards,
Glenn
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:37 EDT