[Top] [All Lists]

Re: IETF-822 Extensions draft (fwd)

1992-01-21 00:37:07
From: kyuho(_at_)cosmos(_dot_)kaist(_dot_)ac(_dot_)kr (Kyuho Kim)
To: internet-drafts(_at_)nri(_dot_)reston(_dot_)va(_dot_)us, 
Subject: Re: IETF-822 Extensions draft
Date: Tue, 21 Jan 92 15:36:47 KST

Thank you for everybody who commented to my message.
I read the specification , though I was late. :-)
I havn't a member of IETF discussion, so if I miss something, please
let me know.

My impression is that you promote common style of ISO-2022 encoding method
prohibiting the use of locking shifts(SI/SO/LS1/LS2). I agree with you. 
Then why don't you adopt the mechanism like Compound Text which is more 
strict form of ISO-2022 to avoid the confusion like this. It's for information 
exchange and clean definition. It doesn't allow locking shifts as far as I know.
You may devise a mechanism like CT(7-bits version of CT) and register the 
charset(or encoding methods)
as something like "ISO-2022-MIME".  You may explicitly list the codesets
which is registered with IANA.

In summary, IETF needs to generalize ISO-2022 encoding methods 
from ISO-2022-jp.  Refer the following paragraph.

[on page 64]
Appendix F -- ISO-2022-jp

    This appendix briefly describes the  existing  practice  for
    the  use  of  ISO-2022  in  Japanese electronic mail.   This
    description is for informational purposes only, and  is  not
    intended  to  guide  an  implementation  of ISO-2022-jp mail
    senders or readers. 
    Degination sequences ESC 2/8 4/2, ESC 2/8 4/10, ESC 2/4 4/0 and
    ESC 2/4 4/2 are allowed. No other designation sequences are allowed

As the paragraph says, ISO-2022-jp allows only ASCII and Japanese JIS
character sets. The implication is that there neee to be "ISO-2022-kr"
which allows Korean KS character sets. That's what you want to avoid.

7.1.1     The charset parameter
An initial list of predefined character  set  names  can  be
found at the end of this section.  Additional *character sets*
may be registered with IANA, although the standardization of
their  use requires the usual IAB review and approval.  

I need more clarification. What's meant by *character sets*?
Does it mean the encoding methods like ISO-2022-jp style encoding?
or code sets like JIS0208 or KSC5601?
If it means the former(encoding method), I propose to devise "ISO-2022-MIME".

The defined charset values are:
    ISO-2022-jp -- ISO-2022, as defined in  [ISO-2022]
        specifies  ways  of designating and accessing
        character sets, rather than, itself, being  a
        character set.  Its use in mail will probably
        be strongly desired by  communities  who  are
        already  using  it locally to handle multiple
        sets of characters and multi-byte characters.
        It  appears  necessary  to explicitly specify
        the ISO-2022 methods that will  be  permitted
        in  text  mail  so  as  to avoid the need for
        private agreements about, e.g., the  specific
        character  sets  being  used  in messages.  A
        specification corresponding to  the  existing
        practice of ISO-2022 use in Japan is included
        as Appendix F.

I propose to update document as follows:

      ISO-2022-MIME -- ISO-2022, as defined in  [ISO-2022]
          specifies  ways  of designating and accessing
          character sets, rather than, ...

  -- Kyuho

<Prev in Thread] Current Thread [Next in Thread>