RFC1428 日本語訳

Network Working Group                                       G. Vaudreuil
Request for Comments: 1428                                          CNRI
                                                           February 1993

コメントを求めるワーキンググループG.ボードルイの要求をネットワークでつないでください: 1428 CNRI1993年2月

                   Transition of Internet Mail from
                              Just-Send-8
                           to 8bit-SMTP/MIME

ただ8を送るのからの8ビット-SMTP/MIMEへのインターネットメールの変遷

Status of this Memo

このMemoの状態

   This RFC provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

このRFCはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

Abstract

要約

   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実現が送付8bit dataのために臨時のメカニズムを採用しました。 拡張SMTPにおいて、環境とこれらの臨時のメカニズムが共同利用するのは、望ましいです。 このドキュメントは非MIMEの8ビットのメッセージの現在の用法からMIMEまでのこの環境における問題と移行コストを最小にすることへのアプローチについて概説します。

1. Terminology

1. 用語

   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.

RFC821は7ビットの輸送を定義します。 SMTPメッセージに設定されたこのビットによる八重奏を受け取り次第高位のビットをきれいにしない輸送エージェントはこのドキュメントで透明な8ビットと呼ばれます。 一般的なSMTP Extensionsドキュメント[3]の実現と8ビットの拡大は八重奏のすべての8ビットを使用するのが8ビットのESMTPと呼ばれるというMIMEメッセージを通過する[4]について議定書の中で述べます。 8ビットのキャラクタを受け入れない拡張SMTPの実現は7ビットのESMTPと呼ばれます。 ゲートウェイは、メッセージの内容を変更するか、または変換するUserエージェント権威がある輸送エージェントになるように定義されます。

2. The Problem

2. 問題

   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

RFC821で定義されるSMTPはインターネットメールの発信を米国-ASCII[5]キャラクタに制限します。 インターネットが非イギリス人の通信員を含むようになったとき、米国-ASCIIを除いた文字の組で交信する必要性は、多くの業者とユーザが非ASCII文字の組を使用するためにSMTPかRFC822を広げるようにうながしました。 一般的なアプローチは8ビットのISO8859を使用するためにSMTPとRFC822を広げるために現在のRFC822/SMTPの上で7ビットの国家の異形にISO646文字の組を送ることです。

Vaudreuil                                                       [Page 1]

RFC 1428              Transition to 8bit-SMTP/MIME         February 1993

MIME1993年8ビット-SMTP/2月へのボードルイ[1ページ]RFC1428変遷

   character sets, and to use proprietary PC character sets.

文字の組の、そして、使用に独占である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.

3番目のアプローチは日本のメールに使用されます。 高位のビットがきれいにされている状態で、日本人のキャラクタは組の八重奏で代理をされます。 14ビットの文字の組と7ビットの文字の組を切り換えるのはメッセージの中にISO2022エスケープシーケンスによって示されます。

   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環境への変遷では、別の非従っているユーザが非従っている現在、ユーザによって送られたメールを読むことができるのは、重要です。 この既存の機能性は読みにくい基地-64でコード化されたテキストか8ビットのテキストから「誤り伝えられた」引用されるところで印刷可能な状態でコード化されたテキストまでの変換で減らされます。

   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.

現在非米国のASCIIメールに存在する数個のおもしろい非共同利用できるケースと8つのビット/MIMEへの変遷で現れそうないくつかの新しいものがあります。 以下に、変遷からパントマイムへのケースのリストがあります。 このメモで翻訳ゲートウェイの文脈の(4)の解決策だけについて議論します。

                \ Receiver
                  \    7bit     8bit          MIME/
             Sender \| only   | transparent | ESMTP
           ----------------------------------------
           7bit only |  (1)   |    (1)      | (1)
           ----------------------------------------
    8bit transparent |  (2)   |    (3)      | (4)
           ----------------------------------------
          MIME/ESMTP |  (5)   |    (5)      | (6)

\受信機7円の8ビットの噛み付いているMIME/送付者\| 唯一| 透明| ESMTP---------------------------------------- 7ビット専用| (1) | (1) | (1) ---------------------------------------- 8に透明な状態で噛み付きました。| (2) | (3) | (4) ---------------------------------------- MIME/ESMTP| (5) | (5) | (6)

   (1) 7Bit non-MIME sender to 7bit, MIME, or 8bit transparent receiver

7ビット、MIME、または8ビットの透明な受信機への(1) 7ビットの非MIME送付者

      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.

「バンド」外部の協定が送付者と受信機の間に存在するなら、これはvarient ISO646かISO2022文字の組移行を全国的にで変わりのない仕事に続けるでしょう。8bit/ESMTPゲートウェイへの7ビットはこのメッセージの内容を変更する必要はありません。

   (2) 8bit sender to 7bit non-MIME receiver

7ビットの非MIME受信機への(2) 8ビットの送付者

      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

受信機はデータの誤解をもたらすビットで剥取られた郵便配達人と見せるか、または印刷する間違った文字を受け取るでしょう。 送られた使用言語にどこを最も郵送してくださいか。

Vaudreuil                                                       [Page 2]

RFC 1428              Transition to 8bit-SMTP/MIME         February 1993

MIME1993年8ビット-SMTP/2月へのボードルイ[2ページ]RFC1428変遷

      characters are in the US-ASCII subset of ISO 8859 may be somewhat
      readable.

キャラクタはISOの米国-ASCII部分集合に、8859がいくらか読み込み可能であるかもしれないということです。

   (3) 8bit transparent sender to 8bit transparent receiver

8ビットの透明な受信機への(3) 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.

タグ付けなしで特定の文字の組を使用する「バンド」が送付者と受信機の間に存在しているという外部の協定であるなら、働くでしょう。

   (4) 8bit transparent sender to MIME/ESMTP conformant receiver

MIME/ESMTP conformant受信機への(4) 8ビットの透明な送付者

      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.

ウィル仕事は妥当なアップグレード経路がゲートウェイを通して、ゲートウェイによって挿入された示された文字の組タグが正しいか、そして、受信機であるなら送付者によって選ばれた文字の組をサポートします。 本件はこのメモの焦点です。

   (5) MIME/ESMTP sender to non-MIME 7bit receiver

(5) 非MIMEの7ビットの受信機へのMIME/ESMTP送付者

      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ビットを理解するかどうかを知ることができないので、送付者は-64が基づくか、引用されて印刷可能への受信機によって「誤り伝えられ」て、考えられるかもしれないテキストをコード化するでしょう。役に立つダウングレード経路にゲートウェイを提供するのにおいて、受信機の能力に関する何らかの知識がなければなりません。この場合明確に文字の組を特定できるとき、RFC1345で説明されたmenmonic MNEMコード化のようなテクニックは役立っているかもしれません。

   (6) MIME/ESMTP sender to MIME/ESMTP receiver

(6) MIME/ESMTP受信機へのMIME/ESMTP送付者

      Interoperability will be attained provided the receiver supports
      the character set chosen by the sender.

受信機が送付者によって選ばれた文字の組をサポートすると、相互運用性に達するでしょう。

3. Upgrade Path from 8bit Transparent to ESMTP/MIME

3. ESMTP/MIMEに透明な8ビットからのアップグレード経路

   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.

Extended SMTPを支持するためにアップグレードしたゲートウェイはMIMEに受け取られた8ビットのメッセージをアップグレードさせるかもしれません。 これは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バージョンヘッダーとコンテントタイプを加えることによって、ボディーを変換できます: サイトの文字の組が使用中のテキスト/平野サイトがただ一つの文字の組を使用するなら。

   An appropriate Content-Transfer-Encoding header line must be added to
   indicate any encoding that may be necessary.

どんな必要であるかもしれないコード化も示すために適切なContent転送コード化ヘッダー線を加えなければなりません。

Vaudreuil                                                       [Page 3]

RFC 1428              Transition to 8bit-SMTP/MIME         February 1993

MIME1993年8ビット-SMTP/2月へのボードルイ[3ページ]RFC1428変遷

    Example:

例:

       MIME-Version: 1.0
       Content-Type: Text/Plain; Charset = ISO-8859-1
       Content-Transfer-Encoding: 8bit

MIMEバージョン: 1.0コンテントタイプ: テキスト/平野。 CharsetはISO-8859-1の満足している転送コード化と等しいです: 8ビット

   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.

使用中の文字の組のどんな情報も利用可能でないなら、ゲートウェイは、「未知-8ビット」という文字の組を使用することによって、内容をアップグレードさせるはずです。 charsetパラメタの未知-8ビットの値は、メッセージで使用される文字の組に関するどんな信頼できる情報も利用可能であっただけではないのを示します。

   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にアップグレードしたなら、非米国のASCII文字を含むRFC822ヘッダーは、RFC1342のヘッダー符号化規則に従うためにアップグレードしなければなりません。 ゲートウェイはRFC1342の規則に従ってすべてのunstructeredヘッダーがRFC822「コメント」sと「句」sと同様にさばく「再-コード」がそうするべきです。 同等物が全くメッセージ本体のための「8ビット」のContent転送コード化値へのRFC1342にないので、「B」か「Q」のどちらかに応じて、方法をコード化しながら、すべての8ビットのヘッダーテキストを変えなければなりません。 一般に、ISO8859文字の組のために、「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.,

トレース情報は転向者節でドキュメントに追加されるべきです: または、「8へのrfc822に噛み付いた」、「64インチを基礎づけるrfc822、「rfc822、-、-、引用されて印刷可能である、」 例えば」

   Received: from dbc.mtview.ca.us by dbc.mtview.ca.us
             convert rfc822-to-8bit; Tue, 01 Sep 1992 01:18:00 -0700

受け取られている: dbc.mtview.ca.usごとに、rfc822から8ビットを変換してください。 火曜日、1992年9月1日01:18:00 -0700

Appendix - The "unknown-8bit" Character Set

付録--「未知-8ビット」の文字コード

   This section defines a "charset" parameter, for use in a MIME
   Content-Type field.

このセクションはMIMEコンテントタイプ分野での使用のための"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.

「未知-8ビット」と呼ばれる専用文字の組は、八重奏の系列にコード化された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

この文字の組はメール作曲家によって使用されることを意図しません。 メール作曲家が使用中の文字の組を知って、[1]の指定されるとしての文字の組値をそれに付けると思われます。

Vaudreuil                                                       [Page 4]

RFC 1428              Transition to 8bit-SMTP/MIME         February 1993

MIME1993年8ビット-SMTP/2月へのボードルイ[4ページ]RFC1428変遷

   amended by current Assigned Numbers documents [6].

現在のAssigned民数記ドキュメント[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.

「未知-8ビット」のラベルの使用は単にメール・ゲートウェイエージェントによって意図されます(バンドで出ている情報で意図している文字の組を決定できません)。

   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.

「未知-8ビット」の解釈はメール読者次第です。 そんなに多くの場合、人間のユーザが情報を解釈して、適切な文字の組かプリプロセッサを選ぶことができると思われます。

Acknowledgements

承認

   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.

このドキュメントはネッド・フリードと、ニール・ケーティンと、作者との廊下の会話として由来しました。 ジョナサンLaventhol、クレイグ・エバーハート、オッレJarnefors、およびOlafurグドムンソンから実質的な入力を受け取りました。 ドキュメントはIETF SMTP Extensions作業部会における、多くの関係者の入力で洗練されました。

References

参照

   [1] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
       Extensions", RFC 1341, Bellcore, Innosoft, June 1992.

[1] Borenstein、N.と解放されたN.、「マルチパーパスインターネットメールエクステンション」、RFC1341、Bellcore、Innosoft、1992年6月。

   [2] Moore, K., "Representation of Non-ASCII Text in Internet Message
       Headers", RFC 1342, University of Tennessee, June 1992.

[2] ムーア、K.、「インターネットメッセージヘッダーの非ASCIIテキストの表現」、RFC1342、テネシー大学、1992年6月。

   [3] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
       E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United
       Nations University, Innosoft International, Inc., Dover Beach
       Consulting, Inc., Network Management Associates, Inc., The Branch
       Office, February 1993.

[3] Klensin、J.、WG議長、解放されています、N.とエディタとローズとM.とStefferud、E.とD.クロッカー、「SMTPサービス拡張子」RFC1425、国連大学、Innosoftの国際Inc.、ドーヴァービーチコンサルティングInc.、ネットワークマネージメントはInc.を関連づけます、支店、1993年2月。

   [4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
       E., and D. Crocker, "SMTP Service Extensions for 8bit
       MIMEtransport", RFC 1426, United Nations University, Innosoft
       International, Inc., Dover Beach Consulting, Inc., Network
       Management Associates, Inc., The Branch Office, February 1993.

[4] WG議長、解放されたKlensin、J.、N.、エディタ、ローズ、M.、Stefferud、E.、およびD.クロッカー、「8ビットのMIMEtransportのためのSMTPサービス拡張子」、RFC1426、国連大学、Innosoftの国際Inc.、ドーヴァービーチコンサルティングInc.、ネットワークマネージメントはInc.を関連づけます、支店、1993年2月。

   [5] Coded Character Set--7-Bit American Standard Code for Information
       Interchange, ANSI X3.4-1986.

[5]コード化文字集合--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。

   [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.

[6] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Vaudreuil                                                       [Page 5]

RFC 1428              Transition to 8bit-SMTP/MIME         February 1993

MIME1993年8ビット-SMTP/2月へのボードルイ[5ページ]RFC1428変遷

Author's Address

作者のアドレス

   Greg Vaudreuil
   Corporation for National Research Initiatives
   1895 Preston White Drive, Suite 100
   Reston, VA 22091 USA

国家の研究イニシアチブ1895のプレストンの白いドライブのためのグレッグボードルイ社、Suite100レストン、ヴァージニア22091米国

   Phone: (703) 620-8990
   EMail: GVaudre@CNRI.Reston.VA.US

以下に電話をしてください。 (703) 620-8990 メールしてください: GVaudre@CNRI.Reston.VA.US

Vaudreuil                                                       [Page 6]

ボードルイ[6ページ]