RFC1495 日本語訳

Network Working Group                                      H. Alvestrand
Request for Comments: 1495                                  SINTEF DELAB
Updates: 1327                                                   S. Kille
                                                        ISODE Consortium
                                                                R. Miles
                                                       Soft*Switch, Inc.
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                             S. Thompson
                                                       Soft*Switch, Inc.
                                                             August 1993

Alvestrandがコメントのために要求するワーキンググループH.をネットワークでつないでください: 1495のSINTEF DELABアップデート: 1327秒間*柔らかいスイッチS.トンプソン*スイッチInc.Inc.M.バラドーヴァービーチコンサルティングInc.1993年8月に柔らかいKille ISODE共同体R.マイル

            Mapping between X.400 and RFC-822 Message Bodies

X.400とRFC-822メッセージの間でボディーを写像します。

Status of this Memo

このMemoの状態

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。

Table of Contents

目次

   1.  Introduction .............................................    1
   2.  Approach .................................................    2
   3.  Mapping between X.400 and RFC-822 Message Bodies .........    3
   3.1  Mapping from X.400 to RFC-822 ...........................    4
   3.2  Mapping from RFC-822 to X.400 ...........................    5
   3.2.1 Asymmetric Mappings ....................................    6
   3.2.1.1 Message/External-Body ................................    6
   3.2.1.2 Message/Partial ......................................    6
   3.2.1.3 Nested Multipart Content-types .......................    6
   3.2.2 Multipart IPMS Heading Extension .......................    7
   4.  Mapping between X.400 and RFC-822 Message Headers ........    7
   5.  OID Assignments ..........................................    9
   6.  Security Considerations ..................................    9
   7.  Authors' Addresses .......................................   10
   8.  References ...............................................   11

1. 序論… 1 2. アプローチしてください… 2 3. X.400とRFC-822メッセージボディーの間で写像します。 3 3.1 X.400からRFC-822まで写像します。 4 3.2 RFC-822からX.400まで写像します。 5 3.2 .1の非対称のマッピング… 6 3.2 .1 .1 外部のメッセージ/ボディー… 6 3.2 .1 .2 メッセージ/部分的… 6 3.2 .1 .3 複合文書内容を入れ子にします… 6 3.2 .2 複合IPMS見出し拡張子… 7 4. X.400とRFC-822メッセージヘッダーの間で写像します。 7 5. OID課題… 9 6. セキュリティ問題… 9 7. 作者のアドレス… 10 8. 参照… 11

1.  Introduction

1. 序論

   The Internet community is a large collection of networks under
   autonomous administration, but sharing a core set of protocols.
   These are known as the Internet suite of protocols (or simply
   "TCP/IP").

インターネットコミュニティは自治の管理の下におけるネットワークの大きい収集ですが、共有は1人の巻き癖のプロトコルです。 これらはプロトコル(または、単に「TCP/IP」)のインターネットスイートとして知られています。

   Use of electronic-mail in the Internet is defined primarily by one

インターネットでの電子メールの使用は主として1時までに定義されます。

Alvestrand, Kille, Miles, Rose & Thompson                       [Page 1]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993

Alvestrand、Kille、マイル、ローズ、およびトンプソン[1ページ]RFC1495MHS/RFC-822メッセージボディーマッピング1993年8月

   document, STD-11, RFC-822 [1], which defines the standard format for
   the exchange of messages.  RFC-822 has proven immensely popular; in
   fact, the 822-connected Internet, is larger than the scope of the
   IP-connected Internet.

ドキュメント、STD-11、メッセージの交換のために標準書式を定義するRFC-822[1]。 RFC-822は、非常にポピュラーであると判明しました。 事実上、822で接続されたインターネットはIPによって接続されたインターネットの範囲より大きいです。

   The framework provided by RFC-822 allows for memo-based textual
   messages.  Each message consists of two parts:  the headers and the
   body.  The headers are analogous to the structured fields found in an
   inter-office memo, whilst the body is free-form.  Both parts are
   encoded using ASCII.

RFC-822によって提供された枠組みはメモベースの原文のメッセージを考慮します。 各メッセージは2つの部品から成ります: ヘッダーとボディー。 ヘッダーは相互事務連絡用メモで見つけられた構造化された分野に類似していますが、ボディーは自由形式です。 両方の部品は、ASCIIを使用することでコード化されます。

   Recently, the Internet Engineering Task Force (IETF) has developed an
   document called,

最近、インターネット・エンジニアリング・タスク・フォース(IETF)は呼ばれるドキュメントを開発しました。

      Multipurpose Internet Mail Extensions

マルチパーパスインターネットメールエクステンション

   or MIME RFC-1341.  The title is actually misleading.  MIME defines
   structure for Internet message bodies.  It is not an extension to
   RFC-822.

または、RFC-1341をまねてください。 タイトルは実際に紛らわしいです。 MIMEはインターネットメッセージ本体のために構造を定義します。 それはRFC-822への拡大ではありません。

   Independently of this, the International standards community
   developed a different framework in 1984 (some say that's the
   problem).  This framework is known as the OSI Message Handling System
   (MHS) or sometimes X.400.

これの如何にかかわらず、国際規格共同体は1984年に異なった枠組みを開発しました(或るものは、それが問題であると言います)。 この枠組みはOSI Message Handling System(MHS)か時々X.400として知られています。

   Since the introduction of X.400(84), there has been work ongoing for
   defining mappings between MHS and RFC-822.  The most recent work in
   this area is RFC-1327 [3], which focuses primarily on translation of
   envelope and headers.  This document is complimentary to RFC-1327 as
   it focuses on translation of the message body.  The mappings defined
   are largely symmetrical with respect to MIME and MHS structuring
   semantics, although the MIME semantics are somewhat richer.  In order
   to provide for reversible transformations, MHS heading extensions are
   used to carry the additional MIME semantics.

X.400(84)の導入以来、MHSとRFC-822の間には、マッピングを定義するのにおける、進行中の仕事があります。 この領域での最新の仕事はRFC-1327[3]です。(そのRFC-1327は主として封筒とヘッダーに関する翻訳に焦点を合わせます)。 メッセージ本体に関する翻訳に焦点を合わせるとき、このドキュメントはRFC-1327に賞賛です。 定義されたマッピングは主に意味論を構造化するMIMEとMHSに関して対称です、MIME意味論はいくらか豊かですが。 可逆的な変換に備えて、MHS見出し拡張子は、追加MIME意味論を運ぶのに使用されます。

   Please send comments to the MIME-MHS mailing list:
   <mime-mhs@surfnet.nl>.

MIME-MHSメーリングリストにコメントを送ってください: mhs@surfnet.nlをまねている<>。

2.  Approach

2. アプローチ

   The mappings have been specifically designed to provide optimal
   behavior for three different scenarios:

マッピングは3つの異なったシナリオのための最適の振舞いを提供するように明確に設計されています:

   (1) Allow a MIME user and an MHS user to exchange an arbitrary binary
       content;

(1) MIMEユーザとMHSユーザに任意の2進の内容を交換させてください。

   (2) Allow MIME content-types to "tunnel" through an MHS relay that
       is, two MIME users can exchange content-types without loss

(2) MIMEの満足しているタイプがMHSリレーで「トンネルを堀ること」を許容してください、そして、すなわち、2人のMIMEユーザが損失なしで満足しているタイプを交換できます。

Alvestrand, Kille, Miles, Rose & Thompson                       [Page 2]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993

Alvestrand、Kille、マイル、ローズ、およびトンプソン[2ページ]RFC1495MHS/RFC-822メッセージボディーマッピング1993年8月

       through an MHS relay); and,

通じて、MHSリレー)、。 そして

   (3) Allow MHS body parts to "tunnel" through a MIME relay that is,
       two MHS users can exchange body parts without loss through a MIME
       relay).

(3) MIMEリレーでMHS身体の部分がすなわち、缶の交換ボディーがMIMEリレーによる損失なしで離れさせる2人のMHSユーザに「トンネルを堀ること」を許容してください、)

   Other, related, scenarios can also be easily accommodated.

また、容易に他の、そして、関連するシナリオに対応できます。

   To facilitate the mapping process, the Internet Assigned Numbers
   Authority (IANA) maintains a table termed the "IANA MHS/MIME
   Equivalence Table".  Once an enterprise has registered an OID to
   describe an MHS body part, it should complete a corresponding
   registry with the IANA for a MIME content-type/subtype.  In practice,
   the corresponding content-type will be "application", with an
   appropriate choice of sub-type and possible parameters.  If a new
   MIME content-type/subtype is registered with the IANA without a
   corresponding entry in the Equivalence Table, the IANA will assign it
   an OID, from the arc defined in this memo. See [4], section 5 for
   details.

マッピング処理を容易にするために、インターネットAssigned民数記Authority(IANA)は「IANA MHS/MIME等価性テーブル」と呼ばれたテーブルを維持します。 企業がMHS身体の部分について説明するためにいったんOIDを登録すると、それはMIMEの満足しているタイプ/「副-タイプ」のためにIANAと共に対応する登録を完成するべきです。 実際には、サブタイプの、そして、可能なパラメタの適当な選択で対応する満足しているタイプは「アプリケーション」でしょう。 新しいMIME満足しているタイプ/「副-タイプ」がEquivalence Tableに対応するエントリーなしでIANAに登録されると、IANAはOIDをそれに割り当てるでしょう、このメモで定義されたアークから。 詳細に関して[4]、セクション5を見てください。

   The companion document, "Equivalences between 1988 X.400 and RFC-822
   Message Bodies"[4], defines the initial configuration of this table.
   The mappings described in both this document and the companion
   document use the notational conventions of RFC-1327.

仲間ドキュメント(「1988X.400とRFC-822メッセージボディーの間の等価性」[4])はこのテーブルの初期の構成を定義します。 このドキュメントと仲間ドキュメントの両方で説明されたマッピングはRFC-1327の記号法のコンベンションを使用します。

3.  Mapping between X.400 and RFC-822 Message Bodies

3. X.400とRFC-822メッセージの間でボディーを写像します。

   MHS messages are comprised of an IPMS.heading and an IPMS.body.  The
   IPMS.Body is a sequence of IPMS.BodyParts.  An IPMS.BodyPart may be a
   nested message (IPMS.MessageBodyPart).

MHSメッセージはIPMS.headingとIPMS.bodyから成ります。 IPMS.BodyはIPMS.BodyPartsの系列です。 IPMS.BodyPartは入れ子にされたメッセージであるかもしれません(IPMS.MessageBodyPart)。

   A MIME message consists of headers and a content.  For the purpose of
   discussion, the content may be structured (multipart or message), or
   atomic (otherwise).  An element of a structured content may be a
   message or a content.  Both message and structured content have
   subtypes which do not have direct analogies in MHS.

MIMEメッセージはヘッダーと内容から成ります。 議論の目的のために、内容が構造化されるかもしれない、(複合、または、原子(そうでなければ)のメッセージ。 構造化された内容の要素は、メッセージか内容であるかもしれません。 メッセージと構造化された内容の両方には、血液型亜型があります(MHSにダイレクト類推を持っていません)。

   The mapping between X.400 and RFC-822 message bodies which this
   document defines is symmetrical for the following cases:

以下のケースにおいて、X.400とこのドキュメントが定義するRFC-822メッセージボディーの間のマッピングは対称です:

          (1) any atomic body part

(1) どんな原子身体の部分

          (2) multipart: digest and mixed subtypes

(2)複合: ダイジェストと複雑な血液型亜型

          (3) message/rfc822

(3) メッセージ/rfc822

   RFC-1327 specifies the mappings for headers.  Section 4 describes how
   those mappings are modified by this document.  When mapping between

RFC-1327はヘッダーにマッピングを指定します。 セクション4はそれらのマッピングがこのドキュメントによってどう変更されるかを説明します。 間に写像します。

Alvestrand, Kille, Miles, Rose & Thompson                       [Page 3]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993

Alvestrand、Kille、マイル、ローズ、およびトンプソン[3ページ]RFC1495MHS/RFC-822メッセージボディーマッピング1993年8月

   an MHS body and a MIME content, the following algorithm is used:

MHSボディーであり、MIME内容であり以下のアルゴリズムは使用されています:

3.1.  Mapping from X.400 to RFC-822

3.1. X.400からRFC-822までのマッピング

   This section replaces the text in RFC-1327 starting at the bottom of
   page 84,

84ページの下部で始まって、このセクションはRFC-1327でテキストを置き換えます。

       The IPMS.Body is mapped into the RFC-822 message body.  Each
       IPMS.BodyPart is converted to ASCII as follows:

IPMS.BodyはRFC-822メッセージボディーに写像されます。 各IPMS.BodyPartは以下のASCIIに変換されます:

   and continuing up to and including page 86 of Section 5.3.4 of RFC-
   1327.

そして、.4セクション5.3RFC1327の86ページを含めて続くこと。

             If the IPMS.Body

IPMS.Bodyです。

                  Body ::=
                      SEQUENCE OF
                          BodyPart

以下を具体化させてください:= BodyPartの系列

   consists of a single body part, then the RFC-822 message body is
   constructed as the MIME content corresponding to that body part.

成る、そして、ただ一つの身体の部分では、RFC-822メッセージボディーがその身体の部分に対応するMIME内容として組み立てられます。

   If the body part is an IPMS.MessageBodyPart (forwarded IPM), the
   mapping is applied recursively.  Otherwise, to map a specific MHS
   body part to a MIME content-type, the IANA MHS/MIME Equivalence table
   is consulted.  If the MHS body part is not identified in this table,
   then the body-part is mapped onto an "application/x400-bp" content,
   as specified in [4].

身体の部分がIPMS.MessageBodyPart(IPMを進める)であるなら、マッピングは再帰的に適用されます。 さもなければ、特定のMHS身体の部分をMIMEの満足しているタイプに写像するために、IANA MHS/MIME Equivalenceテーブルは相談されます。 MHS身体の部分がこのテーブルで特定されないなら、身体部分は「アプリケーション/x400-bp」内容に写像されます、[4]で指定されるように。

   If the IPMS.Body consists of more than one body part, then the RFC-
   822 message body is constructed as a

IPMS.Bodyが1つ以上の身体の部分から成るなら、RFC822メッセージボディーはaとして組み立てられます。

          multipart/mixed

複合か混ぜられます。

   content-type, unless all of the body parts are messages, in which
   case it is mapped to a

満足しているタイプ、身体の部分のすべてがメッセージでないなら、その場合、それはaに写像されます。

          multipart/digest

複合/ダイジェスト

   content-type.  Each component of the multipart content-type
   corresponds to a IPMS.BodyPart, preserving the ordering of the body
   parts in the IPMS.Body.

内容でタイプしてください。 IPMS.Bodyでの身体の部分の注文を保存して、複合満足しているタイプの各成分はIPMS.BodyPartに対応しています。

   There is one case which gets special treatement.  If the IPMS.Body
   consists solely of a single IA5Text body part, then the RFC822
   message body is NOT marked as a MIME content.  This prevents RFC822
   mailers from invoking MIME function unnecessarily.

特別なtreatementを手に入れる1つのケースがあります。 IPMS.Bodyが唯一ただ一つのIA5Text身体の部分から成るなら、RFC822メッセージボディーはMIME内容としてマークされません。 これによって、RFC822郵送者は不必要にMIME機能を呼び出すことができません。

Alvestrand, Kille, Miles, Rose & Thompson                       [Page 4]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993

Alvestrand、Kille、マイル、ローズ、およびトンプソン[4ページ]RFC1495MHS/RFC-822メッセージボディーマッピング1993年8月

3.2.  Mapping from RFC-822 to X.400

3.2. RFC-822からX.400までのマッピング

   First, replace the first paragraph of Section 5.1.3 on page 72 of
   RFC-1327 to read as:

まず最初に、以下と読むために72RFC-1327ページの上のセクション5.1.3の第一節を取り替えてください。

       The IPM (IPMS Service Request) is generated according to the
       rules of this section.  The IPMS.body usually consists of one
       IPMS.BodyPart of type

このセクションの規則に従って、IPM(IPMS Service Request)は発生します。 通常、IPMS.bodyはタイプの1IPMS.BodyPartから成ります。

                           IPMS.IA5TextBodyPart

IPMS.IA5TextBodyPart

                      with
                           IPMS.IA5TextBodyPart.parameters.repertoire

IPMS.IA5TextBodyPart.parameters.repertoireと共に

       set to the default (ia5), which contains the body of the RFC-822
       message.  However, if the 822.MIME-Version header field is
       present, a special algorithm is used to generate the IPMS.body.

デフォルト(ia5)にセットしてください。(それは、RFC-822メッセージのボディーを含みます)。 しかしながら、822.MIME-バージョンヘッダーフィールドが存在しているなら、特別なアルゴリズムは、IPMS.bodyを発生させるのに使用されます。

       Second, replace the "Comments:" paragraph on page 74 to reads as:

2番目、取り替え、「コメント:」 読書への74ページの以下としてのパラグラフ

       Comments:

コメント:

          If an 822.MIME-Version header field is not present,
          generate an IPMS.Bodypart of type

822.MIME-バージョンヘッダーフィールドが存在していないなら、タイプのIPMS.Bodypartを発生させてください。

              IPMS.IA5TextBodyPart

IPMS.IA5TextBodyPart

          with

with

              IPMS.IA5TextBodyPart.parameters.repertoire

IPMS.IA5TextBodyPart.parameters.repertoire

          set to the default (ia5), containing the value of
          the fields, preceded by the string "Comments: ".
          This body part shall preceed the other one.

分野の値を含んでいて、デフォルト(ia5)に設定されて、先行されて、ストリングは「以下について論評します」。 ". 部分がそうするものとするこのボディーはもう片方をpreceedしました。

   Third, add the remainder of this section to the end of Section 5.1.3
   of RFC-1327.

3番目に、.3セクション5.1RFC-1327の終わりにこのセクションの残りを加えてください。

   If the 822.MIME-Version header field is present, the following
   mapping rules are used to generate the IPMS.body.

822.MIME-バージョンヘッダーフィールドが存在しているなら、以下の配置規則は、IPMS.bodyを発生させるのに使用されます。

   If the MIME content-type is one of:

MIMEの満足しているタイプであるなら、以下が1つがあります。

   (1)  any atomic body part

(1) どんな原子身体の部分

   (2)  multipart: digest and mixed subtypes

(2)複合: ダイジェストと複雑な血液型亜型

Alvestrand, Kille, Miles, Rose & Thompson                       [Page 5]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993

Alvestrand、Kille、マイル、ローズ、およびトンプソン[5ページ]RFC1495MHS/RFC-822メッセージボディーマッピング1993年8月

   (3)  message/rfc822

(3) メッセージ/rfc822

   then the symmetric mapping applies as described in Section 6.1.  Note
   that the multipart content-types should be marked with the
   IPMS.HeadingExtension described below.

そして、左右対称のマッピングはセクション6.1で説明されるように適用されます。 IPMS.HeadingExtensionが以下で説明されている状態で複合満足しているタイプがマークされるべきであることに注意してください。

   Otherwise, three cases remain, which are discussed in turn.

さもなければ、3つのケース(順番に議論する)が残っています。

3.2.1.  Asymmetric Mappings

3.2.1. 非対称のマッピング

3.2.1.1.  Message/External-Body

3.2.1.1. 外部のメッセージ/ボディー

   This is mapped into a mime-body-part, as specified in [4].

これは[4]で指定されるようにパントマイム身体の部分に写像されます。

3.2.1.2.  Message/Partial

3.2.1.2. メッセージ/部分的です。

   This is mapped onto a message, and the following heading extension is
   used.  The extension is derived from the message/partial parameters:

これはメッセージに写像されます、そして、以下の見出し拡張子は使用されています。 メッセージ/部分的なパラメタから拡大を得ます:

                  partial-message  HEADING-EXTENSION
                      VALUE PartialMessage
                      ::= id-hex-partial-message

部分的なメッセージHEADING-EXTENSION VALUE PartialMessage:、:= イドの十六進法の部分的なメッセージ

                  PartialMessage ::=
                      SEQUENCE {
                          number INTEGER,
                          total  INTEGER,
                          id     IA5String
                      }

PartialMessage:、:= 系列数のINTEGER、総INTEGER、イドIA5String

   If this heading is present when mapping from MHS to MIME, then a
   message/partial should be generated.

MHSから次に、MIME、メッセージ/まで部分的なマッピングが発生するべきであるとき、この見出しが存在しているなら。

3.2.1.3.  Nested Multipart Content-types

3.2.1.3. 入れ子にされた複合文書内容

   In MIME, a multipart content refers to a set of content-types, not a
   message with a set of content-types. However, a nested multipart
   content will always be mapped to an IPMS.MessageBodyPart, with an
   IPMS.BodyPart for each contained content-type.

MIMEでは、1セットの満足しているタイプで複合内容はメッセージではなく、1セットの満足しているタイプについて言及します。 しかしながら、入れ子にされた複合内容はそれぞれの含まれた満足しているタイプのためにIPMS.BodyPartと共にIPMS.MessageBodyPartにいつも写像されるでしょう。

   The only mandatory field in the heading is the IPMS.this-IPM, which
   must always be generated (by the gateway). A IPMS.subject field
   should also be generated where there is no "real" heading. This will
   present useful information to the non-MIME capable X.400(88) and to
   all X.400(84) UAs.

見出しにおける唯一の義務的な分野がIPMS.this-IPMです。(そのIPMS.this-IPMはいつも発生しなければなりません(ゲートウェイのそばで))。 また、IPMS.subject分野は「本当」の見出しが全くないところで発生するべきです。 これは非MIMEのできるX.400(88)と、そして、すべてのX.400(84) UAsに役に立つ情報を提示するでしょう。

Alvestrand, Kille, Miles, Rose & Thompson                       [Page 6]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993

Alvestrand、Kille、マイル、ローズ、およびトンプソン[6ページ]RFC1495MHS/RFC-822メッセージボディーマッピング1993年8月

   The IPM.subject fields for the various types are:

様々なタイプのためのIPM.subject分野は以下の通りです。

   mixed:        "Multipart Message"
   alternative:  "Alternate Body Parts containing the same information"
   digest:       "Message Digest"
   parallel:     "Body Parts to be interpreted in parallel"

混ぜられる: 「複合Message」代替手段: 「同じ情報を含む交互のボディ・パーツ」は読みこなされます: 「メッセージDigest」は以下に沿います。 「平行で解釈されるべきボディ・パーツ」

3.2.2.  Multipart IPMS Heading Extension

3.2.2. 複合IPMS見出し拡張子

   The following IPMS.HeadingExtension should be generated for all
   multipart content-types, with the enumerated value set according to
   the subtype:

「副-タイプ」に応じて、以下のIPMS.HeadingExtensionはすべての複合満足しているタイプのために列挙された選択値群で発生するべきです:

                  multipart-message HEADING-EXTENSION
                      VALUE MultipartType
                      ::= id-hex-multipart-message

複合メッセージHEADING-EXTENSION VALUE MultipartType:、:= イドの十六進法の複合メッセージ

                  MultipartType ::=
                      ENUMERATED {
                          mixed(1),
                          alternative(2),
                          digest(3),
                          parallel(4)
                      }

MultipartType:、:= 列挙されます。混ぜられて、(1)(代替手段(2))は(3)を読みこなして、平行は(4)です。

   If this heading is present when mapping from MHS to MIME, then the
   appropriate multipart content-type should be generated.

MHSからMIMEまで写像するとき、この見出しが存在しているなら、適切な複合満足しているタイプは発生するべきです。

4.  Mapping between X.400 and RFC-822 Message Headers

4. X.400とRFC-822メッセージの間でヘッダーを写像します。

   Replace the first paragraph of Section 3.3.4 on page 26 of RFC-1327
   to read as:
        In cases where T.61 strings are used only for conveying human-
        interpreted information, the aim of this mapping is to render
        the characters appropriately in the remote character set, rather
        than to maximize reversibility.  For these cases, the following
        steps are followed to find an appropriate encoding:

以下と読むために26RFC-1327ページの上のセクション3.3.4の第一節を取り替えてください。 T.61ストリングが人間の解釈された情報を伝えるのにだけ使用される場合では、このマッピングの目的はリバーシブルを最大にするというよりむしろ適切にキャラクタをリモート文字の組にすることです。 これらのケースにおいて、以下の方法は適切なコード化を見つけるために従われています:

        1) If all the characters in the string are contained within the
        ASCII repertoire, the string is simply copied.

1) ストリングのすべてのキャラクタがASCIIレパートリーの中に含まれているなら、ストリングは単にコピーされます。

        2) If all the characters in the string are from an IANA-
        registered character set, then the appropriate encoded-word(s)
        according to [5] are generated instead.

2) ストリングのすべてのキャラクタがIANAの登録された文字の組から来ているなら、[5]に従った適切なコード化された単語は代わりに発生します。

        3) If the characters in the string are from a character set
        which is not registered with the IANA, then the mappings to IA5
        defined in CCITT Recommendation X.408 (1988) shall be used

3) ストリングのキャラクタがIANAに登録されない文字の組から来ているなら、CCITT Recommendation X.408(1988)で定義されたIA5へのマッピングは使用されるものとします。

Alvestrand, Kille, Miles, Rose & Thompson                       [Page 7]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993

Alvestrand、Kille、マイル、ローズ、およびトンプソン[7ページ]RFC1495MHS/RFC-822メッセージボディーマッピング1993年8月

        [CCITT/ISO88a].  These will then be encoded in ASCII.

[CCITT/ISO88a。] そして、これらはASCIIでコード化されるでしょう。

        This approach will only be used for human-readable information
        (Subject and FreeForm Name).

このアプローチは人間が読める情報(対象とFreeForm Name)に使用されるだけでしょう。

        When mapping from an RFC-822 header, when an encoded-word (as
        defined in [5]) is encountered:

コード化された単語であるときに、RFC-822ヘッダーから写像する、(中で定義されるように、[5])は遭遇します:

        1) If all the characters contained therein are mappable to T.61,
        the string content shall be converted into T.61.

1) そこに含まれたすべてのキャラクタがT.61にmappableであるなら、ストリング含有量はT.61に変換されるものとします。

        2) Otherwise, the encoded-word shall be copied directly into the
        T.61 string.

2) さもなければ、コード化された単語は直接T.61ストリングにコピーされるものとします。

   Modify procedure "2a" on page 56 of RFC-1327 to read as:
        If the IPMS.ORDescriptor.free-form-name is present, convert it
        to ASCII or T.61 (Section 3.3.4), and use this as the 822.phrase
        component of the 822.mailbox construct.

以下と読むように56RFC-1327ページの手順"2a"を変更してください。 IPMS.ORDescriptor.freeフォーム名が存在しているなら、ASCIIかT.61(セクション3.3.4)にそれを変換してください、そして、822.mailbox構造物の822.phraseの部品としてこれを使用してください。

   Modify the final paragraph of procedure "2" on page 55 of RFC-1327 to
   read as:
        The string is then encoded into T.61 or ASCII using a human-
        oriented mapping (as described in Section 3.3.4).  If the string
        is not null, it is assigned to IPMS.ORDescriptor.free-form.name.

「以下と読む55RFC-1327ページの上の2インチ」という手順の最終節を変更してください。 そして、人間の指向のマッピングを使用することで(セクション3.3.4で説明されるように)ストリングはT.61かASCIIにコード化されます。 ストリングがヌルでないなら、それはIPMS.ORDescriptor.free-form.nameに割り当てられます。

   Modify the second paragraph of procedure "3" on page 55 of RFC-1327
   to read as:
        If the 822.group construct is present, any included 822.mailbox
        is encoded as above to generate a separate IPMS.ORDescriptor.
        The 822.group is mapped to T.61 or ASCII (as described in
        Section 3.3.4), and an IPMS.ORDescriptor with only an free-
        form-name component is built from it.

「以下と読む55RFC-1327ページの上の3インチ」という手順の第2パラグラフを変更してください。 822.group構造物が存在しているなら、どんな含まれている822.mailboxも、別々のIPMS.ORDescriptorを発生させるように同じくらい上でコード化されます。 822.groupはT.61かASCIIに写像されます、そして、(セクション3.3.4で説明されるように)無料のフォーム名のコンポーネントだけがあるIPMS.ORDescriptorはそれから造られます。

   Modify procedure "822.Subject" on page 62 of RFC-1327 to read as:

以下と読むように62RFC-1327ページの手順"822.Subject"を変更してください。

        Mapped to IMPS.Heading.subject.  The field-body uses the human-
        oriented mapping referenceed in Section 3.3.4.

IMPS.Heading.subjectに写像されます。 分野本体はセクション3.3.4でreferenceedされた人間の指向のマッピングを使用します。

   Modify procedure "IPMS.Heading.subject" on page 71 of RFC-1327 to
   read as:
        Mapped to "Subject:".  The contents are converted to ASCII or
        T.61 (Section 3.3.4).  Any CRLF are not mapped, but are used as
        points at which the subject field must be folded.

以下と読むように71RFC-1327ページの手順"IPMS.Heading.subject"を変更してください。 「Subject:」に写像されます。 内容はASCIIかT.61(セクション3.3.4)に変換されます。 どんなCRLFも写像されませんが、対象の分野を折り重ねなければならないポイントとして使用されます。

Alvestrand, Kille, Miles, Rose & Thompson                       [Page 8]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993

Alvestrand、Kille、マイル、ローズ、およびトンプソン[8ページ]RFC1495MHS/RFC-822メッセージボディーマッピング1993年8月

5.  OID Assignments

5. OID課題

   MIME-MHS DEFINITIONS ::= BEGIN

MIME-MHS定義:、:= 始まってください。

   mail OBJECT IDENTIFIER ::= { internet 7 }

OBJECT IDENTIFIERに郵送してください:、:= インターネット7

   mime-mhs OBJECT IDENTIFIER ::= { mail 1 }

パントマイム-mhs OBJECT IDENTIFIER:、:= メール1

   mime-mhs-headings OBJECT IDENTIFIER ::= { mime-mhs 1 }

パントマイムmhs見出しOBJECT IDENTIFIER:、:= パントマイム-mhs1

   id-hex-partial-message OBJECT IDENTIFIER ::=
           { mime-mhs-headings 1 }

イドの十六進法の部分的なメッセージOBJECT IDENTIFIER:、:= パントマイムmhs見出し1

   id-hex-multipart-message OBJECT IDENTIFIER ::=
           { mime-mhs-headings 2 }

イドの十六進法の複合メッセージOBJECT IDENTIFIER:、:= パントマイムmhs見出し2

   mime-mhs-bodies OBJECT IDENTIFIER ::= { mime-mhs 2 }

パントマイムmhsボディーOBJECT IDENTIFIER:、:= パントマイム-mhs2

   END

終わり

6.  Security Considerations

6. セキュリティ問題

   There are no explicit security provisions in this document.  However,
   a warning is in order.  This document maps two mechanisms between
   RFC822 and X.400 that could cause problems.  The first is the
   transfer of binary files.  The inherent risks are well known and
   won't be reiterated here.  The second is the propagation of strong
   content typing.  The typing can be used to automatically "launch" or
   initiate applications against those contents.  Any such launching
   leaves the invoker vulnerable to application-specific viruses; for
   example, a spreadsheet macro or Postscript command that deletes
   files.  See [2], Section 7.4.2 for a Postscript-specific discussion
   of this issue.

どんな明白なセキュリティ条項も本書ではありません。 しかしながら、警告は整然としています。 このドキュメントは問題を起こすことができたRFC822とX.400の間の2つのメカニズムを写像します。1番目はバイナリーファイルの転送です。 固有の危険は、よく知られて、ここで繰り返されないでしょう。 2番目は強い満足しているタイプの伝播です。 自動的にそれらの内容に対してアプリケーションを「始める」か、または開始するのにタイプを使用できます。 どんなそのような発射も呼び出し元をアプリケーション特有のウイルスに傷つきやすい状態でおきます。 例えば、それが削除するスプレッドシートマクロかPostscriptコマンドがファイルされます。 この問題のPostscript特有の議論に関して[2]、セクション7.4.2を見てください。

Alvestrand, Kille, Miles, Rose & Thompson                       [Page 9]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993

Alvestrand、Kille、マイル、ローズ、およびトンプソン[9ページ]RFC1495MHS/RFC-822メッセージボディーマッピング1993年8月

7.  Authors' Addresses

7. 作者のアドレス

   Harald Tveit Alvestrand
   SINTEF DELAB
   N-7034 Trondheim
   NORWAY

ハラルド・Tveit Alvestrand SINTEF DELAB N-7034トロンヘイムノルウェー

   EMail: Harald.Alvestrand@delab.sintef.no

メール: Harald.Alvestrand@delab.sintef.no

   Steve Kille
   ISODE Consortium
   P.O. Box 505
   London
   SW11 1DX
   England

スティーブKille ISODE共同体P.O. Box505ロンドンSW11 1DXイギリス

   Phone: +44-71-223-4062
   EMail: S.Kille@ISODE.COM

以下に電話をしてください。 +44-71-223-4062 メールしてください: S.Kille@ISODE.COM

   Robert S. Miles
   Soft*Switch, Inc.
   640 Lee Road
   Wayne, PA 19087

柔らかい*スイッチInc.640リー・Roadウェイン、ロバートS.Miles PA 19087

   Phone: (215) 640-7556
   EMail: rsm@spyder.ssw.com

以下に電話をしてください。 (215) 640-7556 メールしてください: rsm@spyder.ssw.com

   Marshall T. Rose
   Dover Beach Consulting, Inc.
   420 Whisman Court
   Mountain View, CA  94043-2186
   US

Inc.420Whisman法廷カリフォルニア94043-2186マウンテンビュー(米国)に相談するマーシャル・T.バラドーヴァービーチ

   Phone: +1 415 968 1052
   Fax:   +1 415 968 2510
   EMail: mrose@dbc.mtview.ca.us

以下に電話をしてください。 +1 415 968、1052Fax: +1 2510年の415 968メール: mrose@dbc.mtview.ca.us

   Steven J. Thompson
   Soft*Switch, Inc.
   640 Lee Road
   Wayne, PA 19087

スティーブン・J.トンプソン柔らかい*スイッチInc.640リー・Roadウェイン、PA 19087

   Phone: (215) 640-7556
   EMail: sjt@gateway.ssw.com

以下に電話をしてください。 (215) 640-7556 メールしてください: sjt@gateway.ssw.com

Alvestrand, Kille, Miles, Rose & Thompson                      [Page 10]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993

Alvestrand、Kille、マイル、ローズ、およびトンプソン[10ページ]RFC1495MHS/RFC-822メッセージボディーマッピング1993年8月

8.  References

8. 参照

   [1] Crocker, D., "Standard for the Format of ARPA Internet Text
       Messages", STD 11, RFC 822, UDEL, August 1982.

[1] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。

   [2] Borenstein, N., and N. Freed, "MIME: Mechanisms for Specifying
       and Describing the Format of Internet Message Bodies", RFC 1341,
       Bellcore, Innosoft, June 1992.

[2] Borenstein(N.、および解放されたN.)は「以下をまねます」。 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1341、Bellcore、Innosoft、1992年6月。

   [3] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
       and RFC-822", RFC 1327, University College London, May 1992.

[3] Hardcastle-Kille、S.、「X.400(1988)/ISO10021とRFC-822の間のマッピング」、RFC1327、ユニバーシティ・カレッジロンドンは1992がそうするかもしれません。

   [4] Alvestrand, H., and S. Thompson, "Equivalences between 1988 X.400
       and RFC-822 Message Bodies", RFC 1494, SINTEF DELAB, Soft*Switch,
       Inc., August 1993.

[4] Alvestrand、H.、およびS.トンプソン、「1988X.400とRFC-822メッセージボディーの間の等価性」、RFC1494、SINTEF DELAB、柔らかい*がInc.(1993年8月)を切り換えます。

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

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

Alvestrand, Kille, Miles, Rose & Thompson                      [Page 11]

Alvestrand、Kille、マイル、ローズ、およびトンプソン[11ページ]