This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、 Internet 社会に情報を提供します。いかなる種類の Internet 標準を規定するものでもありません。このメモの配布は制限しません。
Protocols for extending SMTP to pass 8bit characters have been defined [3] [4] . These protocols require that messages transported by the extended SMTP are to be encoded in MIME [1] [2] . Before work began on these protocols, several SMTP implementations adopted ad-hoc mechanisms for sending 8bit data. It is desirable for the extended SMTP environment and these ad hoc mechanisms interoperate. This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME.
8ビット文字を通過させるように SMTP を拡張するプロトコルが定義されています [3] [4]。 これらのプロトコルでは、拡張 SMTP で転送されるメッセージが MIME [1] [2] で符号化されていることが必要です。これらのプロトコルの作業が始まる以前、幾つかの SMTP 実装は8ビット・データを送信するための特設機構を採用していました。拡張 SMTP 環境とこの様な特設機構が協調して働くことが望ましいです。この文書は、これらの環境での問題と、非 MIME 8ビット・メッセージの現在の利用法から MIME への変換の経費の最小化の方法について概説します。
RFC 821 defines a 7bit transport. A transport agent which does not clear the high order bit upon receipt of octets with this bit set in SMTP messages is called 8 bit transparent in this document. An implementation of the general SMTP Extensions document [3] and the 8bit extensions protocol [4] which passes MIME messages using all 8 bits of an octet is called 8bit ESMTP. An implementation of extended SMTP which does not accept 8bit characters is called 7bit ESMTP. A gateway is defined to be a transport agent with User Agent authority to alter or convert the content of a message.
RFC 821 は8ビット転送を定義しています。 SMTP メッセージ中の受け取ったオクテットの最上位ビットを、このビットに値を設定することで消去しない転送代理者を、この文書では8ビット透過と呼びます。一般 SMTP 拡張文書 [3] 及び MIME メッセージをオクテットの8ビット全てを使って渡す8ビット拡張プロトコル [4] の実装を8ビット ESMTP と呼びます。8ビット文字を受け付けない拡張 SMTP の実装を7ビット ESMTP と呼びます。関門 (gateway) は、メッセージの内容を変える・変換する利用者代理者当局つき転送代理者と定義します。
SMTP as defined in RFC 821 limits the sending of Internet Mail to US-ASCII [5] characters. As the Internet has grown to include non-English correspondents, the need to communicate with character sets other than US-ASCII has prompted many vendors and users to extend SMTP or RFC 822 to use non-ASCII character sets. Common approaches are to send 7 bit national variant ISO 646 character sets over current RFC822/SMTP, to extend SMTP and RFC822 to use 8bit ISO 8859 character sets, and to use proprietary PC character sets.
RFC 821 で定義された SMTP は Internet メイルの送信を US-ASCII [5] 文字に制限していました。 Internet が非英語文通者を含む様に成長するに従い、非 US-ASCII 文字集合による意思疎通の必要性から、多くの製造者や利用者が SMTP や RFC 822 を非 ASCII 文字集合を使用するように拡張しようとしました。その共通の手段には7ビットの国家版 ISO 646 文字集合を現行の RFC 822/SMTP で送信する, SMTP と RFC822 を8ビットの ISO 8859 文字集合を使用するように拡張する, 独占 PC 文字集合を使用する, があります。
A third approach is used for Japanese mail. Japanese characters are represented by pairs of octets with the high order bit cleared. Switching between 14 bit character sets and 7 bit character sets is indicated within the message by ISO 2022 escape sequences.
三番目の方法は日本語メイルに使われています。日本語文字は最上位ビットが消去されたオクテットの組合せで表現します。14ビット文字集合と7ビット文字集合はメッセージ中では ISO 2022 エスケープ列で切り替えます。
三番目の方法とは「独占 PC 文字集合の使用」ですから、この説明では合致しません。おそらく、三番目の方法は、「一番目・二番目以外の方法」とでもしたかったのでしょう。
So long as these implementations can communicate without intermediate transformations and have a loose private agreement on the use of a specific character set without tagging, basic mail service can be provided.
これらの実装は途中経路での変形無しに通信出来、特定文字集合の札無しでの使用の緩い私的な合意があるので、基本的なメイル・サービスが提供出来ます。
In the transition to the negotiated 8bit ESMTP/MIME environment, it is important that mail sent by a currently non-conforming user can be read by another non-conforming user. This existing functionality is reduced by conversion from 8bit text to text encoded in unreadable Base-64 or "garbled" text encoded in quoted printable.
折衝8ビット ESMTP/MIME 環境への変換で、現在非適合の利用者が送信したメイルは他の非適合の利用者が読むことが出来ることは重要です。この既存機能性は、8ビット文から不可読 Base-64 で符号化された文や quoted printable で符号化された「文字化けした」文に変換することで減少します。
There are several interesting non-interoperable cases that currently exist in non US-ASCII mail and several new ones likely to emerge in a transition to 8bit/MIME. Below is a listing of the transition-to-mime cases. Only solutions to (4) in the context of a translating gateway are discussed in this memo.
現在非 US-ASCII メイルに存在する興味深い相互通信不可な事例、あるいは8ビット/MIME への変換で浮上しそうな新しい事例が幾つかあります。下に挙げるのは、 MIME への変換の事例です。変換関門における (4) の解決策のみをこのメモでは取り上げます。
7Bit non-MIME sender to 7bit, MIME, or 8bit transparent receiver
7ビット非 MIME 送信者から7ビットまたは MIME, 8ビット透過受信者へ
This will continue to work unchanged with nationally varient ISO 646 or ISO 2022 character set shifting if an external "out of band" agreement exists between the sender and the receiver. A 7bit to 8bit/ESMTP gateway need not alter the content of this message.
ISO 646 国家版や ISO 2022 文字集合転移を、外部「out of band」合意が送受信者間で存在する場合は変更無く運用し続けます。7ビットから8ビット/SMTP への関門はこのメッセージの内容を変える必要はありません。
Jargon File には、 「out of band」 =
“sometimes
used to describe what communications people call ‘shift characters’,
such as the
と書かれています。ESC that leads control sequences for
many terminals”
8bit sender to 7bit non-MIME receiver
8ビット送信者から7ビット非 MIME 受信者へ
The receiver will receive bit-stripped mail which results in the mis-interpretation of the data and the wrong character being displayed or printed. Mail sent using languages where most characters are in the US-ASCII subset of ISO 8859 may be somewhat readable.
受信者は、データの誤解釈の結果たるビット落ちメイルを受け取り、間違った文字が表示・印刷されることになるでしょう。ほとんどの文字が ISO 8859 の US-ASCII 部分集合中にある言語を使って送られたメイルはそれなりに読めるかもしれません。
8bit transparent sender to 8bit transparent receiver
8ビット透過送信者から8ビット透過受信者へ
Will work if an external agreement "out of band" to use a particular character set without tagging exists between the sender and the receiver.
特定文字集合を札無しで使用する外部合意「out of band」が送受信間に存在する場合はうまく働くでしょう。
8bit transparent sender to MIME/ESMTP conformant receiver
8ビット透過送信者から MIME/ESMTP 適合受信者へ
Will work if a reasonable upgrade path is provided via gateways, the indicated character set tag inserted by the gateway is correct and the receiver supports the character set chosen by the sender. This case is the focus of this memo.
分別ある格上げ経路が関門経由で提供されていて、関門が挿入する文字集合札が正しくて、受信者が送信者の選んだ文字集合に対応していれば、うまく働きましょう。この場合がこのメモの焦点です。
MIME/ESMTP sender to non-MIME 7bit receiver
MIME/ESMTP 送信者から非 MIME 7ビット受信者へ
Because the ESMTP/MIME sender cannot know if the receiver will understand 8bits, the sender will encode the text into base-64 or quoted-printable which may be considered "garbled" by the receiver. To provide a useful downgrade path the gateway must have some knowledge about the capabilities of the receiver. When the character set can be clearly identified, techniques like the menmonic MNEM encoding described in RFC 1345 may be helpful in this case.
ESMTP/MIME 送信者は受信者が8ビットを理解するかどうか知り得ないので、送信者は文を base-64 か受信者に「文字化けした」と思われるかもしれない quoted-printable で符号化するでしょう。有用な格下げ経路を提供するには関門は受信者の理解能力についての知識を有する必要があります。文字集合が明確に識別出来る時は、 RFC 1345 で説明されている記法 MNEM 符号化の様な手法がこの場合には有用かもしれません。
MIME/ESMTP sender to MIME/ESMTP receiver
MIME/ESMTP 送信者から MIME/ESMTP 受信者へ
Interoperability will be attained provided the receiver supports the character set chosen by the sender.
相互通信性は送信者が選択した文字集合に受信者が対応することにより満たされます。
A gateway which has been upgraded to support Extended SMTP may upgrade an 8bit message received to MIME. This is consistent with the requirement that all 8bit mail sent by ESMTP be encoded in MIME. The upgrade should be done using the best available information.
拡張 SMTP に対応するよう格上げする関門は、受信した8ビット・メッセージを MIME に格上げして構いません。これは ESMTP で送信される8ビット・メイルは全て MIME で符号化されていなければならないという要件を満たします。格上げは一番利用可能な情報を使って行うべきです。
A site may "upgrade" to MIME en-masse by implementing MIME conversion for all messages leaving the site. For text messages, the body can be converted by adding a MIME-version header and a Content-Type: Text/Plain with the character set in use in the site, provided the site uses a single character set.
サイトは、サイトを離れる全てのメッセージを、 MIME を実装することでまとめて MIME に「格上げ」しても構いません。テキスト・メッセージについては、本体は MIME-version 頭と Content-Type: Text/Plain にサイト内で使われている文字集合をつけることで、サイトが単一文字集合を使っている場合は変換出来ます。
An appropriate Content-Transfer-Encoding header line must be added to indicate any encoding that may be necessary.
適切な Content-Transfer-Encoding 頭行を、必要かもしれない符号化を示すのに加えなければなりません。
MIME-Version: 1.0 Content-Type: Text/Plain; Charset = ISO-8859-1 Content-Transfer-Encoding: 8bit
If no information about the character set in use is available, the gateway should upgrade the content by using the character set "unknown-8bit". The unknown-8bit value of the charset parameter indicates only that no reliable information about the character set(s) used in the message was available.
使用されている文字集合についての情報が無い場合は、関門は内容を文字集合 "unknown-8bit" を使って格上げするべきです。 charset パラメーターの unknown-8bit 値はメッセージに使われている文字集合についての確実な情報を得ることが出来なかったことのみを示します。
If a message body has been upgraded to MIME, the RFC 822 headers containing non US-ASCII characters must be upgraded to conform with the header encoding rules of RFC1342. A gateway should recode all unstructered header fields as well as RFC 822 "comment"s and "phrase"s according to the rules of RFC 1342. There is no equivalent in RFC 1342 to the "8bit" Content-Transfer-Encoding value for message bodies so all 8bit header text must be transformed according to either the "B" or the "Q" encoding method. For ISO 8859 character sets, the "Q" encoding will generally result in somewhat readable headers.
メッセージ本体が MIME に格上げされる場合、非 US-ASCII 文字を含む RFC 822 頭は RFC1342 の頭符号化規則に適合するようしなければなりません。関門は全ての非構造化頭領域と RFC 822 "comment" と "phrase" を RFC 1342 の規則に従い再符号化するべきです。メッセージ本体の "8bit" 内容転送符号化値に相当するものは RFC 1342 には無いので、全ての8ビット頭文は "B" 符号化方式または "Q" 符号化方式で符号化しなければなりません。 ISO 8859 文字集合には、 "Q" 符号化を使うと、通常やや可読な頭となります。
Trace information should be added to the document with a convert clause: "rfc822-to-8bit", "rfc822-to-base-64" or "rfc822-to-quoted- printable" e.g.,
追跡情報を次の例のように変換 (convert) 条項 "rfc822-to-8bit", "rfc822-to-base-64", "rfc822-to-quoted-printable" つきで文書に追加するべきです。
Received: from dbc.mtview.ca.us by dbc.mtview.ca.us
convert rfc822-to-8bit; Tue, 01 Sep 1992 01:18:00 -0700
This section defines a "charset" parameter, for use in a MIME Content-Type field.
この節では MIME Content-Type 領域で使う "charset" パラメーターを定義します。
A special purpose character set called "unknown-8bit" is defined to be an unknown 8bit character set, encoded into a sequence of octets. It can be used as a label for any character set from any language, using any encoding. It must not be further defined.
"unknown-8bit" という特殊目的文字集合を、オクテット列に符号化された未知の8ビット文字集合用に定義します。これはいかなる言語でいかなる符号化を用いるいかなる文字集合にも札として使うことが出来ます。これ以上は定義しません。
The use of this token in a "charset=" field of a message indicates that nothing is known about the character set used. This marker is intended for use by non-MIME to MIME gateways; specifically in those which translate from SMTP to 8bit ESMTP/MIME.
この字句をメッセージの "charset=" 領域で使うことで、使われている文字集合について全くもって不明であることを示します。この印は非 MIME から MIME への関門、具体的には SMTP から8ビット ESMTP/MIME に変換する関門で使うことを意図しています。
This character set is not intended to be used by mail composers. It is assumed that the mail composer knows the character set in use and will mark it with a character set value as specified in [1] , as amended by current Assigned Numbers documents [6] .
この文字集合はメイル作成者が使うことは意図していません。メイル作成者は使用する文字集合を知っていて、 [1] で規定されて現行の割当番号文書 [6] で改訂された文字集合値で印をつけると想定しています。
The use of the "unknown-8bit" label is intended only by mail gateway agents which cannot determine via out-of-band information the intended character set.
"unknown-8bit" 札の使用は、 out of band 情報により意図された文字集合を決定出来ないメイル関門代理者によりのみ使われることを想定しています。
The interpretation of the "unknown-8bit" is up to the mail reader. It is assumed that in many cases the human user will be able to interpret the information and choose an appropriate character set or pre-processor.
"unknown-8bit" の解釈はメイル・リーダーに委ねられます。多くの場合では人間利用者が情報を解釈して適切な文字集合あるいは前処理器を選択できると思われます。
This document originated as a hallway conversation between Ned Freed, Neil Katin, and the author. Substantive input was received from Jonathan Laventhol, Craig Everhart, Olle Jarnefors, and Olafur Gudmundsson. The document was refined with the input of many participants in the IETF SMTP Extensions Working Group.
この文書は Ned Freed, Neil Katin と著者の井戸端会議から生まれました。 Jonathan Laventhol, Craig Everhart, Olle Jarnefors, Olafur Gudmundsson が魂を吹き込んでくれました。この文書は IETF SMTP 拡張作業部会の参加者の意見により精錬されました。
Security issues are not discussed in this memo.
安全性問題はこのメモでは取り扱っていません。
この翻訳文は、自由に複製・配布・改変して構いません。 (rfc-copyright-story も参照して下さい。)