[Mew-dist 3252] Re: [Q] Why I can't read message with some Subject.

[Kazu Yamamoto ( 山本和彦 )]

From: Hidenori Ohta / 太田英憲 <hidenori at example.com>
Subject: [Mew-dist 3251] Re: [Q] Why I can't read message with some Subject.
Date: Mon, 22 Dec 1997 21:47:49 +0900

> そんなことはありません。正しい encoding を行なえば、問題ないはずです。
> 但し、ISO-2022-JP に関していえば、B encoding を使用するのが無難だと思
> います。
> 理由:
> 1. ISO-2022-JP の RFC に書いてある。
> 2. 昔は (今も?) Q encoding を理解しない UA がたくさんいた。
> 3. B でも Q でも encode された文字列をそのまま読むのは困難。

Sigh. Why don't you guys contribute the current draft?

Quoted from ftp://ds.internic.net/internet-drafts/
draft-yamamoto-charset-iso-2022-jp-00.txt.

5.3 Header Extensions

    In a header or in MIME content headers where `encoded-word's are
    allowed, Japanese string (i.e. excluding CRLF) which consists of the
    four graphic character sets MUST be in the form defined in RFC
    2047[MIME].  For "charset", "ISO-2022-JP" (case-insensitive) SHOULD
    be specified.  ISO-2022-JP string MUST end with ASCII (see 'line-e').

    Message composers SHOULD use "B" encoding for ISO-2022-JP string,
    however, message viewers MUST be able to handle both "B" and "Q"
    encoding. 

    IMPLEMENTATION NOTE: It should be noted that these requirements
    above apply to any fields in MIME content headers.  For example, RFC
    2047 mechanism MUST be used to represent ISO-2022-JP string when
    embedded in Content-Description: content header in a part of a
    multipart.

    ISO-2022-JP string MUST NOT be embedded directly in a header nor in
    MIME content headers.  EUC-JP string and Shift_JIS string SHOULD NOT
    be inserted even if they are in the form defined in RFC 2047.

    The reason why ISO-2022-JP string and "B" encoding is recommended to
    embed Japanese string in header fields is that RFC 1468 defines so.
    For historical reasons, not many message viewers support EUC-JP,
    Shift_JIS, and "Q" encoding,

--Kazu