RFC1496 日本語訳

Network Working Group                                      H. Alvestrand
Request for Comments: 1496                                  SINTEF DELAB
Updates: 1328                                               J. Romaguera
                                                           NetConsult AG
                                                               K. Jordan
                                              Control Data Systems, Inc.
                                                             August 1993

Alvestrandがコメントのために要求するワーキンググループH.をネットワークでつないでください: 1496のSINTEF DELABアップデート: 1328 J.Romaguera NetConsult株式会社K.ジョーダン制御データシステムInc.1993年8月

     Rules for Downgrading Messages from X.400/88 to X.400/84 When
             MIME Content-Types are Present in the Messages

X.400/88からX.400/84 When MIMEコンテントタイプまでのDowngrading Messagesのための規則はMessagesのPresentです。

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.  Basic approach .............................................    2
   3.  Conversion rules ...........................................    3
   3.1  EBP conversions to Basic ..................................    3
   3.2  Encapsulation format ......................................    3
   4.  Implications ...............................................    4
   5.  Security Considerations ....................................    4
   6.  Authors' Addresses .........................................    4
   7.  References .................................................    5

1. 序論… 1 2. 基本的なアプローチ… 2 3. 変換規則… 3 3.1 BasicへのEBP変換… 3 3.2 カプセル化形式… 3 4. 含意… 4 5. セキュリティ問題… 4 6. 作者のアドレス… 4 7. 参照… 5

1. Introduction

1. 序論

   Interworking between X.400(88) and MIME is achieved by [4], which
   complements RFC-1327 [2], which in turn specifies the interworking
   between X.400(88) and RFC-822 based mail.

X.400(88)とMIMEの間の織り込むことは[4]によって達成されます。([4]はRFC-1327[2]の補足となります)。(順番に、RFC-1327はX.400(88)とRFC-822のベースのメールの間の織り込むことを指定します)。

   Interworking between X.400(88) and X.400 (84) is achieved by RFC-1328
   [3]. That document does not describe what to do in the case where
   body parts arrive at the gateway that cannot be adequately
   represented in the X.400(84) system.

X.400(88)とX.400(84)の間の織り込むことはRFC-1328[3]によって達成されます。 そのドキュメントは、身体の部分がX.400(84)システムで適切に表すことができないゲートウェイに到着する場合で何をしたらよいかを説明しません。

   This document describes how RFC-1328 must be modified in order to
   provide adequate support for the scenarios:

このドキュメントはシナリオの適切なサポートを提供するようにどうRFC-1328を変更しなければならないかを説明します:

      SMTP(MIME) -> X.400(84)

SMTP(MIME)->X.400(84)

      X.400(84) -> SMTP(MIME)

X.400(84)->SMTP(MIME)

Alvestrand, Romaguera & Jordan                                  [Page 1]

RFC 1496                        HARPOON                      August 1993

Alvestrand、Romaguera、およびジョーダン[1ページ]RFC1496は1993年8月にもりを打ち込ませます。

   It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is NOT
   obsoleted.

それはRFC-1328の支部6に取って代わります。 RFC-1328の残りは時代遅れにされません。

   NOTE: A desireable side-effect of HARPOON is that a standardized
   method for the identification and transmission of multimedia and
   binary data (like spreadsheets) between X.400/84 UAs is achieved.

以下に注意してください。 HARPOONの「望-可能」副作用はX.400/84 UAsの間のマルチメディアと2進のデータ(スプレッドシートのような)の識別と伝達のための標準化法が達成されるということです。

   While this method is not compatible with current proprietary
   approaches, we believe that it requires less invasive changes to
   current UAs than other possible methods.

この方法は現在の独占アプローチと互換性がない間、私たちが、それが現在のUAsへの侵略的な変化より他の可能な方法を必要とすると信じています。

   This memo updates RFC 1328.  HARPOON is a pure name, and has no
   meaning.  Please send comments to the MIME-MHS mailing list
   <mime-mhs@surnet.nl>.

このメモはRFC1328をアップデートします。 HARPOONは純粋な名前であり、意味を持っていません。 MIME-MHS郵送 list <mime-mhs@surnet.nl にコメントを送ってください、gt。

2.  Basic approach

2. 基本的なアプローチ

   The approach is to imagine that the connection X.400(84) <->
   SMTP(MIME) never happens. This, of course, is an illusion, but can be
   a very useful illusion.

アプローチは接続X.400(84)<->SMTP(MIME)が決して起こらないと想像することです。 これは、もちろん幻想ですが、非常に役に立つ幻想であるかもしれません。

   All mail will therefore go on one of the paths

したがって、すべてのメールが経路の1つに続くでしょう。

      X.400(84) -> X.400(88) -> SMTP(MIME)

X.400(84)->X.400(88)->SMTP(MIME)

      SMTP(MIME) -> X.400(88) -> X.400(84)

SMTP(MIME)->X.400(88)->X.400(84)

   when it goes between a MIME user and an X.400(84) user.

MIMEユーザとX.400(84)ユーザを取り持つと。

   The approach at the interface between X.400(88) and X.400(84) is:

X.400(88)とX.400(84)とのインタフェースでのアプローチは以下の通りです。

      o  Convert what you can

o あなたが変換できることを変換してください。

      o  Encapsulate what you have to

o あなたがそうしなければならないものを要約してください。

      o  Never drop a message

o メッセージを決して落とさないでください。

   Of course, for X.400/88 body parts that are already defined in
   X.400/84, no downgrading should be done. In particular, multi-body
   messages should remain multi-body messages, IA5 messages including
   IA5 messages encoded as Extended Body Parts) should remain IA5
   messages, and G3Fax messages should remain G3Fax messages.

もちろん、X.400/84で既に定義されるX.400/88身体の部分に関して格下げするべきでないこと。 メッセージがそうするべきであるマルチボディー残りマルチボディーメッセージ、特にExtendedボディ・パーツとしてコード化されたIA5メッセージを含むIA5メッセージ) IA5メッセージのままで残るべきであり、G3FaxメッセージはG3Faxメッセージのままで残るべきです。

Alvestrand, Romaguera & Jordan                                  [Page 2]

RFC 1496                        HARPOON                      August 1993

Alvestrand、Romaguera、およびジョーダン[2ページ]RFC1496は1993年8月にもりを打ち込ませます。

3.  Conversion rules

3. 変換規則

3.1.  EBP conversions to Basic

3.1. BasicへのEBP変換

   Some body parts are defined by X.400(88) as having both a Basic form
   and an Extended form. These are listed in Annex B of X.420.

いくつかの身体の部分がX.400(88)によってBasicフォームとExtendedの両方が形成させられると定義されます。 これらはX.420のAnnex Bに記載されています。

   For all of these, the transformation from the Extended Body Part to
   the Basic Body Part takes the form of putting the PARAMETERS and the
   DATA members together in a SEQUENCE.

これらのすべてのために、Extended Body PartからBasic Body Partまでの変化はSEQUENCEでPARAMETERSとDATAメンバーを組み立てる形を取ります。

   This transformation should be applied by the gateway in order to
   allow (for example) X.400(88) systems that use the Extended form of
   the IA5 body part to communicate with X.400(84) systems.

この変化は、(例えば、)IA5身体の部分のExtendedフォームを使用するX.400(88)システムがX.400(84)システムとコミュニケートするのを許容するためにゲートウェイによって適用されるべきです。

3.2.  Encapsulation format

3.2. カプセル化形式

   For any body part that cannot be used directly in X.400(84), the
   following IA5Text body part is made:

直接X.400(84)で使用できない少しの身体の部分においても、以下のIA5Text身体の部分は作られています:

   -  Content = IA5String

- 内容はIA5Stringと等しいです。

   -  First bytes of content: (the description is in USASCII, with C
      escape sequences used to represent control characters):

- 最初に、バイトの内容: (記述がCエスケープシーケンスが制御文字を表すのに使用されているUSASCIIにあります):

       MIME-version: <version>\r\n
           Content-type: <the proper MIME content type>\r\n
         Content-transfer-encoding: <quoted-printable or base64>\r\n
         <Possibly other Content headings here, terminated by\r\n>
         \r\n

MIMEバージョン: <バージョン>\r\n文書内容: 適切なMIMEが満足させる<は>\r\n Content転送コード化をタイプします: 引用されて印刷可能な<かbase64>\r\n<Possiblyもう一方Content、ここの見出し、n>円rの\nのときに\r\終わります。

      <Here follows the bytes of the content, as per [4], encoded in the
      proper encoding>

ここの<は適切なコード化>でコード化された[4]に従って内容のバイトに続きます。

   All implementations MUST place the MIME-version: header first in the
   body part. Headers that are placed by [2] and [4] into other parts of
   the message MUST NOT be placed in the MIME body part.

すべての実現がMIMEバージョンを置かなければなりません: 最初に、身体の部分のヘッダー。 [2]と[4]によってメッセージの他の部分に置かれるヘッダーをMIME身体の部分に置いてはいけません。

   This includes RFC-822 headings carried as heading-extensions, which
   must be placed in a new IA5 body part starting with the string "RFC-
   822-HEADERS", as specified in [2], Appendix G.

これはストリング「RFCの822ヘッダー」から始まる新しいIA5身体の部分に置かなければならない見出し拡張子として運ばれたRFC-822見出しを含んでいます、[2]で指定されるように、付録G。

   Other heading-extensions are still handled as described in chapter 5
   of RFC 1328: They are dropped.

他の見出し拡張子はRFC1328の支部5で説明されるようにまだ扱われています: それらは落とされます。

   Since all X.400(88) body parts can be represented in MIME by using
   the x400-bp MIME content-type, this conversion will never fail.

MIMEでx400-bpのMIMEの満足しているタイプを使用することによってすべてのX.400(88)身体の部分を表すことができるので、この変換は決して失敗しないでしょう。

Alvestrand, Romaguera & Jordan                                  [Page 3]

RFC 1496                        HARPOON                      August 1993

Alvestrand、Romaguera、およびジョーダン[3ページ]RFC1496は1993年8月にもりを打ち込ませます。

   In the reverse direction, any IA5 body part that starts with the
   token "MIME-Version:" will be subjected to conversion according to
   [4] before including the body part into an X.400(88) message.

反対の方向、象徴から始まるどんなIA5身体の部分、も「MIMEバージョン:」 X.400(88)メッセージに身体の部分を含める前に、[4]によると、変換にかけられるでしょう。

4.  Implications

4. 含意

   The implications are several:

含意は数個です:

   - People with X.400(84) readers who have the ability to save messages
     to file will now be able to save MIME multimedia messages

- ファイルするメッセージを保存する能力を持っているX.400(84)読者と一緒にいる人々は現在、MIMEマルチメディアメッセージを保存できるでしょう。

   - People who can use features like the "Mailcaps" file to identify
     what to do about a bodypart can now grab implementations of MIME
     that can run as subprograms and achieve at least some multimedia
     functionality

- bodypartの周りで何をしたらよいかを特定するのに「Mailcaps」ファイルのような特徴を使用できる人々は、現在、副プログラムとして走ることができるMIMEの実現をつかんで、少なくとも何らかのマルチメディアの機能性を達成できます。

5.  Security Considerations

5. セキュリティ問題

   The security considerations in [1] and [4] (beware of trojans that
   can hit you if your UA automagically starts programs for you) are now
   relevant also for X.400(84) systems.

X.400(84)システムにおいても、[1]と[4](あなたのUA automagicallyがあなたのためにプログラムを始動するならあなたに当ることができるtrojansに注意する)のセキュリティ問題は現在、関連しています。

6.  Authors' Addresses

6. 作者のアドレス

   Harald Tveit Alvestrand
   SINTEF DELAB
   N-7034 Trondheim
   NORWAY

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

   EMail: Harald.T.Alvestrand@delab.sintef.no

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

   Kevin E. Jordan, ARH215
   Control Data Systems, Inc.
   4201 Lexington Avenue N
   Arden Hills, MN  55126
   USA

ケビン・E.ジョーダン、ARH215コントロールデータシステムズInc.4201レキシントンアベニューNアーデンの森丘、MN55126米国

   EMail: Kevin.E.Jordan@mercury.oss.arh.cpg.cdc.com

メール: Kevin.E.Jordan@mercury.oss.arh.cpg.cdc.com

   James A. Romaguera
   NetConsult AG
   Mettlendwaldweg 20a
   3037 Herrenschwanden
   Switzerland

ジェームスA.Romaguera NetConsult株式会社Mettlendwaldweg 20a3037Herrenschwandenスイス

   EMail: Romaguera@netconsult.ch

メール: Romaguera@netconsult.ch

Alvestrand, Romaguera & Jordan                                  [Page 4]

RFC 1496                        HARPOON                      August 1993

Alvestrand、Romaguera、およびジョーダン[4ページ]RFC1496は1993年8月にもりを打ち込ませます。

7.  References

7. 参照

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

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

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

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

   [3]  Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading", RFC
        1328, University College London, May 1992.

[3]Hardcastle-Kille、S.、「X.400 1988年から1984格下げ」、RFC1328、ユニバーシティ・カレッジロンドン1992年5月。

   [4]  Alvestrand, H., Kille, S., Miles, R., Rose, M., and S. Thompson,
        "Mapping between X.400 and RFC-822 Message Bodies", RFC 1494,
        SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc, Dover Beach
        Consulting, Inc., Soft*Switch, Inc., August 1993.

[4] Alvestrand、H.、Kille、S.、マイル、R.、ローズ、M.、およびS.トンプソンRFC1494、SINTEF DELAB、ISODE共同体、柔らかい*「X.400とRFC-822メッセージの間でボディーを写像し」て、は切り替わります、Inc、ドーヴァービーチコンサルティングInc.、柔らかい*スイッチInc.、1993年8月。

Alvestrand, Romaguera & Jordan                                  [Page 5]

Alvestrand、Romaguera、およびジョーダン[5ページ]