9
X 5810-3 : 2008
To: Dave Crocker <dcrocker@mordor.stanford.edu>
Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se
From: =・ISO-8859-1・Q・PatrikF=E4ltstr=F6m・= <paf@nada.kth.se>
Subject: Re: RFC-HDR care and feeding
From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
(=・iso-8859-8・b・7eXs+SDv4SDp7Oj08A==・=)
To: Greg Vaudreuil <gvaudre@NRI.Reston.VA.US> , Ned Freed
<ned@innosoft.com>, Keith Moore <moore@cs.utk.edu>
Subject: Test of new header generator
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
次の例は,構造化されたフィールド本体に現れる“encoded-word”を含むテキストがどのようであるか
を示す。“(”及び“)”が“comment”区切り子として認識されないから,“*text”として定義されるフィール
ドとは,規則が少し異なる。箇条5のa)を参照する。
次のそれぞれの例では,“*text”フィールド中に同じ並びが起こらない場合,“表示される”形式は,“符
号化された形式”と同一であることを除き,符号化語として取り扱われない。これは,次の例では符号化
語のそれぞれが,“(”又は“)”文字と隣接しているからである。
符号化形式 表示形式
(=・ISO-8859-1・Q・a・=) (a)
(=・ISO-8859-1・Q・a・= b) (a b)
“comment”中では,空白は,“encoded-word”と取り囲むテキストとの間に現れなければならない[箇
条5のb)]。しかし,空白は,“comment”を始める最初の“(”と“encoded-word”との間には必要でない。
(=・ISO-8859-1・Q・a・= =・ISO-8859-1・Q・b・=) (ab)
隣り合う“encoded-word”間の空白は表示されない。
(=・ISO-8859-1・Q・a・= =・ISO-8859-1・Q・b・=) (ab)
“encoded-word”間に複数のSPACEがあっても,表示の目的のためには無視される。
(=・ISO-8859-1・Q・a・=
=・ISO-8859-1・Q・b・=) (ab)
“encoded-word”間の任意の量の線形空白は,一つ以上のSPACEに後続されるCRLFを含んでいても,
表示の目的のためには無視される。
(=・ISO-8859-1・Q・ab・=) (a b)
――――― [JIS X 5810-3 pdf 11] ―――――
10
X 5810-3 : 2008
符号化されたテキストの部分内で表示されるSPACEを生じさせるため,SPACEは,“encoded-word”の
一部として符号化されなければならない。
(=・ISO-8859-1・Q・a・= =・ISO-8859-2・Q・b・=) (a b)
符号化されたテキストの二つの文字列の間に表示されるSPACEを生じさせるため,SPACEは,一つの
“encoded-word”の一部として符号化してもよい。
9 セキュリティへの考慮
セキュリティに関しては,この規格では規定しない。
――――― [JIS X 5810-3 pdf 12] ―――――
11
X 5810-3 : 2008
附属書A
(参考)
RFC 1522からの変更(順不同)
この附属書は,本体に関連する事柄を補足するものであって,規定の一部ではない。
RFC 1522からの変更は,次のとおりである。
a) “encoded-word”を使用するためにMIME-Versionが要求されないことを,明示的に宣言した。
b) 正確を期するため,“encoded-word”がRFC 822 parser.valuesへの“atom”のように見えなければならない
ということを説明する,“encoded-word”中のSPACE及びTABが許されないという,明示的な注記を
加えた。
c) 隣接する線形空白とともに符号化語がどのように表示されるかを示す,Olle Jarnefors(感謝!)から
の例を加えた。
d) FC 822で定義され,この規格で参照された用語を,明示的に列挙した。
e) roffの癖によって,結果のテキストにおいて1,2行及び幾つかの文字が消えてしまうという誤植を
訂正した。
f) RFC 822ヘッダ及びMIME本体部分ヘッダのいずれの“*text”フィールド中でも,パラメタ値として
でないことを除いて,符号化語は許されることを明確化した。
g) “encoded-word”の符号化された部分内で,コード切替えシーケンスを使うどんな文字集合に対して
も,ASCIIに戻すという要求を明確化した。
h) 注釈の中で,“encoded-word”が“(”及び“)”によって区切られているが,*text中ではそうではない(奇
妙だが)ことに関する注記を追加した。
i) =E9の後の末尾の“”が廃止された(1342の後には必要ない)Andre Pirardの例を修正した。
j) *ctext中の“(”及び“)”との隣接でない,注釈を区切る,直後の最初の“(”又は直前の最後の“)”が注釈を
区切る“encoded-word”が現れてもよいことを明確化した。
k) “B” “encoded-word”はいつでも“encoded-text”部分で4文字の倍数となることを説明する注記を加
えた。
l) 例の中で“=”についての注記を加えた。
m) “encoded-word”の処理は構文解析の後に行われ,そのために関連する幾つかのことを注記した。
n) 普通のRFC 822又はいわゆる“8 bitヘッダ”のどちらかと,RFC 1522との間の変換を期待すること
はできないことを明示的に宣言した。
o) “quoted-string”中の“encoded-word”が不正であることを明示的に宣言した。
――――― [JIS X 5810-3 pdf 13] ―――――
12
X 5810-3 : 2008
附属書B
(参考)
RFC 1521, 1522及び1590からの変更点
この附属書は,本体に関する事柄を補足するものであって,規定の一部ではない。
MIME関連のJIS X 5810規格群は,RFC 1521,1522及び1590の改正である。RFC 1521,1522及び1590
を熟知している人に便利なように,RFC 1521,1522及び1590からの変更点をこの附属書に要約する。そ
れ以前の履歴に関して,RFC 1521がその前の版のRFC 1341とどのように異なるかをRFC 1521のAppendix
Hが示している。
a) この規定は完全に再構成され,複数の規定に分割された。これは,参照原稿であるために必要とされ
る,この規定のプレーンテキスト版の品質を高めるために行われた。
b) IMEオブジェクトヘッダの全体構成を記述する拡張BNFが追加された。これは,文書化の変更だけ
で,根本的な構文は変わっていない。
c) IMEの七つのメディア型のための固有の拡張BNFは削除された。この拡張BNFは,不正確で,不
完全で,型独立の拡張BNFと矛盾していた。型独立の拡張BNFは既に多くのMIMEヘッダの構文を
完全に規定しているので,型固有の拡張BNFは,結局,完全に不要であり,かえって問題を起こした。
d) FC 1521,1522及び1590の多くの部分における非公式の用語であるASCIIの使用は,もっと固有の
“US-ASCII”という文字集合名に置き換えられた。
e) 主メディア下位型という非公式の概念を削除した。
f) 用語“オブジェクト”は,一貫性なしに用いられていた。この用語の定義は,関連の用語“本体”,“本
体部分”及び“実体”とともに明確化され,用法は適切に訂正された。
g) 境界マーカに先行するCRLFが,先行する本体部分ではなくマーカそのものの一部であることを明確
にするため,マルチパートメディア型のための拡張BNFは再整理された。
h) マルチパートオブジェクト内の本体部分は,境界パラメタ文字列で始まる行を含んではならないこと
を明確にするため,マルチパートメディア型を記述する普通文及び拡張BNFは変更された。
i) “message/partial”MIME実体を再組立する規則において,内部メッセージからとるために,ヘッダの一
覧に“Subject”が追加され,この点を明確にするため例が修正された。
j) “message/partial”素片化子は,行境界でのMIMEオブジェクトの分割だけに制限される。
k) pplication/postscript型の議論において,PostScript MIME実体の中でのbinaryデータの組込みによって
引き起こされる可能性のある相互運用可能性の問題についての警告をする追加の段落を加えた。
l) 次の二つの形式を明確にするために,Content-Typeヘッダフィールドのための基本構文規則に対して
明確化の注記を加えた。
Content-type: text/plain; charset=us-ascii (comment)
Content-type: text/plain; charset="us-ascii"
これらは,完全に等価である。
m) IME-Versionヘッダの議論から次の文を削除した。“しかし,適合ソフトウェアは,版番号を検査し,
認識できないMIME-Versionに遭遇したとき,利用者に少なくとも警告することが推奨される。”
n) “message/external-body”ではなく“application/external-body”とした誤植を修正した。
――――― [JIS X 5810-3 pdf 14] ―――――
13
X 5810-3 : 2008
o) 要件を明確にするため,文字集合の定義を再構成した。
p) “image/gif”メディア型の定義は,別文書に移した。この変更は,特許で保護された技術の標準化を管
理するIETF規則と矛盾が生じる可能性があるため,行われた。
q) “7 bit”及び“8 bit”の定義を厳しくしたので,はだかのCR及びLFは行終端列として使用されるだけと
した。この規格はまた,NUL文字を保存することをもはや要求しない。それは,MIMEを実世界の実
装と整合させる。
r) IMEにおける正準テキストの定義を厳しくしたため,行区切りはCRLF列で表現されなければなら
ない。CR文字及びLF文字は,この用法以外には許容されない。それに伴って,quoted-printable符号
化の定義が変更された。
s) quoted-printable符号化の定義は,quoted-printable符号化器が不適切に符号化されたデータをどう扱う
のが最もよいかについて,今では多くの推奨を含む。
t) “8 bit”又は“binary”データにカプセル化するメッセージ実体又はマルチパートで,“7 bit”,“8 bit”及び
“binary”の内容転送符号化の使用を明確にする普通文を加えた。
u) IME適合性の箇条において,最小限のMIME適合性に関する要件の一覧に“multipart/digest”のサポー
トを追加した。“message/rfc822”のサポートのための用件も,再帰構造を認識することの重要性を明確
にするために,強化された。
v) “message”のメディア下位型の様々な制限は,今ではメディア下位型ごとに完全に規定されている。
w) “message/rfc822”の定義は,“From”,“Subject”又は“Date”ヘッダの少なくとも一つが存在しなければな
らないことを示すように変更した。
x) 認識できないメディア下位型の“application/octet-stream”としての必す(須)処理は,型定義の節及び
適合性指針の両方において,もっと明示的に作成された。
y) ext/richtextを用いた例は,text/enrichedに変更された。
z) メディア下位型の拡張BNF定義は,IANA登録済みメディア下位型又は非標準の“X-”メディア下位型
のどちらかがContent-Typeヘッダフィールドで使わなければならないことを明らかにするために変更
された。
aa) 使用するために単に登録されるMIMEメディア型と,IETFによって標準化されるMIMEメディア型
とは,今ではMIME 拡張BNFにおいて区別される。
ab) 様々なMIME登録手続のすべてを広範囲に改正した。文字集合に関するIANA登録手続は,このJIS X
5810規格群に含まれない別の規格に移動した。
ac) FC 1521,1522及び1590が定義しているUS-ASCII文字集合及びISO-8859-X文字集合におけるエス
ケープ機構及びシフト機構の使用を明確にした。これらの機構は,これらの文字集合,及びそれらの
使用が定義されないときの影響と一緒に用いてはならない。
ad) essage/external-bodyのためのAFSアクセス型の定義を削除した。
ae) ultipart/alternativeとmessage/external-bodyとの組合せの処理には,今は特に言及していない。
af) essage/external-bodyに固有のセキュリティの課題は,今では細かく示されている。
――――― [JIS X 5810-3 pdf 15] ―――――
次のページ PDF 16
JIS X 5810-3:2008の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.110 : 情報通信ネットワーキング
JIS X 5810-3:2008の関連規格と引用規格一覧
- 規格番号
- 規格名称
- JISX5810-1:2008
- 多目的インターネットメール拡張(MIME)―第1部:インターネットメッセージ本体のフォーマット