RFC2157 日本語訳
2157 Mapping between X.400 and RFC-822/MIME Message Bodies. H.Alvestrand. January 1998. (Format: TXT=92554 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Alvestrand Request for Comments: 2157 UNINETT Category: Standards Track January 1998
Alvestrandがコメントのために要求するワーキンググループH.をネットワークでつないでください: 2157年のUNINETTカテゴリ: 標準化過程1998年1月
Mapping between X.400 and RFC-822/MIME Message Bodies
X.400とRFC-822/MIMEメッセージの間でボディーを写像します。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Table of Contents
目次
1 Introduction ........................................... 2
1.1 Glossary ............................................. 3
2 Basic rules for body part conversion ................... 4
2.1 Generating the IPM Body from MIME .................... 5
2.2 Generating the MIME Body from the IPMS.Body .......... 6
2.3 Mapping the EMA FTBP parameters ...................... 7
2.3.1 Mapping GraphicStrings ............................. 7
2.3.2 Mapping specific parameters ........................ 7
2.3.3 Summary of FTBP elements generated ................. 10
2.4 Information that is lost when mapping ................ 11
3 Encapsulation of body parts ............................ 11
3.1 Encapsulation of MIME in X.400 ....................... 12
3.1.1 FTBP encapsulating body part ....................... 12
3.1.2 BP15 encapsulating body part ....................... 13
3.1.3 Encapsulation using IA5 (HARPOON) .................. 15
3.1.4 Content passing using BP14 ......................... 16
3.2 Encapsulating X.400 Body Parts in MIME ............... 16
3.3 Encapsulating FTBP body parts in MIME ................ 17
4 User control over the gateway choice ................... 18
4.1 Conversion from MIME to X.400 ........................ 18
4.2 Conversion from X.400 to MIME ........................ 20
5 The equivalence registry ............................... 21
5.1 What information one must give about a mapping
..................................................... 21
5.2 Equivalence summary for known X.400 and MIME
Types ................................................ 22
5.3 MIME to X.400 Table .................................. 23
1つの序論… 2 1.1用語集… ボディーのための3 2の基本的なルールが変換を分けます… 4 2.1 MIMEからIPMボディーを発生させます… 5 MIMEを発生させる2.2がIPMSから. ボディーを具体化させます… 6 2.3 EMA FTBPパラメタを写像します… 7 2.3 .1 GraphicStringsを写像します… 7 2.3 .2 特定のパラメタを写像します… 7 2.3 発生するFTBP要素の.3概要… 10 2.4 写像するとき無くなっている情報… 11 3 身体の部分のカプセル化… 11 3.1 X.400のMIMEのカプセル化… 12 3.1 .1 ボディーを要約するFTBPが離れています… 12 3.1 .2 ボディーを要約するBP15が離れています… 13 3.1 .3カプセル化使用IA5(もりを打ち込みます)… 15 3.1 BP14を使用することで終わる.4内容… 16 3.2 MIMEにおけるX.400ボディ・パーツを要約します… 16 3.3 MIMEでFTBP身体の部分を要約します… 17 4 ゲートウェイ選択のユーザコントロール… 18 MIMEからX.400までの4.1変換… 18 X.400からMIMEまでの4.2変換… 20 5 等価性登録… 21 5.1 マッピングに関して教えなければならないすべての情報… 21 知られているX.400とMIMEの種類のための5.2等価性概要… 22 5.3 X.400テーブルにまねてください… 23
Alvestrand Standards Track [Page 1] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[1ページ]RFC2157X.400/MIMEボディー
5.4 X.400 to MIME Table .................................. 23
5.5 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ........... 24
6 Defined Equivalences ................................... 26
6.1 IA5Text - text/plain ................................. 26
6.2 GeneralText - text/plain (ISO-8859) .................. 27
6.3 BilaterallyDefined - application/octet-stream
...................................................... 29
6.4 FTBP EMA Unknown Attachment -
application/octet-stream ............................. 29
6.5 MessageBodyPart - message/RFC822 ..................... 30
6.6 MessageBodyPart - multipart/* ........................ 31
6.7 Teletex - Text/Plain (Teletex) ....................... 32
7 Body parts where encapsulation is recommended .......... 33
7.1 message/external-body ................................ 34
7.2 message/partial ...................................... 35
7.3 multipart/signed ..................................... 35
7.4 multipart/encrypted .................................. 36
8 Conformance requirements ............................... 37
9 Security Considerations ................................ 38
10 Author's Address ...................................... 38
11 Acknowledgements ...................................... 38
References .............................................. 38
APPENDIXES .............................................. 41
Appendix A: Escape code normalization ................... 41
Appendix B: OID Assignments ............................. 44
Appendix C: Registration information for the
Teletex character set ............................... 46
Appendix D: IANA Registration form for new
mappings ................................................ 48
Full Copyright Statement ................................. 49
テーブルをまねる5.4X.400… 23 5.5 物の識別子とASN.1マクロの使用… 24 6は等価性を定義しました… 26 6.1 IA5Text--テキスト/平野… 26 6.2 GeneralText--テキスト/平野(ISO-8859)… 27 6.3 BilaterallyDefined--八重奏アプリケーション/流れ… 29 6.4 FTBP EMA Unknown Attachment--八重奏アプリケーション/流れ… 29 6.5 MessageBodyPart--メッセージ/RFC822… 30 6.6 MessageBodyPart--複合/*… 31 6.7 テレテックス--テキスト/平野(テレテックス)… 32 7 カプセル化がお勧めである身体の部分… 33 7.1 外部のメッセージ/ボディー… 34 7.2 メッセージ/部分的… 35 7.3 複合かサインされる… 35 7.4 複合かコード化される… 36 8 順応要件… 37 9 セキュリティ問題… 38 10作者のアドレス… 38 11の承認… 38の参照箇所… 38の付属物… 41 付録A: コード正常化から逃げてください… 41 付録B: OID課題… 44 付録C: Teletex文字の組のための登録情報… 46 付録D: IANA Registrationは新しいマッピングのために形成します… 48 完全な著作権宣言文… 49
1. Introduction
1. 序論
This document is a companion to [MIXER], which defines the principles and translation of headers for interworking between MIME-based RFC- 822 mail and X.400 mail.
このドキュメントは[MIXER]の仲間です。(それは、MIMEベースのRFC822メールとX.400メールの間の織り込むためにヘッダーに関する原則と翻訳を定義します)。
This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages.
このドキュメントは逆もまた同様にX.400メッセージの身体の部分をMIME実体に写像する方法を定義します、複合メッセージと転送されたメッセージの取り扱いを含んでいて。
Alvestrand Standards Track [Page 2] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[2ページ]RFC2157X.400/MIMEボディー
1.1. Glossary
1.1. 用語集
The following terms are defined in this document:
次の用語は本書では定義されます:
Body part
Part of a message that has a unique type. This term comes from
X.400; the corresponding term in MIME (RFC 2046) is limited to use
in parts of a multipart message; the term "body" may correspond
better.
ユニークなタイプがあるメッセージの身体のパートPart。 今期はX.400から来ます。 MIME(RFC2046)における対応する用語は複合メッセージの部分での使用に制限されます。 「ボディー」という用語は、より一層対応するかもしれません。
Content-type
Type information indicating what the content of a body part
actually is. This term comes from MIME; the corresponding X.400
term is "body part type".
身体の部分の内容が実際に何であるかを示す文書内容Type情報。 今期はMIMEから来ます。 対応するX.400用語は「ボディー部分タイプ」です。
Mapping
(noun): A description of how to transform an X.400 body part into
a MIME body part, or how to transform a MIME body part into an
X.400 body part.
マッピング(名詞): どのようにX.400身体の部分をMIME身体の部分に変えるか、そして、またはどのようにMIME身体の部分をX.400身体の部分に変えるかに関する記述。
Equivalence
A set of two mappings that taken together provide a lossless
conversion between an X.400 body part and a MIME body part
Aが設定した一緒に取って、X.400身体の部分とMIME身体の部分の間にlossless変換を提供する2つのマッピングの等価性
Encapsulation
The process of wrapping something from one of the mail systems in
such a way that it can be carried inside the other mail system.
When encapsulating, it is not expected that the other mail system
can make reasonable sense of the body part, but a gateway back
into the first system will always be able to convert the body part
without loss back to its original format.
カプセル化、メールシステムの1つから何かをもう片方のメールシステムの中でそれを運ぶことができるような方法で包装する過程。 要約するとき、もう片方のメールシステムが身体の部分の妥当な意味になることができないと予想されますが、最初のシステムへのゲートウェイは元の形式への損失なしで身体の部分をいつも変換できるでしょう。
HARPOON encapsulation
The encapsulating of a MIME body part by putting it inside an IA5
body with all headers and encoding intact. First described in RFC
1496 [HARPOON].
すべてのヘッダーとコード化が完全な状態でMIME本体の要約がIA5ボディーの中にそれを置くことによって離れさせるHARPOONカプセル化。 1番目はRFC1496で[HARPOON]について説明しました。
Tunneling
What happens when one gateway encapsulates a message and sends it
to another gateway that decapsulates it. The hope is that this
will cause minimal damage to the message in transit.
あるゲートウェイがそれをdecapsulatesするもう1門にメッセージを要約して、それを送るとき、トンネリングWhatは起こります。 望みはこれがトランジットにおけるメッセージに最小限のダメージを引き起こすということです。
DISCUSSION
At many points in this document, the author has found it useful to
include material that explains part of the reasoning behind the
specification. These sections all start with DISCUSSION: and
continue to the next numbered section heading; they do not dictate
any additional requirements on a gateway.
このドキュメントのDISCUSSION At多くのポイント、作者は仕様の後ろで推理の一部がわかる材料を含んでいるのが役に立つのがわかりました。 これらのセクションはすべて、DISCUSSIONから始まります: そして、次の番号付のセクション見出しに続いてください。 彼らはゲートウェイに関するどんな追加要件も書き取りません。
Alvestrand Standards Track [Page 3] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[3ページ]RFC2157X.400/MIMEボディー
The words MUST, SHOULD and MAY, when capitalized, are used as defined in RFC 2119 [MUST].
SHOULD、単語はそうしなければなりません、そして、5月、大文字で書かれたいつがRFC2119[MUST]で定義されるように使用されているか。
2. Basic rules for body part conversion
2. ボディー部分変換のための基本的なルール
The basic approach for translating body parts is described in section 2.1 and 2.2.
身体の部分を翻訳するための基本的なアプローチはセクション2.1と2.2で説明されます。
Chapter 3 gives details on "encapsulation", which allows you to be certain that no information is lost even when unknown types are encountered.
第3章はあなたが未知のタイプが遭遇するとき、情報が全く失われてさえいないのを確信しているのを許容する「カプセル化」に関する詳細を述べます。
Chapter 6 gives the core mappings for various body parts.
第6章は様々な身体の部分のためのコアマッピングを与えます。
The conformance requirements in chapter 8 describe what the minimum conformance for a MIXER gateway is with respect to body part conversion.
第8章における順応要件は、MIXERゲートウェイのための最小の順応がボディー部分変換に関する何であるかを説明します。
DISCUSSION:
議論:
At the moment both the MIME and the X.400 worlds seem to be in a stable state of flux with regards to carrying around stuff that is not text. In such a situation, there is little chance of defining a mapping between them that is the best for all people, all of the time. For this reason, this specification allows a gateway considerable latitude in deciding exactly what conversion to apply.
現在、MIMEとX.400世界の両方があいさつがあるフラックスの安定状態にテキストでないものを持ち歩くのにあるように思えます。 そのような状況に、それらの間のすべての人々にとって、最も良いマッピングを定義するわずかなチャンスがあります、絶えず。 この理由で、どんな変換を適用したらよいかをまさに決める際にこの仕様はゲートウェイのかなりの緯度を許容します。
The decision taken by the gateway may be based on various information sources:
ゲートウェイによって取られた決定は様々な情報源に基づくかもしれません:
(1) If the gateway knows what body parts or content
types the recipient is able to handle, or has
registered a particular set of preferences for a
user, and knows how to convert the message
reasonably to those body parts, the gateway may
choose to convert body parts in the message to
those types only.
(1) ゲートウェイがそれらの身体の部分に受取人がどんな身体の部分か満足しているタイプを扱うことができるかを知っているか、ユーザのために特定の好みを示して、または合理的にメッセージを変換する方法を知っているなら、ゲートウェイは、メッセージで身体の部分をそういったタイプの人だけに変換するのを選ぶかもしれません。
(2) If the gateway gets indications (via special
headers or heading-extensions defined for the
purpose) that the sender wanted a particular
representation on the "other side", and the gateway
is able to satisfy the request, it may do so. Such
a mechanism is defined in chapter 4 of this
document.
(2) ゲートウェイが送付者が「反対側」で特定の表現が欲しく、ゲートウェイが要望に応じることができるという指摘(特別なヘッダーか目的のために定義された見出し拡張子を通した)を得るなら、それはそうするかもしれません。 そのようなメカニズムはこのドキュメントの第4章で定義されます。
Alvestrand Standards Track [Page 4] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[4ページ]RFC2157X.400/MIMEボディー
(3) If the gateway gets a message that might be
appropriate to send as one out of several types,
but where the typing information does not tell you
which one to use (like an X.400 BP14, FTAM "just a
file", or MIME application/octet-stream), it may
apply heuristics like looking at content or looking
at filenames to figure out how to deal with the
message.
(3) ゲートウェイが1としていくつかのタイプから送るのが適切であるかもしれませんが、タイプ情報がどれを使用したらよいかをあなたに言わないメッセージ(X.400 BP14、FTAM「正当なaファイル」、またはMIME八重奏アプリケーション/流れのような)を得るなら、それは内容を見るか、またはメッセージに対処する方法を理解するためにファイル名を見るような発見的教授法を適用するかもしれません。
(4) If the gateway knows that the next hop for the
message has limited capabilities (like X.400/84),
it may choose to perform conversions appropriate
for that medium.
(4) ゲートウェイが、メッセージのための次のホップが能力(X.400/84のような)を制限したのを知っているなら、それは、その媒体に、適切な変換を実行するのを選ぶかもしれません。
(5) Where no mapping is known by the gateway, it
may choose to drop the body part, reject the
message, or encapsulate the body part as
described in chapter 3. The choice may be
configurable, but a conformant MIXER gateway MUST
be able to be configured for encapsulation.
(5) それは、第3章で説明されるように写像でないのがゲートウェイによって知られているところに、身体の部分を落とすのを選ぶか、メッセージを拒絶するか、または身体の部分を要約するかもしれません。 選択は構成可能であるかもしれませんが、conformant MIXERゲートウェイはカプセル化のために構成できなければなりません。
In many cases, a message that goes SMTP->X.400->SMTP will arrive without loss of information.
多くの場合行くメッセージ、SMTP、-SMTPが望んでいる>X.400->は情報の損失なしで届きます。
In some cases, the reverse translation may not be possible, or two gateways may choose to apply different translations, based on the criteria above, leading to an apparently inconsistent service.
いくつかの場合、逆の翻訳が可能でないかもしれませんか、または2門は、明らかに無節操なサービスに通じながら、上で評価基準に基づいた異なった翻訳を適用するのを選ぶかもしれません。
In addition, service will vary because some gateways will have implemented conversions not implemented by other gateways.
さらに、数門が他のゲートウェイによって実行されなかった変換を実行してしまうだろうので、サービスは異なるでしょう。
This is believed to be unavoidable.
これが避けられないと信じられています。
2.1. Generating the IPM Body from MIME
2.1. MIMEからIPMボディーを発生させます。
When converting the body of a message from MIME to X.400, the following steps are taken:
MIMEからX.400までメッセージのボディーを変換するとき、以下の方法を取ります:
If the header does not contain a 822.MIME-Version field, then generate an IPMS.Body with a single IPMS.BodyPart of type IPMS.IA5TextBodyPart containing the body of the RFC 822 message with IPMS.IA5TextBodyPart.parameters.repertoire set to the default (IA5).
ヘッダーが822.MIME-バージョン分野を含まないなら、タイプIPMS.IA5TextBodyPartの独身のIPMS.BodyPartがデフォルト(IA5)に用意ができているIPMS.IA5TextBodyPart.parameters.repertoireと共にRFC822メッセージのボディーを含んでいるIPMS.Bodyを発生させてください。
If 822.MIME-Version is present, the body is analyzed as a MIME message and the body is converted according to the mappings configured and implemented in the gateway.
822.MIME-バージョンが存在しているなら、ボディーはMIMEメッセージとして分析されます、そして、ゲートウェイで構成されて、実行されたマッピングによると、ボディーは変換されます。
Alvestrand Standards Track [Page 5] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[5ページ]RFC2157X.400/MIMEボディー
2.2. Generating the MIME Body from the IPMS.Body
2.2. IPMS.BodyからMIME本体を発生させます。
When converting the body of a message from X.400 to MIME, the following steps are taken:
X.400からMIMEまでメッセージのボディーを変換するとき、以下の方法を取ります:
If there is more than one body part, and the first body part is IA5 and starts with the string "RFC-822-Headers:" as the first line, then the remainder of this body part shall be appended to the RFC 822 header. This relies upon the theory that this body part has been generated according to Appendix B of MIXER. A gateway shall check the consistency and syntax of this body part, to ensure that the resulting message is conformant with RFC 822.
1つ以上の身体の部分があって、最初の身体の部分がIA5であり、ストリングから始まる、「RFC822ヘッダー:」 そして、最初の線として、この身体の部分の残りをRFC822ヘッダーに追加するものとします。 これはMIXERのAppendix Bに応じてこの身体の部分が発生したという理論を当てにされます。 ゲートウェイは、結果として起こるメッセージがRFC822とconformantであることを保証するためにこの身体の部分の一貫性と構文をチェックするものとします。
If the remaining IPMS.Body consists of a single IPMS.Bodypart, there are three possibilities.
残っているIPMS.Bodyが独身のIPMS.Bodypartから成るなら、3つの可能性があります。
(1) If it is of type IPMS.IA5Text, and the first line
is "MIME-Version: 1.0", it is assumed to be a
HARPOON-encapsulated body part. The complete body
content is then appended to the headers; the
separating blank line is inside the message. If an
RFC 822 syntax error is discovered inside the
message, it may be mapped directly as described
below instead.
(1) それがタイプIPMS.IA5Textのそうであり、最初の線がそうである、「MIMEバージョン:」 何1インチも、それはHARPOONによって要約された身体の部分であると思われます。 次に、完全なボディー内容をヘッダーに追加します。 メッセージには分離している空白行があります。 RFC822構文エラーがメッセージで発見されるなら、それは直接代わりに以下で説明されるように写像されるかもしれません。
(2) If it is of type IPMS.IA5Text, then this is mapped
directly and the default MIME encoding (7bit) is
used, unless very long lines or non-ASCII or
control characters are found in the body part, in
which case Quoted-Printable SHOULD be used.
(2) タイプIPMS.IA5Textにはそれがあって、次に、これが直接写像されて、非常に長い線、非ASCIIまたは制御文字が身体の部分で見つけられない場合(7ビット)をコード化するデフォルトMIMEが使用されているなら、どれがQuoted印刷可能なSHOULDをケースに入れるかで使用されてください。
(3) All other types are mapped according to the
mappings configured and implemented in the gateway.
(3) ゲートウェイで構成されて、実行されたマッピングによると、他のすべてのタイプが写像されます。
If the IPMS.Body contains multiple IPMS.Bodypart fields, then a MIME message of content type multipart is generated. If all of the body parts are messages, then this is multipart/digest. Otherwise it is multipart/mixed. The components of the multipart are generated in the same order as in the IPMS.Body.
IPMS.Bodyが複数のIPMS.Bodypart分野を含んでいるなら、満足しているタイプ複合に関するMIMEメッセージは発生します。 身体の部分のすべてがメッセージであるなら、これは複合/ダイジェストです。 さもなければ、それは、複合か混ぜられます。 複合のコンポーネントはIPMS.Bodyのように同次で発生します。
Each component is mapped according to the mappings configured and implemented in the gateway; any IA5 body parts are checked to see if they are HARPOON mappings, as described above.
ゲートウェイで構成されて、実行されたマッピングによると、各コンポーネントは写像されます。 どんなIA5身体の部分も、それらが上で説明されるようにHARPOONマッピングであるかどうか確認するためにチェックされます。
Alvestrand Standards Track [Page 6] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[6ページ]RFC2157X.400/MIMEボディー
2.3. Mapping the EMA FTBP parameters
2.3. EMA FTBPパラメタを写像します。
DISCUSSION:
議論:
EMA has defined a profile for use of the File Transfer Body Part (FTBP). [MAWG]
EMAはFile Transfer Body Part(FTBP)の使用のためのプロフィールを定義しました。 [MAWG]
New mappings are expected to use this as the mechanism for carrying body parts, and since it is important to have a consistent mapping for the special FTBP parameters, these are defined here.
新しいマッピングが身体の部分を運ぶのにメカニズムとしてこれを使用すると予想されて、特別なFTBPパラメタのための一貫したマッピングを持っているのが重要であるので、これらはここで定義されます。
The mapping of the body will depend on the content-type in MIME and on the application-reference in FTBP, and is not specified here.
ボディーに関するマッピングは、MIMEにおける満足しているタイプと、そして、FTBPでのアプリケーション参照に頼って、ここで指定されません。
However, in many cases, we expect that the translation will involve simply copying the octets from one format to the other; that is, "no conversion".
しかしながら、多くの場合、私たちは、翻訳が、単に1つの形式からもう片方までの八重奏をコピーすることを伴うと予想します。 すなわち、「変換がありません。」
2.3.1. Mapping GraphicStrings
2.3.1. GraphicStringsを写像します。
Some parameters of the EMA Profile are encoded as ASN.1 GraphicStrings, which are troublesome because they can contain any ISO registered graphic character set. To map these to ASCII for use in mail headers, the gateway may either:
EMA ProfileのいくつかのパラメタがASN.1GraphicStringsとしてコード化されて、彼らが何かISOを含むことができるのでどれが厄介であるかが図形文字セットを登録しました。 メールヘッダにおける使用のためのASCIIにこれらを写像するために、ゲートウェイはそうするかもしれません:
(1) Use the RFC 2047 [MIME-HDR] encoding mechanism to
create appropriate encoded-words for the headers
involved. Note that in some cases, such as within
Content-Disposition filenames, the encoded-words
must be in quotes, which is not the normal usage of
encoded-words.
(1) かかわった状態でヘッダーに対する適切なコード化された単語を作成するためにメカニズムをコード化して、RFC2047[MIME-HDR]を使用してください。 Content-気質ファイル名などのいくつかの場合には、コード化された単語が引用文にあるに違いないことに注意してください(コード化された単語の正常な用法ではありません)。
(2) Apply the normalization procedure given in Appendix
A to identify the ASCII characters of the string,
and replace all non-ASCII characters with the
question mark (?).
(2) ストリングのASCII文字を特定するためにAppendix Aで与えられた正常化手順を適用してください、そして、すべての非ASCII文字を疑問符(?)に取り替えてください。
Both procedures are valid for MIXER gateways; the simplified procedure of ignoring escape sequences and bit-stripping the result is NOT valid.
MIXERゲートウェイに、両方の手順は有効です。 エスケープシーケンスを無視して、結果をビット剥取る簡易手法は有効ではありません。
2.3.2. Mapping specific parameters
2.3.2. 特定のパラメタを写像します。
The following parameters are mapped in both directions:
以下のパラメタは両方の方向に写像されます:
Content-ID
コンテントID
The mapping of this element is complex.
この要素のマッピングは複雑です。
Alvestrand Standards Track [Page 7] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[7ページ]RFC2157X.400/MIMEボディー
The Content-ID is encoded as an IPM.MessageIdentifier and entered
into the FTBP.FileTransferParameters.related-stored-file. file-
identifier.cross-reference.message-reference.
コンテントIDは、IPM.MessageIdentifierとしてコード化されて、FTBP.FileTransferParameters.relatedがファイルを格納していたのに入れられます。identifier.cross-reference.message-referenceをファイルしてください。
FTBP.FileTransferParameters.related-stored-file.
relationship.descriptive-relationship is set to the string
"Internet MIME Body Part".
FTBP.FileTransferParameters.relatedはファイルを格納しました。relationship.descriptive-関係はストリング「インターネットMIME身体の部分」に設定されます。
FTBP.FileTransferParameters.related-stored-file. file-
identifier.cross-reference.application-crossreference is set to a
null OCTET STRING.
FTBP.FileTransferParameters.relatedはファイルを格納しました。ファイルidentifier.cross-reference.application-crossreferenceはヌルOCTET STRINGに用意ができています。
The reverse mapping is only performed if the
FTBP.FileTransferParameters.related-stored-file.
relationship.descriptive-relationship has the string value
"Internet MIME Body Part".
FTBP.FileTransferParameters.relatedがファイルを格納していた場合にだけ、逆のマッピングは実行されます。relationship.descriptive-関係には、ストリング値の「インターネットMIME身体の部分」があります。
Content-Description
満足している記述
The value of this field is mapped to and from the first string in
FTBP.FileTransferParameters.environment.user-visible-string.
この分野の値はストリングとFTBP.FileTransferParameters.environment.userの目に見えるストリングにおける最初のストリングから写像されます。
Content-Disposition
満足している気質
This field is defined in [CDISP]. It has multiple components; the
handling of each component is given below.
この分野は[CDISP]で定義されます。 それには、複数のコンポーネントがあります。 各コンポーネントの取り扱いを以下に与えます。
The "disposition" component is ignored on MIME -> X.400 mapping,
and is always "attachment" on X.400 -> MIME mapping.
「気質」コンポーネントは、MIME->X.400マッピングで無視されて、いつもX.400->MIMEマッピングに関する「付属」です。
C-D: filename
C-D: ファイル名
The filename component of the C-D header is mapped to and from
FileTransferParameters.file-attributes.pathname.
C-Dヘッダーのファイル名の部品はFileTransferParameters.file-attributes.pathnameとFileTransferParameters.file-attributes.pathnameから写像されます。
The EBNF.disposition-type is ignored when creating the FTBP
pathname, and always set to "attachment" when creating the
Content-Disposition header. For example:
Content-気質ヘッダーを創造するとき、EBNF.disposition-タイプは、FTBPパス名を作成するとき、無視されて、いつも「付属」に用意ができています。 例えば:
Content-Disposition: attachment; filename=dodo.doc
満足している気質: 付属。 ファイル名=dodo.doc
or
または
Content-Disposition: attachment; filename=/etc/passwd
満足している気質: 付属。 ファイル名=/etc/passwd
Alvestrand Standards Track [Page 8] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[8ページ]RFC2157X.400/MIMEボディー
The filename will be carried as a single incomplete-pathname
string. No special significance is assumed for the characters "/"
and "\". Note that normal security precautions MUST be taken in
using a filename on a local file system; this should be obvious
from the second example.
ファイル名はただ一つの不完全なパス名ストリングとして運ばれるでしょう。 「どんな特別な意味もキャラクタのために想定されない」/、」 「\。」 ローカルファイルシステムの上でファイル名を使用して、通常の安全対策を中に入れなければならないことに注意してください。 これは2番目の例から明白であるべきです。
This is done to be conformant with the EMA Profile.
EMA Profileとconformantになるようにこれをします。
C-D: Creation-date
C-D: 作成日付
Mapped to and from FileTransferParameters.file-attributes.date-
and-time-of-creation
FileTransferParameters.file-attributes.dateとFileTransferParameters.file-attributes.dateから写像される、創造の時間
For this and all other date fields, the RFC-822 date format is
used (822.date-time). Note that the parameter syntax of [CDISP]
requires that all dates be quoted!
他のこれとすべての日付の分野において、RFC-822日付の形式は使用されています(822.date-時間)。 [CDISP]のパラメタ構文が、すべての日付が引用されるのを必要とすることに注意してください!
C-D: Modification-date
C-D: 変更日付
Mapped to and from FileTransferParameters.file-attributes.date-
and-time-of-last-modification
FileTransferParameters.file-attributes.dateとFileTransferParameters.file-attributes.dateから写像される、最後の変更の時間
C-D: Read-date
C-D: 日付を読みます。
Mapped to and from FileTransferParameters.file-attributes.date-
and-time-of-last-read-access
FileTransferParameters.file-attributes.dateとFileTransferParameters.file-attributes.dateから写像される、最後に読まれたアクセスの時間
C-D: Size
C-D: サイズ
Mapped to and from FileTransferParameters.file-attributes.object-
size. If the value is "no-value-available", the component is NOT
generated.
サイズとFileTransferParameters.file-attributes.objectサイズから写像されます。 値が「利用可能な値がありません」であるなら、コンポーネントは発生しません。
Other RFC-822 headers
他のRFC-822ヘッダー
Mapped to extension in FTBP.FileTransferParameters.extensions
using the rfc-822-field HEADING-EXTENSION from [MIXER].
[MIXER]からrfc822分野HEADING-EXTENSIONを使用することでFTBP.FileTransferParameters.extensionsでの拡大に写像されます。
NOTE:
The set of headers that are mapped will depend on the placement of
the body part (single body part or multipart).
When it is the only body of a message, headers starting with
"content-" SHOULD be put into the FTAM extension, and all other
headers should be put into the IPMS extension for the message.
When it is a single bodypart of a multipart, ALL headers on the
body part are included, since there is nowhere else to put them.
Note that only headers that start with "content-" have defined
semantics in this case.
以下に注意してください。 写像されるヘッダーのセットは身体の部分(ただ一つの身体の部分の、または、複合の)のプレースメントに依存するでしょう。 それが唯一のボディーであるときに、メッセージ、FTAM拡張子に置かれる「内容」SHOULDから始まるヘッダー、およびすべてでは、メッセージのためのIPMS拡張子に他のヘッダーを入れるべきです。 それがa複合の単一のbodypartであるときに、身体の部分の上のすべてのヘッダーが含まれています、彼らを置くためにほかにどこにもないので。 「内容」から始めるヘッダーだけがこの場合意味論を定義したことに注意してください。
Alvestrand Standards Track [Page 9] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[9ページ]RFC2157X.400/MIMEボディー
EMA NOTE
EMA注意
The EMA profile, version 1.5, specifies that handling of
extensions is Optional for reception. This means that some non-
MIXER gateways may not implement handling of this field, and some
UAs may not have the possibility of showing the content of this
field to the user.
EMAプロフィール(バージョン1.5)は、拡大の取り扱いがレセプションのためのOptionalであると指定します。 これは非MIXERの数num#nil個の門がこの分野の取り扱いを実行しないかもしれなくて、またいくつかのUAsにはこの分野の内容をユーザに示している可能性がないかもしれないことを意味します。
An alternative approach using
FTBP.FileTransferParameters.environment.user-visible-string was
suggested to EMA, and the EMA MAWG recommended in its April 1996
conference that the IETF MIXER group should rather choose this
approach.
FTBP.FileTransferParameters.environment.userの目に見えるストリングを使用する代替的アプローチはEMAに提案されました、そして、EMA MAWGは1996年4月の会議でIETF MIXERグループがむしろこのアプローチを選ぶべきであることを勧めました。
2.3.3. Summary of FTBP elements generated
2.3.3. 発生するFTBP要素の概要
This is a summary of the preceding section, and does not add new information.
これは、先行するセクションの概要であり、新情報を加えません。
The following elements of the FTBP parameters are mapped or used (the rightmost column gives their status in the EMA profile; M=Mandatory, O=Optional, R=Recommended for Origination/Receipt):
FTBPパラメタの以下の要素は、写像されるか、または使用されます(一番右のコラムはEMAプロフィールでそれらの状態を与えます; MはOrigination/領収書のために推薦された義務的で、O=任意のR=と等しいです):
FileTransferParameters M/M
Related-Stored-File O/O
file-identifier
cross-reference
application-crossreference NULL
message-reference Content-ID
descriptive-relationship Used as marker
contents-type Must be unstructured-binary M/M
environment M/M
application-reference Selects mapping M/M
user-visible-string Content-description R/M
file-attributes
pathname C-D: Filename R/M
date-and-time-of-creation C-D: Creation-Date O/O
date-and-time-of-last-modification C-D: Modification-Date R/M
date-and-time-of-last-read-access C-D: Read-Date O/O
object-size C-D: Size R/M
extensions Other headers O/O
マーカーとしてのFileTransferParameters M/M関連格納されたファイルOファイル識別名相互参照アプリケーション-crossreference NULL O/メッセージ参照コンテントID描写的である関係UsedはM/Mユーザの目に見えるストリングContent-記述R/Mファイル属性パス名を写像した不統一なバイナリーM/M環境M/Mアプリケーション参照SelectsがC-DであったならMustをコンテンツでタイプします: ファイル名R/M創造の日付と時間C-D: 創造日付のO/O最後の変更の日付と時間C-D: 変更日付のR/M最後に読まれたアクセスの日付と時間C-D: 日付を読んでいるO物O/サイズC-D: サイズR/M拡大OtherヘッダーO/O
All other elements of the FTBP parameters are discarded.
FTBPパラメタの他のすべての要素が捨てられます。
Alvestrand Standards Track [Page 10] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[10ページ]RFC2157X.400/MIMEボディー
NOTE: There is ongoing work on defining a more complete mapping between FTBP headers and a set of RFC-822 headers. A gateway MAY choose to support the larger set once it is available, but MUST support this limited set.
以下に注意してください。 RFC-822ヘッダーのFTBPヘッダーとセットの間には、より完全なマッピングを定義することに対する進行中の仕事があります。 ゲートウェイは、いったん利用可能になると、より大きいセットを支えるのを選ぶかもしれませんが、この限られたセットを支えなければなりません。
2.4. Information that is lost when mapping
2.4. 写像するとき無くなっている情報
MIME defines fields which add information to MIME contents. Two of these are "Content-ID", and "Content-Description", which have special rules here, but MIME allows new fields to be defined at any time.
MIMEはMIMEコンテンツに情報を加える分野を定義します。 これらの2は、「コンテントID」と、「満足している記述」ですが、MIMEは、新しい分野がいつでも定義されるのを許容します。(それは、ここに特別な規則を持っています)。
The possibilities are limited about what one can do with this information:
可能性は1つがこの情報でできることが制限されます:
(1) When using encapsulation, the information can be
preserved
(1) カプセル化を使用するとき、情報を保存できます。
(2) When using mapping to FTBP, the information can be
preserved in the FileTransferParameters.extensions
defined for that purpose.
(2) FTBPにマッピングを使用するとき、そのために定義されたFileTransferParameters.extensionsに情報を保存できます。
(3) When mapping to a single-body message, the
information can be preserved as P22 header
extensions
(3) 単一のボディーメッセージに写像するとき、P22ヘッダー拡張子として情報を保存できます。
(4) When mapping to other body part types, the
information must be discarded.
(4) 部分タイプを他のボディーに写像するとき、情報を捨てなければなりません。
3. Encapsulation of body parts
3. 身体の部分のカプセル化
Where no mapping is possible, the gateway may choose any of the following alternatives:
写像でないのが可能であるところでは、ゲートウェイは以下の代替手段のどれかを選ぶかもしれません:
- Discard the body part, leaving a "marker" saying what
happened
- 「マーカー」が、何が起こったかを言っているままにして、身体の部分を捨ててください。
- Reject the message
- メッセージを拒絶してください。
- "Encapsulate" the body part, by wrapping it in a body
part defined for that purpose in the other mail
system
- もう片方のメールシステムの身体の部分であって、身体の部分でそれを包装することによってそのために定義された「要約してください」
The choice to be made should be configurable in the gateway, and may depend on both policy and knowledge of the recipient's capabilities.
作られているこの選択は、ゲートウェイで構成可能であるべきであり、方針と受取人の能力に関する知識の両方次第であるかもしれません。
Alvestrand Standards Track [Page 11] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[11ページ]RFC2157X.400/MIMEボディー
3.1. Encapsulation of MIME in X.400
3.1. X.400のMIMEのカプセル化
Four body parts are defined here to encapsulate MIME body parts in X.400.
4つの身体の部分が、X.400でMIME身体の部分を要約するためにここで定義されます。
This externally-defined body part is backwards compatible with RFC 1494. The FTBP body part is compatible with the EMA MAWG document [MAWG], version 1.5, but has some extensions, in particular the one for extra headers.
この外部的に定義された身体の部分は後方にRFC1494と互換性があった状態であります。 FTBP身体の部分には、EMA MAWGドキュメント[MAWG]、バージョン1.5と互換性がありますが、いくつかの拡大、特にものが余分なヘッダーのためにあります。
The imagined scenarios for each body part are:
それぞれの身体の部分への想像されるシナリオは以下の通りです。
FTBP For use when sending to recipients that can handle
generic FTBP, and for tunnelling MIME to a MIME UA
一般的なFTBPを扱うことができる受取人と、MIME UAにMIMEにトンネルを堀るために発信するときのFTBP For使用
BP15 For use when tunnelling MIME to a MIME UA through an
X.400(88) network, or to UAs that have been written
to RFC 1494
X.400(88)ネットワークを通したMIME UA、または、RFC1494に書かれているUAsにMIMEにトンネルを堀るときのBP15 For使用
IA5 For use when tunneling MIME to a MIME UA through an
X.400 network, where some of the links may involve
X.400(84).
X.400ネットワークを通してMIME UAにMIMEにトンネルを堀るときのIA5 For使用。そこでは、いくつかのリンクがX.400(84)にかかわるかもしれません。
BP14 For use when the recipient may be an X.400(84) UA
with BP14 handling capability, and the loss of
information in headers is not regarded as important.
受取人がBP14取り扱い能力、および情報の損失がヘッダーにあるX.400(84) UAであることのBP14 For使用は重要であると見なされません。
but the gateway is free to use any method it finds appropriate in any situation.
しかし、ゲートウェイは無料でそれが適切であることがどんな状況においてもわかるどんな方法も使用できます。
FTBP is expected to be the most useful body part in sending to X.400(92) systems, while the BP14 content passing is primarily useful for sending to X.400(84) systems.
FTBPはX.400(92)システムに発信するのにおいて最も役に立つ身体の部分であると予想されます、BP14の満足している通過は主としてX.400(84)システムに発信することの役に立ちますが。
3.1.1. FTBP encapsulating body part
3.1.1. 身体の部分を要約するFTBP
This body part utilizes the fundamental assumption in MIME that all message content can be legally and completely represented by a single octet stream, the "canonical format".
この身体の部分はただ一つの八重奏の流れ、「正準な形式」ですべてのメッセージ内容を法的に、そして完全に表すことができるというMIMEにおける基本的仮説を利用します。
The FTBP encapsulating body part is defined by the application- reference id-mime-ftbp-data; all headers are mapped to the FTBP headers, including putting the "Content-type:" header inside the FTBP ExtensionsField.
身体の部分を要約するFTBPはアプリケーション参照イドパントマイムftbpデータによって定義されます。 すべてのヘッダーが置くのを含むFTBPヘッダーに写像される、「文書内容:」 FTBP ExtensionsFieldの中のヘッダー。
Translation from the MIME body part is done by:
以下はMIME身体の部分からの翻訳をします。
- Undoing the content-transfer-encoding
- 満足している転送コード化を元に戻します。
Alvestrand Standards Track [Page 12] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[12ページ]RFC2157X.400/MIMEボディー
- Setting the "FileTransferData.FTdata.value.octet-
aligned" to the resulting string of octets
- 「並べられたFileTransferData.FTdata.value.octet」を八重奏の結果として起こるストリングに設定します。
- Putting the appropriate parameters into the headers.
- 適切なパラメタをヘッダーに入れます。
Reversing the translation is done by:
翻訳は以下によって逆にされます。
- Extracting the headers
- ヘッダーを抽出します。
- Applying an appropriate content-transfer-encoding to
the body. If this is for some reason different from
the content-transfer-encoding: header retrieved from
the headers, the old one must be deleted.
- 適切な満足している転送コード化をボディーに当てます。 これが満足している転送コード化とある理由で異なるなら: ヘッダーから救済されたヘッダー、古い削除しなければなりません。
This mapping is lossless, and therefore counts as "no conversion".
このマッピングは、losslessであり、したがって、「変換がありません」にみなします。
Note that this mapping does not work with multipart types; the multipart must first be mapped to a ForwardedIPMessage.
このマッピングが複合タイプで働かないことに注意してください。 最初に、複合をForwardedIPMessageに写像しなければなりません。
3.1.2. BP15 encapsulating body part
3.1.2. 身体の部分を要約するBP15
This section defines an extended body part, based on body part 15, which may be used to hold any MIME content.
このセクションは拡張身体の部分を定義します、身体のパート15に基づいて。パートは、どんなMIME内容も保持するのに使用されるかもしれません。
mime-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS MimeParameters
IDENTIFIED BY id-mime-bp-parameters
DATA OCTET STRING
::= id-mime-bp-data
パントマイム身体のパートEXTENDED-BODY-PART-TYPE PARAMETERS MimeParameters IDENTIFIED BYイドパントマイムbpパラメタDATA OCTET STRING:、:= イドパントマイムbpデータ
MimeParameters ::=
SEQUENCE {
content-type IA5String,
content-parameters SEQUENCE OF
SEQUENCE {
parameter IA5String
parameter-value IA5String
}
other-header-fields RFC822FieldList
}
MimeParameters:、:= 系列満足しているタイプIA5String、満足しているパラメタSEQUENCE OF SEQUENCE、パラメタIA5Stringパラメタ価値のIA5String、他のヘッダーフィールドRFC822FieldList
The OBJECT IDENTIFIERS id-mime-bp-parameter and id-mime-bp-data are defined in Appendix B. A MIME content is mapped onto this body part. The MIME headers of the body part are mapped as follows:
OBJECT IDENTIFIERSイドパントマイムbpパラメタとイドパントマイムbpデータはAppendix B.で定義されます。A MIME内容はこの身体の部分に写像されます。 身体の部分のMIMEヘッダーは以下の通り写像されます:
RFC822FieldList is defined in Appendix L of [MIXER].
RFC822FieldListは[MIXER]のAppendix Lで定義されます。
Alvestrand Standards Track [Page 13] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[13ページ]RFC2157X.400/MIMEボディー
Content-Type:
The "type/subtype" string is mapped to
MimeParameters.content-type.
コンテントタイプ: 「タイプ/「副-タイプ」」ストリングはMimeParameters.content-タイプに写像されます。
For each "parameter=value" string create a
MimeParameters.content-parameters element. The
MimeParameters.content-Parameters.parameter field is
set to the parameter and the MimeParameters.content-
parameters.parameter-value field is set to the value.
各「パラメタ=価値」ストリングには、MimeParameters.content-パラメタ要素を作成してください。 MimeParameters.content-Parameters.parameter分野はパラメタに設定されます、そして、MimeParameters.content parameters.parameter-値の分野は値に設定されます。
Quoting is preserved in the parameter-value.
引用はパラメタ値で保存されます。
Other
Take all other headers and create
MimeParameters.other-header-fields.
The MIME-version, content-type and content-transfer-
encoding fields are NOT copied.
そして、他のTake、他のすべてのヘッダー、MimeParameters.other-ヘッダーフィールドを作成してください。 MIMEバージョンであり、満足しているタイプと満足している転送コード化分野はコピーされません。
NOTE:
The set of headers that are mapped will depend on the
placement of the body part (single body part or
multipart).
When it is the only body of a message, headers
starting with "content-" SHOULD be put into the
other-header-fields, and all other headers should be
put into the IPMS extension for the message.
When it is a single bodypart of a multipart, ALL
headers on the body part are included, since there is
nowhere else to put them. Note that only headers that
start with "content-" have defined semantics in this
case.
以下に注意してください。 写像されるヘッダーのセットは身体の部分(ただ一つの身体の部分の、または、複合の)のプレースメントに依存するでしょう。 それが唯一のボディーであるときに、メッセージ、他のヘッダーフィールドに置かれる「内容」SHOULDから始まるヘッダー、およびすべてでは、メッセージのためのIPMS拡張子に他のヘッダーを入れるべきです。 それがa複合の単一のbodypartであるときに、身体の部分の上のすべてのヘッダーが含まれています、彼らを置くためにほかにどこにもないので。 「内容」から始めるヘッダーだけがこの場合意味論を定義したことに注意してください。
The body is mapped as follows:
ボディーは以下の通り写像されます:
Convert the MIME body part into its canonical form, as specified in Appendix H of MIME [MIME]. This canonical form is used to generate the mime-body-part.data octet string.
MIME[MIME]のAppendix Hで指定されるようにMIME身体の部分を標準形に変換してください。 この標準形は、パントマイムボディーpart.data八重奏ストリングを発生させるのに使用されます。
The Parameter mapping may be used independently of the body part mapping (e.g., in order to use a different encoding for a mapped MIME body part).
Parameterマッピングはボディー部分マッピングの如何にかかわらず使用されるかもしれません(例えば、写像しているMIME本体に異なったコード化を使用するには、離れてください)。
This body part contains all of the MIME information, and so can be mapped back to MIME without loss of information.
MIME情報のすべてを含んでいるので、情報の損失なしでこの身体の部分をMIMEに写像であって戻しできます。
The OID id-mime-bp-data is added to the Encoded Information Types of the envelope.
OIDイドパントマイムbpデータは封筒のEncoded情報Typesに加えられます。
Alvestrand Standards Track [Page 14] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[14ページ]RFC2157X.400/MIMEボディー
This body part is completely compatible with RFC 1494.
この身体の部分はRFC1494と完全に互換性があります。
When converting back to a MIME body part, the gateway is responsible for:
MIME身体の部分に変えて戻るとき、ゲートウェイは以下に原因となります。
(1) Selecting an appropriate content-transfer-encoding,
and deleting any content-transfer-encoding header
from the other-header-fields
(1) 他のヘッダーフィールドから適切な満足している転送コード化を選択して、どんな内容がコード化を移しているヘッダーも削除すること。
(2) Adding quotes to any parameters that need them (but
not adding quotes to parameters that are already
quoted)
(2) それらを必要とするどんなパラメタにも引用文を追加すること。(既に引用されるパラメタに引用文を追加しませんが)
(3) Removing any content-type field that is left in the
RFC822FieldList of the message that is redundant or
conflicting with the one from the mime-body-part
(3) 余分なメッセージのRFC822FieldListに残されるどんな満足しているタイプ野原も取り除くか、またはパントマイム身体の部分からものと衝突すること。
(4) Make sure that on multipart messages, the boundary
string actually used is reflected in the boundary-
parameter of the content-type header, and does not
occur within the body of the message.
(4) 実際に使用される境界ストリングが複合メッセージでは、満足しているタイプヘッダーの境界パラメタに反映されて、メッセージ欄の中に現れないのを確実にしてください。
3.1.3. Encapsulation using IA5 (HARPOON)
3.1.3. IA5を使用するカプセル化(もり)
This approach is the one taken in RFC 1496 - HARPOON - for tunneling any MIME body part through X.400/84 networks. It has proven rather unhelpful for bringing information to X.400 users, but preserves all the information of a MIME body part.
このアプローチはX.400/84ネットワークを通したRFC1496(HARPOON)でどんなMIME身体の部分にもトンネルを堀るのに取られたものです。 それは、X.400ユーザに情報をもたらすのにおいてかなり役に立たないと判明しましたが、MIME身体の部分のすべての情報を保存します。
The following IA5Text body part is made:
以下のIA5Text身体の部分は作られています:
- Content = IA5String
- 内容はIA5Stringと等しいです。
- First bytes of content: (the description is in US
ASCII, with C escape sequences used to represent
control characters):
- 最初に、バイトの内容: (米国ASCIIにはCエスケープシーケンスが制御文字を表すのに使用されている状態で、記述があります):
MIME-version: <version>\r\n
Content-type: <the proper MIME content type>\r\n
Content-transfer-encoding: <7bit, quoted-printable or base64>\r\n
<Possibly other Content headings here, terminated by\r\n>
\r\n
<Here follows the bytes of the content, encoded
in the proper encoding>
MIMEバージョン: <バージョン>\r\n文書内容: 適切なMIMEが満足させる<は>\r\n Content転送コード化をタイプします: ここの<Possibly他の<噛み付いている7引用されて印刷可能であるかbase64>\r円n Content見出しであり、\r終えられて、\n>\r\n<Hereは内容のバイトに続きます、適切なコード化>でコード化されて
All implementations MUST place the MIME-version: header first in the body part. Headers that are placed by [MIXER] into other parts of the message MUST NOT be placed in the MIME body part.
すべての実現がMIMEバージョンを置かなければなりません: 最初に、身体の部分のヘッダー。 [MIXER]によってメッセージの他の部分に置かれるヘッダーをMIME身体の部分に置いてはいけません。
Alvestrand Standards Track [Page 15] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[15ページ]RFC2157X.400/MIMEボディー
This encapsulation may also be applied to subtypes of multipart, creating a single IA5 body part that contains a single multipart/*, which in turn may contain multiple MIME body parts.
また、このカプセル化は複合の血液型亜型に適用されるかもしれません、順番に複数のMIME身体の部分を含むかもしれない単一の複合/*を含むただ一つのIA5身体の部分を作成して。
3.1.4. Content passing using BP14
3.1.4. BP14を使用することで終わる内容
This is described in this section because it is at the same conceptual level as encapsulation. It is a lossy transformation; it is impossible to reconstruct the MIME type information from it.
それがカプセル化と同じ概念的なレベルにあるので、これはこのセクションで説明されます。 それは損失性変化です。 それからMIMEの種類情報を再建するのは不可能です。
Nevertheless, there is a demand for such functionality.
それにもかかわらず、そのような機能性の要求があります。
This "encapsulation" simply strips off all headers, undoes the content-transfer-encoding, and creates a BilaterallyDefined body part (BP14) from the resulting octet stream.
この「カプセル化」は、単にすべてのヘッダーを全部はぎ取って、満足している転送コード化を元に戻して、結果として起こる八重奏の流れからBilaterallyDefined身体の部分(BP14)を作成します。
No reverse translation is defined; when a BP14 arrives at a MIXER gateway, it will be turned into an application/octet-stream according to chap. 6.3
どんな逆の翻訳も定義されません。 BP14がMIXERゲートウェイに到着するとき、やつによると、それは八重奏アプリケーション/流れに変えられるでしょう。 6.3
3.2. Encapsulating X.400 Body Parts in MIME
3.2. MIMEにおけるX.400ボディ・パーツを要約します。
This section specifies a generic mechanism to map X.400 body parts to a MIME content. This allows for the body part to be tunneled through MIME. It may also be used directly by an appropriately configured MIME UA.
このセクションは、X.400身体の部分をMIME内容に写像するために一般的なメカニズムを指定します。 これは、身体の部分がMIMEを通してトンネルを堀られるのを許容します。 また、それは直接適切に構成されたMIME UAによって使用されるかもしれません。
This content-type is defined to carry any X.400 extended body part. The mapping of all standard X.400 body parts is defined in this document. The content-type field is "application/x400-bp". The parameter is defined by the EBNF:
この満足しているタイプは運ぶために定義されて、どんなX.400も身体の部分を広げたということです。 すべての標準のX.400身体の部分に関するマッピングは本書では定義されます。 満足しているタイプ分野は「アプリケーション/x400-bp」です。 パラメタはEBNFによって定義されます:
mime-parameter = "bp-type=" ( object-identifier / 1*DIGIT=
パントマイムパラメタが「bpタイプ=」と等しい、(物識別子/1*DIGITは等しいです。
If the body is a basic body part, the bp-type parameter is set to the number of the body part's context-specific tag, that is, the tag of the IPMS.Body.BodyPart component.
ボディーが基本的な身体の部分であるなら、bp-型引数は身体の部分の文脈特有のタグ(すなわち、IPMS.Body.BodyPartの部品のタグ)の数に設定されます。
If the body is an Extended Body Part, the EBNF.object-dentifier is set to the OBJECT IDENTIFIER from IPMS.body.externally- defined.data.direct-reference.
ボディーがExtended Body Partであるなら、EBNF.object-dentifierはIPMS.body.externally defined.data.direct-referenceからのOBJECT IDENTIFIERに用意ができています。
For example, a basic VideotexBodyPart will have
例えば、基本的なVideotexBodyPartはそうしてしまうでしょう。
Content-type=application/x400-bp; bp-type=6
文書内容はアプリケーション/x400-bpと等しいです。 bp-タイプ=6
whilst a Extended Videotex body part will have
Extended Videotex身体の部分はそうしてしまうでしょうが
Alvestrand Standards Track [Page 16] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[16ページ]RFC2157X.400/MIMEボディー
Content-type=application/x400-bp; bp-type=2.6.1.4.5
文書内容はアプリケーション/x400-bpと等しいです。 タイプ=2.6.1.4をbpしている.5
The body contains the raw ASN.1 IPM body octet stream, that is, the BER encoding of the IPM.Body.BodyPart, including the initial tag octet. The content may use a content-transfer-encoding of either base64 or quoted-printable when carried in 7-bit MIME. It is recommended to use the one which gives the more compact encoding of the data. If this cannot be determined, Base64 is recommended. No attempt is made to turn the parameters of Extended Body Parts into MIME parameters, as this cannot be done in a general manner.
ボディーはすなわち、生のASN.1IPMボディー八重奏の流れ、IPM.Body.BodyPartのBERコード化を含みます、初期のタグ八重奏を含んでいて。 7ビットのMIMEで運ばれると、内容はbase64か引用されて印刷可能な状態でどちらかの満足している転送コード化を使用するかもしれません。 データの、よりコンパクトなコード化を与えるものを使用するのはお勧めです。 これが決定できないなら、Base64はお勧めです。 Extendedボディ・パーツのパラメタをMIMEパラメタに変えるのを試みを全くしません、一般的な方法でこれができないように。
For extended body parts, the
拡張身体の部分に
3.3. Encapsulating FTBP body parts in MIME
3.3. MIMEでFTBP身体の部分を要約します。
The File Transfer Body Part is believed to be important in the future as "the" means of carrying well-identified data in X.400 networks.
運ぶ“the"手段がX.400ネットワークにおけるデータをよく特定したのでFile Transfer Body Partが将来重要であると信じられています。
They also share the property (at lest when limited to the EMA MAWG functional profile) of having a well-defined data part that is always representable as a sequence of bytes.
また、彼らが特性を共有する、(EMA MAWGの機能的なプロフィールに制限されたいつ) 明確なデータ部分を持つのにおいて、それはバイトの系列としていつも「表-可能」であるか。
This conversion will have to fail, and the x400-bp encapsulation used instead, if:
この変換が代わりに使用されるカプセル化をやり損ない、およびx400-bpに持つ、:
- FileTransferData has more than one element
- FileTransferDataには、1つ以上の要素があります。
- Contents-type is not unstructured-binary
- コンテンツタイプは不統一に2進ではありません。
- Parameters that are not mappable, but important, are
present (like Compression, which EMA doesn't
recommend).
- mappableでない、しかし、重要なパラメタは存在しています(EMAが推薦しないCompressionのような)。
Otherwise, it can be encapsulated in MIME by:
さもなければ、以下はMIMEでそれを要約できます。
- Creating the "content-type" value by forming the
string "application/x-ftbp." and appending the
numbers of the OID found in
FileTransferParameters.environment.application-
reference.registered-identifier
- 「アプリケーション/x-ftbp」 OIDの数を追加するとFileTransferParameters.environment.application reference.registered-識別子で見つけられたストリングを形成することによって、「満足しているタイプ」値を作成します。
- Mapping all other parameters according to the
standard FTBP parameter mapping
- 標準のFTBPパラメタマッピングによると、他のすべてのパラメタを写像します。
- Applying an appropriate content-transfer-encoding to
the data contained in FileTransferData.value.encoding
- 適切な満足している転送コード化をFileTransferData.value.encodingに含まれたデータに適用します。
Alvestrand Standards Track [Page 17] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[17ページ]RFC2157X.400/MIMEボディー
DISCUSSION:
議論:
The choice of the somewhat strange, and by necessity unregistered, MIME type "application/x-ftbp.n.n.n.n" is because for any concrete example of this usage, it will be easy to configure any MIME reader to take advantage of the identification. If the MIME type registration rules are ever changed to allow the registration of a namespace, rather than just of names, the "x-" can be deleted, and the types can be "application/ftbp.n.n.n.n".
いくらか奇妙の選択、必要に迫られて、登録されていないです、MIMEの種類「アプリケーション/x-ftbp.n.n.n.n」は識別を利用するためにどんなMIME読者も構成するのがこの用法のどんな具体的な実例に関しても、簡単になるからです。 今までにまさしく名前についてというよりむしろ名前空間の登録を許すためにMIMEの種類登録規則を変えるなら、「x」を削除できます、そして、タイプは「アプリケーション/ftbp.n.n.n.n」であることができます。
4. User control over the gateway choice
4. ゲートウェイ選択のユーザコントロール
In some cases, the gateway may make an inappropriate choice when deciding what to do about a particular body part.
特定の身体の部分の周りで何をしたらよいかを決めるとき、いくつかの場合、ゲートウェイは不適当な選択をするかもしれません。
To allow an escape clause, this chapter defines a way in which the user can signal the gateway what action it finds most appropriate.
免責条項を許容するために、本章はユーザがゲートウェイに合図できる方法を定義します。それは、最も適切であることがどんな動作がわかりますか?
The headers given here override any "conversion prohibited" and "conversion with loss prohibited" on the message.
ここに与えられたヘッダーはメッセージで「変換は禁止した」いずれと「損失で禁止された変換」をくつがえします。
It is still the gateway's responsibility that the generated messages conform to the destination domain's syntax rules.
それでも、発生しているメッセージが目的地ドメインのシンタックス・ルールに従うのは、ゲートウェイの責任です。
DISCUSSION:
議論:
The intent of this mechanism is to allow the sender to efficiently get a message through to a single recipient when the sender has information about the recipient that the gateway does not have.
このメカニズムの意図は送付者にゲートウェイにはいない受取人の情報があるとき、送付者が効率的に独身の受取人に伝言を伝えるのを許容することです。
It is not a part of the minimum functionality listed in chapter 8; a gateway does not have to implement this spec to be MIXER conformant, but if implemented, it should be done like this.
それは第8章にリストアップされた最小の機能性の一部ではありません。 ゲートウェイはMIXER conformantになるようにこの仕様を実行する必要はありませんが、実行するなら、このようにそれをするべきです。
The additional complexity, both in user interface and in protocol, of making this field selectable per recipient was not thought worthwhile;
追加複雑さ、ユーザーインタフェースとプロトコルでは、作成では、1受取人あたり選択可能なこの分野は価値があると考えられませんでした。
4.1. Conversion from MIME to X.400
4.1. MIMEからX.400までの変換
The header field described below specifies explicit MIXER conversion. Comments are allowed within the field according to the usual RFC 822 convention.
以下で説明されたヘッダーフィールドは明白なMIXER変換を指定します。 普通のRFC822コンベンションによると、コメントは分野の中に許容されています。
If "x400-object-id" is omitted, "tunnel" is assumed.
「x400物のイド」が省略されるなら、「トンネル」は想定されます。
mime-to-x400 = "Wanted-X400-Conversion" ":"
[ mime-from ] [ x400-object-id ]
「パントマイムからx400は「欲しいX400変換」と等しい」:、」 [パントマイム、-、][x400物のイド]
Alvestrand Standards Track [Page 18] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[18ページ]RFC2157X.400/MIMEボディー
"in" x400-encoding
"in" x400-コード化
x400-object-id = "to" ( object-identifier-2 / "tunnel" )
x400-encoding = "bp14" / "bp15" / "ftbp" / "ia5"
mime-from = "from" mime-type
mime-type = word
x400をコード化しているx400物のイド=“to"(物の識別子2/「トンネル」)=、「bp14"/、「bp15"/"ftbp"/、「ia5"、パントマイム、-、=“from"パントマイムタイプパントマイムタイプ=単語、」
There is no way to ask for a different conversion based on MIME parameters or bodypart content.
MIMEパラメタかbodypart内容に基づく異なった変換を求める方法が全くありません。
Examples:
例:
Wanted-X400-Conversion: from application/msword
to 1.2.840.113556.4.2 (Microsoft defined ms-word)
in ftbp
欲しいX400変換: アプリケーション/mswordから1.2.840.113556.4.2(単語をmsする状態で定義されたマイクロソフト)までコネはftbpされます。
This uses the MAWG definitions, and leads to an FTBP encoding.
これは、MAWG定義を使用して、FTBPコード化に通じます。
Wanted-X400-Conversion: from application/msword
to tunnel in bp14
欲しいX400変換: アプリケーション/mswordからbp14のトンネルまで
This leads to a Body Part 14 encoding for all body parts of type application/msword.
これはすべてのボディーのためにタイプアプリケーション/mswordの部分をコード化するBody Part14に通じます。
Wanted-X400-Conversion: in bp14
欲しいX400変換: bp14で
This requests that this specific body part be encoded in Body Part 14.
これは、この特定の身体の部分がBody Part14でコード化されるよう要求します。
This field may be used in two places:
この分野は2つの場所に使用されるかもしれません:
(1) In the heading of an unstructured MIME body part.
In this case the EBNF.mime-from is omitted, and the
requested conversion applies to the body part.
(1) 不統一なMIME本体に関する見出しでは、離れてください。 この場合、EBNF.mime、-、省略されていて変換が身体の部分に付ける要求です。
(2) In a multipart. In this case, the body part type to
which the conversion applies is defined by
EBNF.mime-from, and the conversion applies to all
body parts of this MIME type contained in the
multipart, including those contained in nested
messages and multiparts. If a contained body part
has its own heading, this takes precedence. Note
that the "from" parameter is mandatory when used in
a multipart.
a複合の(2)。 この場合変換が適用されるボディー部分タイプが定義される、EBNF.mime、-、変換は入れ子にされたメッセージと「マルチ-部品」に含まれたものを含む複合に含まれたこのMIMEの種類のすべての身体の部分に適用されます。 含まれた身体の部分にそれ自身の見出しがあるなら、これは優先します。 a複合で使用されると“from"パラメタが義務的であることに注意してください。
The EBNF.x400-object-id shall be present when "bp15" or "ftbp" encoding is selected.
「bp15"か"ftbp"コード化は選択される」とき、EBNF.x400物のイドが存在するでしょう。
Alvestrand Standards Track [Page 19] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[19ページ]RFC2157X.400/MIMEボディー
The value "tunnel" implies encapsulation as defined in Chapter 3.
第3章で定義されて、「トンネル」がカプセル化を含意する値。
The "object identifier" used below is:
以下で使用された「物の識別子」は以下の通りです。
- For BP 15, it is the value of the EXTENDED-BODY-PART-
TYPE macro that defines the body part, which is found
in ExternallyDefinedBodyPart.data.direct-reference.
- BP15に関しては、それはExternallyDefinedBodyPart.data.direct-referenceで見つけられる身体の部分を定義するEXTENDED-BODY-PART- TYPEマクロの値です。
- For FTBP, it is the value of the
Environment.application-reference.
- FTBPに関しては、それはEnvironment.application-参照の値です。
4.2. Conversion from X.400 to MIME
4.2. X.400からMIMEまでの変換
The IPM heading defined here shall be present in the heading of a message. It defines the mapping for all body parts of the specified types, including those in nested messages.
ここで定義されたIPM見出しはメッセージに関する見出しに存在するでしょう。 それは入れ子にされたメッセージにものを含む指定されたタイプのすべての身体の部分のためのマッピングを定義します。
wanted-MIME-conversion HEADING-EXTENSION
VALUE WantedMIMEConversions
::= id-wanted-MIME-conversions
欲しいMIME変換見出し拡張子値のWantedMIMEConversions:、:= イドの欲しいMIME変換
WantedMIMEConversions ::= SEQUENCE OF X400toMIMEConversion
WantedMIMEConversions:、:= X400toMIMEConversionの系列
X400toMIMEConversion ::= SEQUENCE {
x400-type X400Type,
mime-type MIMEType }
X400toMIMEConversion:、:= 系列x400-タイプX400Type、パントマイムタイプMIMEType
X400Type ::= CHOICE {
standard [0] INTEGER, -- standard body part
extended [1] OBJECT IDENTIFIER, -- BP 15
ftbp [2] OBJECT IDENTIFIER} -- FTBP
-- application-reference
X400Type:、:= CHOICE規格[0]INTEGER(標準の身体のパートの拡張[1]OBJECT IDENTIFIER)BP15ftbp[2]OBJECT IDENTIFIER--FTBP--アプリケーション参照
MIMEType ::= SEQUENCE {
type IA5String, -- type (e.g., application/ms-word)
encoding [1] IA5String OPTIONAl -- e.g. quoted-printable
parameters [2] IA5String OPTIONAL } -- MIME Parameters
MIMEType:、:= SEQUENCEはIA5String--[1] IA5String OPTIONAlをコード化するタイプ(例えば、msアプリケーション/単語)--例えば引用されて印刷可能なパラメタ[2]IA5String OPTIONALをタイプします--、MIME Parameters
The heading extension includes all requested conversions, with explicit information as to how each body part type is encoded in MIME.
見出し拡張子はすべての要求された変換を含んでいます、それぞれのボディー部分タイプがMIMEでどうコード化されるかに関する明示的な情報で。
FTBP is identified as a separate body part type, as there will be a need for different encodings, dependent on what is being carried.
FTBPは別々のボディー部分タイプとして特定されます、異なったencodingsの必要があるので、運ばれるものに依存しています。
Alvestrand Standards Track [Page 20] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[20ページ]RFC2157X.400/MIMEボディー
Encapsulation is requested by asking for "application/x400-bp" or "application/ftbp" as the destination type.
カプセル化は、目的地タイプとして「アプリケーション/x400-bp」か「アプリケーション/ftbp」を求めることによって、要求されています。
For FTAM body parts, the parameters will survive the gatewaying process. For other body parts, there are three alternatives:
FTAM身体の部分に関しては、パラメタはgatewayingの過程を乗り切るでしょう。 他の身体の部分には、3つの選択肢があります:
(1) The gateway knows a defined mapping for this
particular body part and destination type. It will be used,
and parameters mapped accordingly.
(1) ゲートウェイはこの特定の身体の部分と目的地タイプで定義されたマッピングを知っています。 それは使用して、パラメタは写像されています。それに従って。
(2) The gateway knows how to extract an OCTET STRING
from the body part, and the destination is a simple MIME body
part. All information outside the OCTET STRING is lost. (This
may be the case for a BP14 that should end up in an
application/xyzzy, for instance).
(2) ゲートウェイは身体の部分からOCTET STRINGを抽出する方法を知っています、そして、目的地は簡単なMIME身体の部分です。 OCTET STRINGの外のすべての情報が無くなっています。 (これは例えばアプリケーション/xyzzyで終わるはずであるBP14のためのそうであるかもしれません。)
(3) The gateway knows of no relevant mapping, and does
not know how to simplify the X.400 body part. The gateway
will then proceed as if the mapping control field had not
been present.
(3) ゲートウェイは、どんな関連マッピングも知らないで、またX.400身体の部分を簡素化する方法を知りません。 そして、まるでマッピング制御フィールドが存在していなかったかのようにゲートウェイは続くでしょう。
5. The equivalence registry
5. 等価性登録
5.1. What information one must give about a mapping
5.1. 情報1がマッピングに関して与えなければならないもの
The following information MUST be supplied when describing an equivalence or a mapping:
等価性かマッピングについて説明するとき、以下の情報を提供しなければなりません:
MIME type name (which must be preregistered)
MIMEの種類名(前登録しなければなりません)
X.400 body part (often BP15 or FTAM Body Part)
X.400身体の部分(しばしばBP15かFTAM身体の部分)
If BP15 is used, the following information must be given:
BP15が使用されているなら、以下の情報を与えなければなりません:
(1) Object Identifier for X.400 BP15 Data
(1) X.400 BP15データのための物の識別子
(2) Object Identifier for X.400 BP15 Parameters
(2) X.400 BP15パラメタのための物の識別子
(3) X.400 ASN.1 Syntax (must be an EXTENDED-BODY-PART-
TYPE macro)
(3) X.400 ASN.1構文(EXTENDED-BODY-PART- TYPEマクロでなければなりません)
If FTBP is used, the following information must be given:
FTBPが使用されているなら、以下の情報を与えなければなりません:
<1) Object Identifier for the FTAM Environment.application-
reference
<1) FTAM Environment.application参照のための物のIdentifier
<2) Object Identifier for the FTAM Contents-type, if
unstructured-binary is not used
<2) FTAM Contents-タイプと、不統一なバイナリーのための物のIdentifierは使用されていません。
Alvestrand Standards Track [Page 21] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[21ページ]RFC2157X.400/MIMEボディー
(3) Any other special considerations
(3) いかなる他の特別な問題
In all cases, the following must be given:
すべての場合では、以下を与えなければなりません:
Conversion algorithms. The expected effect of "Conversion prohibited" and "Conversion with loss prohibited" should be noted.
変換アルゴリズム「禁止された変換」と「損失で禁止された変換」の期待効果は注意されるべきです。
The conversion must be specified with enough detail to permit independent implementation; literature references are acceptable.
独立している実現を可能にすることができるくらいの詳細で変換を指定しなければなりません。 文学参照は許容できます。
An equivalence can be registered with IANA using the form at the end of this document. The purpose of the registration is to achieve a greater uniformity among gateways implementing the same translation; there is no requirement that a gateway must support all of the translations that are registered with IANA, and there is no requirement that all conversions supported by a gateway are registered with IANA. Specific conformance requirements for MIXER are given at the end of this document.
このドキュメントの端でフォームを使用するIANAに等価性を示すことができます。 登録の目的は同じ翻訳を実行しながらゲートウェイの中で、より大きい一様性を達成することです。 ゲートウェイがIANAに登録される翻訳のすべてを支持しなければならないという要件が全くありません、そして、ゲートウェイで後押しされているすべての変換がIANAに登録されるという要件が全くありません。 このドキュメントの端でMIXERのための特定の順応要件を与えます。
Anyone can register an equivalence with IANA, and may update the registered equivalence at any time, or reassign the right to update the registry entry at any time. However, the IESG has the power to "lock" a registration, so that changing it requires IESG approval, and to update such a "locked" registration. All registered equivalences defined in standards-track documents (including this one) are locked.
だれでも、等価性をIANAに示すことができて、いつでも登録された等価性をアップデートするか、またはいつでも、登録エントリーをアップデートする権利を再選任するかもしれません。 しかしながら、IESGには、それを変えるのがIESG承認を必要とするように登録を「ロックし」て、そのような「ロックされた」登録をアップデートするパワーがあります。 標準化過程文書(これを含んでいる)で定義されたすべての登録された等価性がロックされます。
5.2. Equivalence summary for known X.400 and MIME Types
5.2. 知られているX.400とMIMEの種類のための等価性概要
This section itemizes the equivalences for all currently known MIME content-types and X.400 body parts.
このセクションはすべての現在知られているMIME満足しているタイプとX.400身体の部分に等価性を箇条書きします。
For each MIME content-type/X.400 body part pair, the equivalence table contains an entry with the following sections:
それぞれのMIME満足しているタイプ/X.400ボディー部分組のために、等価性テーブルは以下のセクションによるエントリーを含んでいます:
X.400 Body Part
This section identifies the X.400 Body Part governed by this
Table entry. It includes any OBJECT IDENTIFIERs or other
parameters necessary to uniquely identify the Body Part.
X.400ボディーPart This部はこのTableエントリーで治められたX.400 Body Partを特定します。 それは唯一Body Partを特定するのに必要などんなOBJECT IDENTIFIERsや他のパラメタも含んでいます。
MIME Content-Type
This section identifies the MIME content-type governed by this
Table entry. The MIME content-type named here must be
registered with the IANA.
MIMEコンテントタイプThis部はこのTableエントリーで決定されたMIMEの満足しているタイプを特定します。 ここで指定されたMIMEの満足しているタイプをIANAに示さなければなりません。
Section/document reference
Reference to section of this document, or to the other document
that describes this mapping.
このドキュメントのセクション、またはこのマッピングについて説明するもう片方のドキュメントのセクション/ドキュメント参照Reference。
Alvestrand Standards Track [Page 22] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[22ページ]RFC2157X.400/MIMEボディー
The initial Equivalence Table entries in this document are described using this convention.
初期のEquivalence Tableエントリーは、このコンベンションを使用することで本書では説明されます。
Further registrations of equivalences should be submitted to the IANA after a public review, using the example form given at the end of this document.
公開レビューの後に等価性のさらなる登録証明書をIANAに提出するべきです、このドキュメントの端で与えられた例の書式を使用して。
5.3. MIME to X.400 Table
5.3. X.400テーブルにまねてください。
MIME content-type X.400 Body Part Section
----------------- ------------------ -------
text/plain
charset=us-ascii ia5-text 6.1
charset=ISO-8859-x EBP - GeneralText 6.2
text/richtext no mapping defined Encap
application/oda EBP - ODA [ODA]
application/octet-stream bilaterally-defined or 6.3
FTBP unknown attachment 6.4
application/postscript EBP - mime-postscript-body [POSTSCRIPT]
image/g3fax g3-facsimile [IMAGES]
image/jpeg EBP - mime-jpeg-body [IMAGES]
image/gif EBP - mime-gif-body [IMAGES]
audio/basic no mapping defined Encap
video/mpeg no mapping defined Encap
message/RFC822 ForwardedIPMessage 6.5
multipart/* ForwardedIPMessage 6.6
multipart/signed HARPOON encap 7.3
multipart/encrypted HARPOON encap 7.4
MIME満足しているタイプX.400 Body Partセクション----------------- ------------------ ------- 明瞭なcharset=私たちテキスト/ASCII ia5-テキスト6.1charset=ISO-8859-x EBP--定義されたEncapアプリケーション/oda EBPを写像しないGeneralText6.2テキスト/richtext--八重奏アプリケーション/流れが相互的に定義したODA ODAか6.3のFTBPの未知の付属6; 4アプリケーション/追伸EBP--パントマイム追伸ボディーPOSTSCRIPT g3fax g3イメージ/ファクシミリイメージズイメージ/jpeg EBP--パントマイムjpegボディーイメージズイメージ/gif EBP--写像でないのが定義したパントマイムgifボディーのマッピングの定義されたEncapイメージズのオーディオ的、または、基本的なノービデオ/mpeg Encapメッセージ/RFC822 ForwardedIPMessage6.5の複合/*ForwardedIPMessage6.6の複合の、または、サインされたHARPOON encap7.3の複合の、または、コード化されたHARPOON encap7.4
Abbreviation: EBP - Extended Body Part
略語: EBP--拡張身体の部分
5.4. X.400 to MIME Table
5.4. テーブルをまねるX.400
Basic Body Parts
基本的なボディ・パーツ
X.400 Basic Body Part MIME content-type Section --------------------- -------------------- ------- ia5-text text/plain;charset=us-ascii 6.1 voice No Mapping Defined Encap g3-facsimile image/g3fax [IMAGES] g4-class1 no mapping defined Encap teletex text/plain;charset=teletex 6.7 videotex no mapping defined Encap encrypted no mapping defined Encap bilaterally-defined application/octet-stream 6.3 nationally-defined no mapping defined Encap externally-defined See Extended Body Parts below
X.400の基本的なBody Part MIME満足しているタイプセクション--------------------- -------------------- ------- ia5-テキストテキスト/平野; charsetするのが私たちと等しい、-ASCII6.1は写像でないのが定義したMapping Defined Encap g3-ファクシミリがないイメージ/g3fax[イメージズ]g4-class1Encapテレテックステキスト/平野を声に出します; 定義されたEncapを写像しないマッピングの定義された=テレテックス6.7ビデオテックスノーEncapがコード化したcharsetが相互的に以下のマッピングの定義された6.3の全国的に定義されたノーEncapが外部的に定義した八重奏アプリケーション/流れのSee Extendedボディ・パーツを定義しました。
Alvestrand Standards Track [Page 23] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[23ページ]RFC2157X.400/MIMEボディー
ForwardedIPMessage message/RFC822 or multipart 6.5,6.6
ForwardedIPMessageメッセージ/RFC822か複合6.5、6.6
X.400 Extended Body Part MIME content-type Section ------------------------- -------------------- ------- GeneralText text/plain;charset=ISO-8859-x 6.2 ODA application/oda [ODA] mime-postscript-body application/postscript [POSTSCRIPT] mime-jpeg-body image/jpeg [IMAGES] mime-gif-body image/gif [IMAGES] FTAM various 2.3,6.4
X.400はBody Part MIME満足しているタイプセクションを広げました。------------------------- -------------------- ------- GeneralTextテキスト/平野; charset=ISO-8859-x6.2ODA oda[ODA]パントマイム追伸アプリケーション/ボディーアプリケーション/追伸[POSTSCRIPT]パントマイムjpegホディー・イメージ/jpeg[イメージズ]パントマイムgifホディー・イメージ/gif[イメージズ]のFTAMの様々な2.3、6.4
FTAM application ID MIME content type Section ------------------- ----------------- ------- ema-unknown-attachment application/octet-stream 6.4
FTAMアプリケーションID MIME内容タイプセクション------------------- ----------------- ------- emaの未知の付属八重奏アプリケーション/流れの6.4
5.5. Use of OBJECT IDENTIFIERs and ASN.1 MACROS
5.5. 物の識別子とASN.1マクロの使用
When one wants to define new BP15 body parts for use with equivalences, it is important to know that X.420 dictates that Extended Body Parts shall:
人が使用のために等価性で新しいBP15身体の部分を定義したがっているとき、X.420が、Extendedボディ・パーツがそうすると決めるのを知るのは重要です:
(1) use OBJECT IDENTIFIERs (OIDs) to uniquely identify
the contents, and
そして(1) OBJECT IDENTIFIERs(OIDs)を使用して、唯一コンテンツを特定してください。
(2) be defined by using the ASN.1 Macro:
(2) ASN.1Macroを使用することによって、定義されてください:
EXTENDED-BODY-PART-TYPE MACRO::=
BEGIN
TYPE NOTATION ::= Parameters Data
VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
拡張ボディー部分タイプマクロ:、:= タイプ記法を始めてください:、:= パラメタデータは記法を評価します:、:= 値(値の物の識別子)
Parameters ::= "PARAMETERS" type "IDENTIFIED"
"BY" value(OBJECT IDENTIFIER)
| empty;
Data ::= "DATA" type
END
パラメタ:、:= 「PARAMETERS」タイプは“BY"値(物の識別子)を「特定しました」。| 空になってください。 データ:、:= "DATA"はENDをタイプします。
To meet these requirements, this document uses the OID
これらの必要条件を満たすために、このドキュメントはOIDを使用します。
mixer
ミキサー
defined in [MIXER], as the root OID for X.400 Extended Body Parts defined for MIME interworking.
[MIXER]では、MIMEの織り込むために定義されたX.400 Extendedボディ・パーツのための根のOIDと定義されています。
Each Extended Body Part contains Data and optional Parameters, each being named by an OID. To this end, two OID subtrees are defined under mixer-bodies, one for Data, and the other for Parameters:
OIDによってそれぞれ命名されて、各Extended Body PartはDataと任意のParametersを含んでいます。 このために、2つのOID下位木がミキサーボディー、Dataのための1つ、およびParametersのためのもう片方の下で定義されます:
Alvestrand Standards Track [Page 24] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[24ページ]RFC2157X.400/MIMEボディー
mixer-bp-data OBJECT IDENTIFIER ::=
{ mixer 1 }
ミキサーbpデータOBJECT IDENTIFIER:、:= ミキサー1
mixer-bp-parameter OBJECT IDENTIFIER ::=
{ mixer 2 }
ミキサーbpパラメタOBJECT IDENTIFIER:、:= ミキサー2
All definitions of extended X.400 body parts submitted to the IANA for registration with a mapping must use the Extended Body Part Type macro for the definition. See [IMAGES] for an example.
登録のためにマッピングでIANAに提出された拡張X.400身体の部分のすべての定義が定義にExtended Body Part Typeマクロを使用しなければなりません。 例に関して[イメージズ]を見てください。
Lastly, the IANA will use the mixer-bp-data and mixer-bp-parameter OIDs as root OIDs for any new MIME content-type/subtypes that aren't otherwise registered in the Equivalence Table.
最後に、IANAはどんな新しいMIME満足しているタイプ/血液型亜型のための別の方法でEquivalence Tableに登録されない根のOIDsとしてもミキサーbpデータとミキサーbpパラメタOIDsを使用するでしょう。
NOTE: The ASN.1 for an ExternallyDefinedBodyPart is
以下に注意してください。 ExternallyDefinedBodyPartのためのASN.1はそうです。
ExternallyDefinedBodyPart ::= SEQUENCE {
parameters [0] ExternallyDefinedParameters OPTIONAL,
data ExternallyDefinedData }
ExternallyDefinedBodyPart:、:= 系列パラメタ[0]ExternallyDefinedParameters OPTIONAL、データExternallyDefinedData
ExternallyDefinedParameters ::= EXTERNAL
ExternallyDefinedParameters:、:= 外部
ExternallyDefinedData ::= EXTERNAL
ExternallyDefinedData:、:= 外部
The ASN.1 for EXTERNAL is (from X.208):
EXTERNALのためのASN.1はこと(X.208から)です:
EXTERNAL ::= [UNIVERSAL 8] IMPLICIT SEQUENCE
{direct-reference OBJECT IDENTIFIER OPTIONAL,
indirect-reference INTEGER OPTIONAL,
data-value-descriptor ObjectDescriptor OPTIONAL,
encoding CHOICE
{single-ASN1-type [0] ANY,
octet-aligned [1] IMPLICIT OCTET STRING,
arbitrary [2] IMPLICIT BIT STRING}}
外部:、:= [普遍的な8] 暗黙の系列直接的な言及OBJECT IDENTIFIER OPTIONAL、間接的な言及INTEGER OPTIONAL、CHOICEをコード化するデータ値の記述子ObjectDescriptor OPTIONAL、[0] 独身のASN1がタイプしているいずれ、八重奏で並べられた[1]IMPLICIT OCTET STRING、任意の[2]IMPLICIT BIT STRING
ObjectDescriptor ::= [UNIVERSAL 7] IMPLICIT GraphicString
ObjectDescriptor:、:= [普遍的な7] 内在しているGraphicString
There are a bit too many choices here; the common X.400 usage for BP15 encoding is to:
少しあまりに多くの選択がここにあります。 BP15コード化のための一般的なX.400用法は以下のことのためのことです。
(1) Always use direct-reference
(1) いつも直接的な言及を使用してください。
(2) Omit indirect-reference and data-value-descriptor
(2) 間接的な言及とデータ値の記述子を省略してください。
(3) Use the single-ASN1-type encoding only
(3) 独身のASN1がタイプしているコード化だけを使用してください。
Alvestrand Standards Track [Page 25] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[25ページ]RFC2157X.400/MIMEボディー
Unfortunately, some implementations have chosen to use the octet- aligned choice when constructing values where the ASN.1 type is OCTET STRING, which of course caused interoperability problems.
ASN.1がタイプする値を構成するのが、OCTET STRINGであるときに、残念ながら、いくつかの実現が、八重奏の並べられた選択を使用するのを選びました。(もちろん、OCTET STRINGは相互運用性問題を引き起こしました)。
An attempt to specify that X.420 only allowed the single-ASN1-type choice in the 1996 versions is still (Sept 1995) being debated in ISO; the end result seems to be that all agree in principle that single-ASN1-type should be used, but that one has to allow the generation of the octet-aligned choice as being conformant.
それでも(1995年9月)、X.420が1996年のバージョンにおける独身のASN1がタイプしている選択を許しただけであると指定する試みはISOで討論することにされます。 結末はすべてが、単独のASN1タイプが使用されるべきですが、1つがconformantであるとして八重奏で並べられた選択の世代を許容しなければならないのに原則的に同意するということであるように思えます。
6. Defined Equivalences
6. 定義された等価性
6.1. IA5Text - text/plain
6.1. IA5Text--テキスト/平野
X.400 Body Part: IA5Text MIME Content-type: text/plain; charset=US- ASCII Conversion Type: No conversion Comments:
X.400身体の部分: IA5Textは文書内容をまねます: テキスト/平野。 charsetは米国のASCIIの転換型と等しいです: 変換がないComments:
When mapping from X.400 to MIME, the "repertoire" parameter is ignored.
X.400からMIMEまで写像するとき、「レパートリー」パラメタは無視されます。
When mapping from MIME to X.400, the "repertoire" parameter is set to IA5 (5).
MIMEからX.400まで写像するとき、「レパートリー」パラメタはIA5(5)に設定されます。
NOTE: The MIME Content-type headers are omitted, when mapping from X.400 to MIME, if and only if the IA5Text body part is the only body part in the IPMS.Body sequence.
以下に注意してください。 X.400からMIMEまで写像するとき、MIME文書内容ヘッダーが省略される、IA5Textが部分を具体化させる場合にだけ、中のボディーが分けるIPMS.Bodyが配列する唯一はそうです。
NOTE: IA5Text specifies the "currency" symbol in position 2/4. This is converted without comment to the "dollar" symbol, since the author of this document has seen many documents in which the position was intended to indicate "dollar" while he has not yet seen one in which the "currency" symbol is intended.
以下に注意してください。 IA5Textは位置2/4で「通貨」シンボルを指定します。 これはコメントなしで「ドル」シンボルに変換されます、このドキュメントの作者が位置が彼がまだ、「通貨」シンボルが意図するものを見ていない間、「ドル」を示すことを意図した多くのドキュメントを見たので。
(For reference: The T.50 (1988) recommendation, which defines IA5, talks about ISO registered set number 2, while ASCII, using the "dollar" symbol, is ISO registered set number 6. There are no other differences.)
(参照のために: IA5を定義するT.50(1988)推薦、ISOの周りの会談はセットNo.2を示して、「ドル」シンボルを使用して、ASCIIはISOですが、そこの登録されたセットNo.6は他の違いではありません。)
NOTE: It is not uncommon, though it is a violation of the standard, to use 8-bit character sets inside an IA5 body part. Gateways that can expect to encounter this situation should consider implementing something like the guidance given in RFC 1428 [MIMETRANS], "Transition of Internet Mail from just-send-8 to 8-bit SMTP/MIME", and generate appropriate charset parameters for the MIME messages they generate. This behavior is not required for MIXER conformance, since it is only needed when the base standards are violated.
以下に注意してください。 それは珍しくはありません、それがIA5身体の部分の中で8ビットの文字の組を使用するためには規格の違反ですが。 この状況に遭遇すると予想できるゲートウェイは、RFC1428[MIMETRANS]、「ただ8ビットに8を送っているSMTP/MIMEからのインターネットメールの変遷」で与えられた指導のように実行すると考えて、それらが発生させるMIMEメッセージのための適切なcharsetパラメタを発生させるはずです。 ベース規格が違反されるときだけ、それが必要であるので、この振舞いはMIXER順応に必要ではありません。
Alvestrand Standards Track [Page 26] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[26ページ]RFC2157X.400/MIMEボディー
6.2. GeneralText - text/plain (ISO-8859)
6.2. GeneralText--テキスト/平野(ISO-8859)
X.400 Body Part: GeneralText; CharacterSets in
6, 14, 42, 87, 100,101,109,110,126,127,138,144,148
MIME Content-Type: text/plain; charset=ISO-8859-(1-9)
or iso-2022-jp
Conversion Type: Text conversion without character change When
mapping from X.400 to MIME, the character-set is chosen from the
table below according to the value of Parameters.CharacterSets. If no
match is found, and the gateway does not support a conversion, the
character set shall be encoded as x-iso-nnn-nnn-nnn, where "nnn" is
the numbers of the Parameters.CharacterSets, sorted in numeric order.
X.400身体の部分: GeneralText。 6、14、42、87、100,101,109,110,126,127,138,144,148におけるキャラクタセットはコンテントタイプをまねます: テキスト/平野。 charset=ISO-8859-(1-9)かiso-2022-jp Conversion Type: X.400からMIMEまでのキャラクタ変化Whenマッピングのないテキスト変換、Parameters.CharacterSetsの値に従って、文字の組は以下のテーブルから選ばれています。 マッチが全く当たられないで、またゲートウェイが変換を支持しないなら、文字の組は"nnn"がParameters.CharacterSetsの数であるところで番号順で分類されたx-iso-nnn-nnn-nnnとしてコード化されるものとします。
When mapping from MIME to X.400, GeneralText is an Extended Body
Part, hence it requires an OID. The OID for the GeneralText body is
defined in [MOTIS], part 8, annex D, as {2 6 1 4 11}. The OID for the
parameters is {2 6 1 11 11}.
MIMEからX.400まで写像するとき、GeneralTextがExtended Body Partである、したがって、それはOIDを必要とします。 GeneralTextボディーのためのOIDが[MOTIS]、パート8で定義されて、別館がDである、2 6 1 4、11 パラメタのためのOIDがそうである、2 6 1、11 11
The Parameters.CharacterSets is set from table below according to the value of "charset"
"charset"の値に従って、Parameters.CharacterSetsは以下のテーブルから用意ができています。
The following table lists the MIME character sets and the corresponding ISO registry numbers. If no correspondence is found, this conversion fails, and the generic body part approach is used.
以下のテーブルはMIME文字の組と対応するISO登録番号を記載します。 通信が全く見つけられないなら、この変換は失敗します、そして、一般的なボディー部分アプローチは使用されています。
MIME charset ISO IR numbers Comment ----------------------------------------------- ISO-8859-1 6, 100 West European "8-bit ASCII" ISO-8859-2 6, 101 East European ISO-8859-3 6, 109 <regarded as obsolete> ISO-8859-4 6, 110 <regarded as obsolete> ISO-8859-5 6, 144 Cyrillic ISO-8859-6 6, 127 Arabic ISO-8859-7 6, 126 Greek ISO-8859-8 6, 138 Hebrew ISO-8859-9 6, 148 Other Latin-using languages ISO-2022-JP 6, 14, 42, 87 Japanese
MIME charset ISO IR数のComment----------------------------------------------- ISO-8859-1 6、100の西ヨーロッパの「8ビットのASCII」ISO-8859-2 6、101の東ヨーロッパのISO-8859-3 6、109<は>ISO-8859-4 6、<が見なした>ISO-8859-5 6を時代遅れにするのと同じくらい時代遅れの110を見なしました、144キリール文字ISO-8859-6 6、127のアラビアのISO-8859-7 6、126のギリシアのISO-8859-8 6、138のヘブライのISO-8859-9 6、148のラテン語を使用するOther言語2022年のISO JP6、14、42、87人の日本人
When converting from MIME to X.400, generate the correct OIDs for use
in the message envelope's Encoded Information Types by looking up the
ISO IR numbers in the above table, and then appending each to the
id-cs-eit-authority {1 0 10021 7 1 0} OID, generating 2-4 OIDs.
MIMEからX.400まで変換するときにはメッセージ封筒のEncoded情報Typesにおける使用のために上のテーブルでISO IR番号を調べて、次に、イドCs eit権威にそれぞれ添えることによって正しいOIDsを発生させてください、1 0、10021、7 1 0、OID(発生2-4OIDs)
Similar procedures can be used with other MIME charsets that map to a set of ISO character sets.
ISOの1セットに文字の組を写像する他のMIME charsetsと共に同様の手順を用いることができます。
Alvestrand Standards Track [Page 27] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[27ページ]RFC2157X.400/MIMEボディー
The escape sequences to designate and invoke the relevant character sets in their proper positions must be added to the front of the GeneralText character string.
それらの適切な位置に関連文字の組を指定して、呼び出すエスケープシーケンスをGeneralText文字列の前部に加えなければなりません。
For ISO 8859-1, the relevant escape sequence will be:
関連エスケープシーケンスはISO8859-1に関しては、以下の通りになるでしょう。
ESC 28 42
ASCII in G0
G0のESC28 42ASCII
ESC 2D 41
ISO-IR-100 in G1
G1のESC2D41ISO IR100
ESC 21 41
High control character set in C1
ESC21 41High制御文字はC1にセットしました。
ESC 7E
Locking shift 1 Right
ESC7E Lockingシフト1Right
These escape sequences are removed when converting from GeneralText to text/plain.
GeneralTextからテキスト/平野まで変換するとき、これらのエスケープシーケンスを取り除きます。
Note that new character sets may be defined on both the Internet side and the X.400 side; a gateway MAY choose to implement more conversions in the same fashion.
新しい文字の組がインターネット側とX.400側の両方で定義されるかもしれないことに注意してください。 ゲートウェイは、同じファッションで、より多くの変換を実行するのを選ぶかもしれません。
DISCUSSION:
議論:
The conversion of text is a problematic one, and one in which it is likely that gateways should be given wide latitude to make decisions based upon their knowledge of the user's preferences. The text given below is thought to give the best approximation to a gateway conforming to current and anticipated usage in the MIME and X.400 worlds, and is the way recommended when no knowledge of the recipient's capabilities exists.
テキストの変換は、問題の多いものと、作る広い緯度をゲートウェイに与えるべきでありそうである決定がユーザの好みに関するそれらの知識に基礎づけたものです。 以下に与えられたテキストは、電流に一致しているゲートウェイに最良近似を与えると思われて、MIMEとX.400世界で用法を予期して、受取人の能力に関する知識が全く存在しないとき推薦された道です。
The lossless changes, such as normalizing escape sequences, can be done even when "conversion-prohibited" is set. If "conversion-with- loss-prohibited" is set, translation to a character set that is not able to encode all characters cannot be done, and the message should be non-delivered with an appropriate non-delivery reason.
エスケープシーケンスを正常にすることなどのlossless変化はして、「変換で、禁止されている」と同等であるのが、セットであるということであるかもしれません。 「変換、-、-、損失で禁止される、」 すべてのキャラクタをできるというわけではないエンコードにできない文字の組にはセット、翻訳があって、メッセージは非渡された適切な非配送と共に理由であるべきです。
The common use of character sets in MIME is somewhat different from the rules given by X.400; in particular, it is common in MIME to assume that the character sets follow strict rules. For the ISO- 8859-x character sets, it is assumed that they are designated and invoked at the beginning of the text, and that no designation or invocation sequences occur within the body of the text.
MIMEにおける文字の組の一般の使用はX.400によって与えられた規則といくらか異なっています。 文字の組が厳しい規則に従うと仮定するのはMIMEで特に、一般的です。 ISO8859-x文字の組において、それらがテキストの始めに指定されて、呼び出されて、どんな名称も実施の系列もテキストのボディーの中に起こらないと思われます。
Alvestrand Standards Track [Page 28] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[28ページ]RFC2157X.400/MIMEボディー
The rules for ISO-2022-JP are given in RFC 1468 [2022-JP], and are even more particular, using a pure 7-bit encoding in which each line of text starts in ASCII.
ISO2022JPのための規則は、RFC1468[2022JP]で与えられていて、さらに特定です、各テキスト行がASCIIで始まる純粋な7ビットのコード化を使用して。
Therefore, the text must be "normalized" by going through the whole message, using a state machine or similar device to remove or rewrite all escape and shift sequences.
したがって、テキストは全体のメッセージに直面していることによって、「正常にされなければなりません」、すべてのエスケープとシフト系列を取り除くか、または書き直すのに州のマシンか同様の装置を使用して。
Appendix A gives pseudocode for such a conversion.
付録Aはそのような変換のために擬似コードを与えます。
NOTE: In 1988, the GeneralText body part was defined in ISO 10021-8 [MOTIS], and NOT in the corresponding CCITT recommendation; this was added later. Also, the parameters have been heavily modified; they should be a SET OF INTEGER in the currently valid text. Use the latest version of the standard that you can get hold of.
以下に注意してください。 1988年に、GeneralText身体の部分は対応するCCITT推薦で定義されたのではなく、ISO10021-8[MOTIS]で定義されました。 これは後で加えられました。 また、パラメタは大いに変更されました。 それらは現在有効なテキストのSET OF INTEGERであるべきです。 あなたがつかむことができる規格の最新版を使用してください。
6.3. BilaterallyDefined - application/octet-stream
6.3. BilaterallyDefined--八重奏アプリケーション/流れ
X.400 Body Part: BilaterallyDefined MIME Content-Type: Application/Octet-Stream (no parameters) Conversion Type: No conversion
X.400身体の部分: BilaterallyDefinedはコンテントタイプをまねます: 八重奏アプリケーション/流れ(パラメタがない)の変換Type: 変換がありません。
When mapping from MIME to X.400, if there are parameters present in the Content-Type: header field, they are removed.
パラメタがあれば、MIMEからX.400まで写像するときにはコンテントタイプで以下を提示してください。 ヘッダーフィールド、それらを取り除きます。
DISCUSSION:
議論:
The parameters "name" "type" and "conversions" are advisory; name and conversions are depreciated in RFC 2046.
パラメタ「名前」「タイプ」と「変換」は顧問です。 名前と変換はRFC2046で軽視されます。
The parameter "padding" changes the interpretation of the last byte of the data, but it is deemed better by the WG to delete this information than to non-deliver the body part. The "padding" parameter is rarely used with MIME.
「詰め物」というパラメタがデータの最後のバイトの解釈を変えますが、それがこの情報を削除するために、より良いとWGによって考えられる、非、配送、身体の部分。 「詰め物」パラメタはMIMEと共にめったに使用されません。
Use of BilaterallyDefined Body Parts is specifically deprecated in both 1988 and 1992 X.400. It is retained solely for backward compatibility with 1984 systems, and because it is in common use.
BilaterallyDefinedボディ・パーツの使用は1988と1992X.400の両方で明確に非難されます。 それは唯一1984台のシステムとの後方の互換性のために保有されて、共用であるからです。
6.4. FTBP EMA Unknown Attachment - application/octet-stream
6.4. FTBP EMA Unknown Attachment--八重奏アプリケーション/流れ
X.400 Body Part: FTBP EMA Unknown Attachment MIME Content-Type: Application/Octet-Stream Conversion Type: No conversion
X.400身体の部分: FTBP EMAの未知の付属MIMEコンテントタイプ: 八重奏アプリケーション/流れの転換型: 変換がありません。
Alvestrand Standards Track [Page 29] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[29ページ]RFC2157X.400/MIMEボディー
The OID for the Unknown Attachment is { joint-iso-ccitt(2)
country(16) us(840) organization(1) ema(113694) objects(2)
messaging(2) attachments(1) unknown(1) }, or
2.16.840.1.113694.2.2.1.1 for short.
Unknown AttachmentのためのOIDがそうである、共同iso-ccitt(2)国(16)、私たち、(840) 組織(1)ema(113694)が(2) (2) 付属(1)未知(1)を通信させながら反対する、2.16 .840 .1 .113694 .2 .2 .1 .1 略して。
NOTE: Previous EMA drafts gave it as { iso(1) countries(2) usa(840)
organization (1) ema (113694) objects(2) messaging(2) attachments(1)
unknown (1)}, or 1.2.840.1.113694.2.2.1.1 for short.
以下に注意してください。 前のEMA草稿はiso(1)国(2)usa(840)組織(1)ema(113694)物(2)メッセージング(2)付属(1)未知(1)、または1.2としてそれを与えました。.840 .1 .113694 .2 .2 .1 .1 略して。
The parameters for this type must be mapped according to chapter 2.3, with the following extensions for the parameters of the application/octet-stream:
第2.3章に従って、このタイプへのパラメタを写像しなければなりません、八重奏アプリケーション/流れのパラメタのための以下の拡大で:
If there is no Content-Disposition parameter with a filename, and
there is a name parameter, the FTBP.FileTransferParameters.File-
attributes.pathname is generated from this parameter. Note that
RFC 2046 recommends not using the "name" parameter.
ファイル名があるContent-気質パラメタが全くなくて、名前パラメタがあれば、FTBP.FileTransferParameters.File attributes.pathnameはこのパラメタから発生します。 RFC2046が、パラメタという「名前」を使用することを勧めないことに注意してください。
The "type", "conversions" and "padding" attributes are ignored; "type" is for human consumption; "conversions" are discouraged in RFC 2046.
「タイプ」と、「変換」と属性が「水増し」であることは無視されます。 「タイプ」が人間の消費であります。 「変換」はRFC2046でがっかりしています。
The body mapping is just copying the bytes in both directions.
ボディーマッピングはただ両方の方向にバイトをコピーしています。
6.5. MessageBodyPart - message/RFC822
6.5. MessageBodyPart--メッセージ/RFC822
X.400 body part: MessageBodyPart MIME Content-Type: message/RFC822 Conversion Type: Special
X.400身体の部分: MessageBodyPartはコンテントタイプをまねます: メッセージ/RFC822転換型: 特別番組
NOTE: If the headers of the X.400 MessageBodyPart contains the "multipart-message" heading extension with the isAMessage bit set (either explicitly or implicitly), the mapping should be to multipart/* according to section 6.6, below.
以下に注意してください。 X.400 MessageBodyPartのヘッダーがisAMessageビットがセットしたことでの(明らかかそれとなく)「複合メッセージ」見出し拡張子を含んでいるなら、下のセクション6.6によると、複合/*にはマッピングがあるべきです。
To map an IPMS.MessageBodyPart, the full X.400 -> RFC 822 mapping is recursively applied, to generate an RFC 822 Message. If present, the IPMS.MessageBodyPart.parameters.delivery-envelope is used for the MTS Abstract Service Mappings. If present, the IPMS.MessageBodyPart.parameters.delivery-time is mapped to the extended RFC 822 field "Delivery-Date:".
IPMS.MessageBodyPartを写像するなら、完全なX.400->RFC822マッピングは、RFC822Messageを発生させるように再帰的に適用されます。 存在しているなら、IPMS.MessageBodyPart.parameters.delivery-封筒はMTSの抽象的なService Mappingsに使用されます。 存在しているなら、IPMS.MessageBodyPart.parameters.delivery-timeが拡張RFC822分野に写像される、「納品日:」
When a message/RFC822 is contained within a MIME message, it is mapped to an IPMS.MessageBodyPart according to MIXER. specification. Any mappings that would have been made to the MTS Abstract Service are placed in IPMS.MessageBodyPart.parameters.delivery-envelope.
メッセージ/RFC822がMIMEメッセージの中に含まれているとき、それはMIXER仕様通りにIPMS.MessageBodyPartに写像されます。 MTSの抽象的なServiceにされたどんなマッピングもIPMS.MessageBodyPart.parameters.delivery-封筒に置かれます。
Alvestrand Standards Track [Page 30] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[30ページ]RFC2157X.400/MIMEボディー
6.6. MessageBodyPart - multipart/*
6.6. MessageBodyPart--複合/*
X.400 body part: MessageBodyPart MIME Content-Type: multipart/* Conversion Type: Special
X.400身体の部分: MessageBodyPartはコンテントタイプをまねます: 複合/*変換Type: 特別番組
NOTE: If the headers of the X.400 MessageBodyPart do not contain the "multipart-message" heading extension with the "isAMessage" flag FALSE=, the mapping should be to message/RFC822.
以下に注意してください。 X.400 MessageBodyPartのヘッダーが"isAMessage"旗のFALSE=との「複合メッセージ」見出し拡張子を含んでいないなら、メッセージ/RFC822にはマッピングがあるべきです。
A MIME multipart is a set of content-types and not a message with a set of content types. When the multipart is at the outermost MIME header, elements of the multipart are mapped directly onto IPMS.Bodypart.
A MIME複合であることは、1セットの満足しているタイプがあるメッセージではなく、1セットの満足しているタイプです。 複合が一番はずれのMIMEヘッダーにあるとき、複合の要素は直接IPMS.Bodypartに写像されます。
When the MIME multipart is not at the outermost level, it is mapped to an IPMS.MessageBodyPart containing an IPMS.Bodypart for each element of the multipart.
MIMEであるときに、複合であることは、一番はずれのレベルにおいてそうではありません、それ。複合の各要素のためのIPMS.Bodypartを含んでいて、IPMS.MessageBodyPartに写像されます。
When a nested IPMS.Message is generated from a multipart, an IPMS.heading shall always be generated. The only mandatory field is the IPMS.Heading.this-IPM message id, which shall be generated by the gateway. An IPMS.Heading.subject field shall also be generated, in order to provide useful information to non-MIME capable X.400(88) UAs and to all X.400(84) UAs. The subject field is set as follows according to the multipart subtype:
入れ子にされたIPMS.Messageがa複合から発生するとき、IPMS.headingはいつも発生するものとします。 唯一の義務的な分野がIPMS.Heading.this-IPMメッセージイドです。(そのイドはゲートウェイで発生するものとします)。 また、IPMS.Heading.subject分野は発生するものとします、非MIMEのできるX.400(88) UAsと、そして、すべてのX.400(84) UAsに役に立つ情報を供給するために。 複合「副-タイプ」に従って、対象の分野は以下の通り設定されます:
mixed:
"Multipart Message"
混ぜられる: 「複合メッセージ」
alternative:
"Alternative Body Parts containing the same information"
代替手段: 「同じ情報を含む代替のボディ・パーツ」
digest:
"Message Digest"
以下を読みこなしてください。 「メッセージダイジェスト」
parallel:
"Body Parts interpreted in parallel"
以下に沿ってください。 「平行で解釈されたボディ・パーツ」
other:
"Multipart Message (<subtype>)"
他: 「複合メッセージ(<「副-タイプ」>)」
For other types of multipart, the multipart subtype shall be included in the subject line.
複合の他のタイプにおいて、複合「副-タイプ」は件名に含まれているものとします。
For each multipart, the following IPMS.HeadingExtension shall be generated, with the value set according to the subtype.
それぞれに関しては、複合であり、「副-タイプ」に応じて、以下のIPMS.HeadingExtensionは選択値群で発生するものとします。
Alvestrand Standards Track [Page 31] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[31ページ]RFC2157X.400/MIMEボディー
If the multipart is the outermost multipart, and the subtype is "mixed", it may be omitted.
複合であるなら、一番はずれは複合です、そして、「副-タイプ」が「混ぜられ」て、それは省略されるかもしれません。
multipart-message HEADING-EXTENSION
VALUE MultipartType
::= id-hex-multipart-message-v2
複合メッセージHEADING-EXTENSION VALUE MultipartType:、:= イドは複合メッセージv2に魔法をかけます。
MultipartType ::= SEQUENCE {
subtype IA5String,
isAMessage BOOLEAN DEFAULT TRUE }
MultipartType:、:= 系列subtype IA5String、isAMessage BOOLEAN DEFAULT TRUE
The MultipartType contains the subtype, for example "digest". If this heading is present when mapping from X.400 to MIME, the appropriate multipart may be generated.
MultipartTypeは「副-タイプ」、例えば、「ダイジェスト」を含んでいます。 X.400からMIME、適切になりまで写像するとき、この見出しが存在している、複合、発生するかもしれません。
The isAMessage flag is needed because of the case where a message contains a ForwardedIPMessage, which itself was generated from a MIME message that was a Multipart; it is set whenever the multipart is the outermost level of nesting inside a Message/RFC822.
isAMessage旗がメッセージがMultipartであったMIMEメッセージからそれ自体で発生したForwardedIPMessageを含むケースのために必要です。 それは複合がMessage/RFC822の中の一番はずれのレベルの巣篭もりであるときはいつも、設定されます。
NOTE:
When downgrading to X.400/84, the content-type SHOULD be
regenerated from this heading-extension and put into the RFC-822-
HEADERS extra body part.
以下に注意してください。 X.400/84に格下げするとき、満足しているタイプのSHOULDのこの見出し拡張子から作り直された、RFC-822に入れられたHEADERSの余分な身体の部分です。
NOTE:
This definition is different from the one in RFC 1494, because the
RFC 1494 definition turned out to be insufficient when new
subtypes of Multipart (like Signed or Related) were defined. That
is the reason for the "-v2" part of the name of the OID.
以下に注意してください。 この定義はRFC1494のものと異なっています、RFC1494定義がMultipart(Signedや関連であることのように)の新しい血液型亜型が定義されたとき、不十分であると判明したので。 それは「OIDという名前の-v2"部分」の理由です。
If both the old and the new heading extensions occur on a message,
a MIXER gateway should give preference to the new one.
老人と新しい見出し拡張子の両方がメッセージに起こるなら、MIXERゲートウェイは新しい方に優先を与えるはずです。
6.7. Teletex - Text/Plain (Teletex)
6.7. テレテックス--テキスト/平野(テレテックス)
X.400 Body Part: Teletex MIME Content-Type: text/plain; charset=Teletex Conversion Type: Text conversion
X.400身体の部分: テレテックスMIMEコンテントタイプ: テキスト/平野。 charsetはテレテックス転換型と等しいです: テキスト変換
From X.400 to RFC-822, the conversion shall take the bytes of all the pages in the "data" part of the TeletexBodyPart, add a FF character (0x0C, control-L) to each part that does not already end in one, and concatenate them together to form the body of the Text/Plain.
X.400からRFC-822まで、変換はTeletexBodyPartの「データ」部分のすべてのページの何バイトも取るものとします、とText/平野のボディーを形成するために一緒に既に1つに終わって、それらを連結しない各部分へのFFキャラクタ(0x0C、コントロールL)は言い足します。
Alvestrand Standards Track [Page 32] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[32ページ]RFC2157X.400/MIMEボディー
The character set shall be "Teletex", which is especially registered for this purpose. Its definition is shown in an appendix.
文字の組はこのために特に登録される「テレテックス」でしょう。 定義は付録に示されます。
The parameters are discarded.
パラメタは捨てられます。
From RFC-822 to X.400, the conversion shall split the content at each occurrence of the FF character (0x0C), delete the character and construct the Teletex body part as a SEQUENCE OF TeletexString, as described in X.420(88), section 7.3.5
変換は、SEQUENCE OF TeletexStringとしてRFC-822からX.400まで、FFキャラクタ(0x0C)の各発生のときに内容を分けて、キャラクタを削除して、Teletex身体の部分を構成するものとします、X.420(88)、セクション7.3.5で説明されるように
The TeletexParameters may, but need not, contain the number-of-pages component.
しかし、TeletexParametersがそうするかもしれない、ページ数成分を含まなければならなくなってください。
NOTE: It is recommended, but not mandated, that the data be converted into a more widespread character set like ISO-8859-1 or ISO-2022-JP (if applicable) if possible. This will result in the reverse translation giving a GeneralText body part, which will have to be dealt with appropriately at the X.400/88 to X.400/84 downgrading boundary, if possible, but will give a much greater chance that the MIME recipient can actually read the message.
以下に注意してください。 推薦されますが、できれば、データがISO-8859-1やISO2022JPのような、より広範囲の文字の組に変換されるのと(適切)であることが強制されません。 これはX.400/88で適切に境界を格下げするX.400/84に対処されなければならないGeneralText身体の部分を与える逆の翻訳をもたらすでしょう、できればMIME受取人が実際にメッセージを読むことができるというはるかに大きい機会を与えて。
DISCUSSION:
議論:
The Teletex body part is frequently used in X.400(84) to send around text with slightly extended character sets beyond ASCII.
Teletex身体の部分は、わずかに拡張している文字の組と共にテキストの周りでASCIIを超えて発信するのにX.400(84)で頻繁に使用されます。
Its body consists of a series of "pages", separated by ASN.1 representation. It is important to many people to have this mapped into something that is readable to most end-users; therefore, it is recommended to map this onto Text/Plain; however, since this is not plain text, the conversion must be specified.
ボディーはASN.1表現で切り離された一連の「ページ」から成ります。 多くの人々にとって、ほとんどのエンドユーザにとって、何か読み込み可能なものにこれを写像させるのは重要です。 したがって、Text/平野にこれを写像するのはお勧めです。 しかしながら、これがプレーンテキストでないので、変換を指定しなければなりません。
Note that the definition of Text/Plain permits only CRLF as a line separator; the sequences "CR FF" and "CR LF LF LF.." permitted in Teletex must be encoded as Quoted-Printable.
Text/平野の定義がラインセパレータとしてCRLFだけを可能にすることに注意してください。 系列「CR ff」と中で受入れられた"CR LF LF LF"テレテックスはそうであるに違いありません。引用されて印刷可能であるとして、コード化されます。
7. Body parts where encapsulation is recommended
7. カプセル化がお勧めである身体の部分
Some body parts are MIME constructs, and their functionality will be severely damaged if they are coerced into an X.400 framework.
いくつかの身体の部分がMIME構造物です、そして、それらがX.400枠組みに強制されると、それらの機能性はひどく傷つけられるでしょう。
Special care needs to be taken with these; they are described below.
特別な注意は、これらで取られる必要があります。 それらは以下で説明されます。
Alvestrand Standards Track [Page 33] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[33ページ]RFC2157X.400/MIMEボディー
7.1. message/external-body
7.1. 外部のメッセージ/ボディー
The gateway MUST support the encapsulation of this body part using the HARPOON encapsulation (IA5).
HARPOONカプセル化(IA5)を使用して、ゲートウェイはこの身体の部分のカプセル化を支持しなければなりません。
It MAY support some kind of retrieval of the referred object.
それは参照された物のある種の検索を支持するかもしれません。
DISCUSSION:
議論:
The message/external-body part points to an object that can be retrieved using Internet protocols.
外部のメッセージ/身体の部分はインターネットプロトコルを使用することで検索できる物を示します。
There are three cases to consider for the recipient's capabilities:
受取人の能力のために考える3つのケースがあります:
(1) The user has no Internet access. In this case, the
user might be grateful if the gateway fetches the body part and
inserts it into the message. If the body part is large or
dynamic, it might not be appropriate.
(1) ユーザには、インターネット・アクセスが全くありません。 この場合、ゲートウェイがボディーに部分をとって来て、それをメッセージに挿入するなら、ユーザはありがたく思うかもしれません。 身体の部分がかなりである、またはダイナミックであるなら、適切でないかもしれません。
(2) The user has Internet access, but no UA support for
fetching external-body objects.
(2) インターネット・アクセスを持っていますが、ユーザは魅惑的な外部のボディー物のどんなUAサポートも持っていません。
(3) The user has Internet access and UA support for
fetching external-body objects, based on an understanding of
this document.
(3) ユーザには、このドキュメントの理解に基づいて魅惑的な外部のボディー物のインターネット・アクセスとUAサポートがあります。
Some access-types, like anonymous FTP, are easy to resolve. Others, like the Mailserver access-type, are almost impossible to resolve at a gateway.
アクセス型の中には決議するのが公開FTPのように簡単である人もいます。 Mailserverアクセス型のように、他のものはゲートウェイで決議するのがほとんど不可能です。
To support the second case above, the tunneling method chosen is the HARPOON encapsulation described in section 3.1.3, using an IA5 body part, inserting the string "MIME-Version: 1.0 (generated by gateway)" at the beginning of the body part. (The part in parentheses can be changed at will).
選ばれたトンネリング方法は2番目のケースを支えるためには、上では、セクション3.1.3で説明されたHARPOONカプセル化です、IA5身体の部分を使用して、ストリングを挿入して「MIMEバージョン:」 ボディーの始めの「1.0(ゲートウェイで、発生される)」は離れています。 (括弧の部分を自由自在に変えることができます。)
This will:
これはそうするでしょう:
(1) Maximize the chance that the user will see the
message
(1) ユーザがメッセージを見るという機会を最大にしてください。
(2) Give the user hints that will enable him to fetch
the message using other Internet tools
(2) 彼がメッセージをとって来るのを他のインターネット・ツールを使用することで可能にするユーザヒントをお願いします
(3) Identify the message as a MIME object in a reliable
fashion, allowing UAs to support the fetching of the object if
the UA implementor desires.
(3) MIME物として信頼できるファッションでメッセージを特定してください、UA作成者願望であるならUAsが物をとって来ることを支持するのを許容して。
Alvestrand Standards Track [Page 34] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[34ページ]RFC2157X.400/MIMEボディー
7.2. message/partial
7.2. メッセージ/部分的です。
This represents part of a larger message, where it is only possible to parse the complete message after getting all the pieces.
これは、より大きいメッセージの一部を表します。(そこでは、すべての断片を得た後に単に完全なメッセージを分析するのが可能です)。
The gateway MUST support the encapsulation of this body part.
ゲートウェイはこの身体の部分のカプセル化を支持しなければなりません。
It MAY implement transparent reassembly of the message, but in this
case, it MUST support a configurable timeout
for the reassembly, defaulting back to encapsulation.
メッセージの透明な再アセンブリを実行するかもしれませんが、この場合再アセンブリのために構成可能なタイムアウトを支持しなければなりません、カプセル化をデフォルトとして戻って。
DISCUSSION:
議論:
The gateway's choices are:
ゲートウェイの選択は以下の通りです。
(1) Wait until all the pieces arrive at the gateway,
reassemble the message, and use normal processing
(1) すべての断片がゲートウェイに到着するまで、待ってください、そして、メッセージを組み立て直してください、そして、正常処理を使用してください。
(2) Encapsulate the message, using any encapsulation
method (BP15, FTAM or HARPOON).
(2) どんなカプセル化方法(BP15、FTAMまたはHARPOON)も使用して、メッセージを要約してください。
In some cases, not all pieces will arrive at the gateway; some may have been transferred through other gateways due to route changes or machine outages; some may have been lost in transit.
いくつかの場合、すべての断片がゲートウェイに到着するというわけではないでしょう。 ルート変化かマシン供給停止のため他のゲートウェイを通して或るものを移したかもしれません。 或るものはトランジットで失われたかもしれません。
7.3. multipart/signed
7.3. 複合かサインされています。
A gateway MUST implement encapsulation of multipart/signed using HARPOON.
ゲートウェイは複合の、または、サインされた使用HARPOONのカプセル化を実行しなければなりません。
The gateway MAY be configured to do other processing, as outlined in the discussion below. This is outside the scope of the standard.
ゲートウェイは、他の処理をするために以下での議論に概説されているように構成されるかもしれません。 規格の範囲の外にこれはあります。
DISCUSSION:
議論:
Gatewaying security is a problem. The gateway can basically take three approaches:
セキュリティをGatewayingするのは、問題です。 ゲートウェイは基本的に3つのアプローチを取ることができます:
- Strip the multipart/signed, leaving the bare body
part unsecured, possibly with a comment that the signature was
stripped
- むき出しの身体の部分をことによると署名を剥取ったというコメントで非安全にされたままにして、複合かサインを剥取ってください。
- Attempt to check the signature and re-signing the
message using X.400 security functions, then stripping as above
- 署名をチェックする試みとX.400セキュリティ機能を使用することでメッセージを再契約して、次に、同じくらい上に剥取ること。
- Encapsulate the message. This is the only approach
that allows end to end security, but requires MIME functionality
at the recipient.
- メッセージを要約してください。 これは終わりがセキュリティを終わらせるのを許容しますが、受取人におけるMIMEの機能性を必要とする唯一のアプローチです。
Alvestrand Standards Track [Page 35] RFC 2157 X.400/MIME Body Mapping January 1998
1998年1月を写像するAlvestrand標準化過程[35ページ]RFC2157X.400/MIMEボディー
- Replace the message content with multiple body parts,
containing first an unsecured body part and then the
encapsulated multipart/signed.
- 最初に、非安全にされた身体の部分を含んで、次に、複合/がサインした要約を含んで、メッセージ内容を複数の身体の部分に取り替えてください。
All these are valid options for a MIXER gateway.
これらはMIXERゲートウェイのための妥当な選択肢です。
Note that the encapsulation must use HARPOON, as the signature is computed on the ENCODED body part, not on the canonical representation, and HARPOON is the only encapsulation that preserves the content transfer encoding of the message.
カプセル化がHARPOONを使用しなければならないことに注意してください、署名が正準な表現で計算されるのではなく、ENCODED身体の部分の上で計算されて、HARPOONがメッセージの満足している転送コード化を保存する唯一のカプセル化であるので。
Note also that all methods except for encapsulation break end-to-end security; the recipient can place no more trust in the integrity of the message than he can place in the security of the gateway.
また、カプセル化以外のすべての方法が終わりから終わりへのセキュリティを壊すことに注意してください。 受取人は彼がゲートウェイのセキュリティに置くことができるより多くの信用をメッセージの保全に置くことができません。
7.4. multipart/encrypted
7.4. 複合かコード化されています。
A gateway MUST implement encapsulation of multipart/encrypted using HARPOON.
ゲートウェイは複合の、または、コード化された使用HARPOONのカプセル化を実行しなければなりません。
If the implementor chooses to allow other processing at the gateway, as outlined below, he/she is advised that there are grave security concerns with such a solution, since it violates the general rule of keeping decryption keys as close to the user as possible.
作成者が、ゲートウェイで他の処理を許すのを選ぶなら、その人は以下に概説されているようにそのような解決策がある荘重な安全上の配慮があると忠告されます、できるだけユーザに近く復号化キーを保つ一般的な規則に違反するので。
DISCUSSION:
議論:
There are two basic cases for a gateway:
ゲートウェイへの2つの基本的なケースがあります:
- The gateway is trusted with the user's keys. In this
case, the gateway can decrypt the message, possibly add a note
that it has done so, and gateway the unencrypted form, possibly
applying X.400 security functions, and possibly attaching a copy
of the original, encrypted material for reference. This does
nothing to protect the transfer from gateway to recipient,
unless suitable X.400-native security is applied. It also means
that the gateway must be part of the user's trusted environment.
- The gateway is trusted with the user's keys. In this case, the gateway can decrypt the message, possibly add a note that it has done so, and gateway the unencrypted form, possibly applying X.400 security functions, and possibly attaching a copy of the original, encrypted material for reference. This does nothing to protect the transfer from gateway to recipient, unless suitable X.400-native security is applied. It also means that the gateway must be part of the user's trusted environment.
- The gateway is not trusted with the recipient's keys.
In this case, encapsulation is the only approach that preserves
any information at all.
- The gateway is not trusted with the recipient's keys. In this case, encapsulation is the only approach that preserves any information at all.
The valid options for a MIXER gateway are therefore:
The valid options for a MIXER gateway are therefore:
- Decrypt the body part
- Decrypt the body part
- Encapsulate the body part
- Encapsulate the body part
Alvestrand Standards Track [Page 36] RFC 2157 X.400/MIME Body Mapping January 1998
Alvestrand Standards Track [Page 36] RFC 2157 X.400/MIME Body Mapping January 1998
- Drop the body part
- Drop the body part
The MIXER WG has shown strong preference for the encapsulation alternative, and urges anyone who thinks of buying or implementing gateway decryption to carefully evaluate this choice in light of the company's general security policy.
The MIXER WG has shown strong preference for the encapsulation alternative, and urges anyone who thinks of buying or implementing gateway decryption to carefully evaluate this choice in light of the company's general security policy.
8. Conformance requirements
8. Conformance requirements
In order to be called MIXER conformant, a gateway must implement:
In order to be called MIXER conformant, a gateway must implement:
- Encapsulation of MIME content in the FTBP body part
- Encapsulation of MIME content in the FTBP body part
- Encapsulation of X.400 body parts in the x400-bp body
part
- Encapsulation of X.400 body parts in the x400-bp body part
- Encapsulation of FTBP body parts in the
application/x-ftbp.oid body part
- Encapsulation of FTBP body parts in the application/x-ftbp.oid body part
- Encapsulation of security multiparts using HARPOON
- Encapsulation of security multiparts using HARPOON
- Text/plain <-> IA5Text
- Text/plain <-> IA5Text
- Text/plain; charset=iso-8859-* <-> GeneralText
- Text/plain; charset=iso-8859-* <-> GeneralText
- Multipart/* <-> ForwardedIPMessage
- Multipart/* <-> ForwardedIPMessage
- message/RFC822 <-> ForwardedIPMessage
- message/RFC822 <-> ForwardedIPMessage
- application/octet-stream <-> FTBP unknown
- application/octet-stream <-> FTBP unknown
- application/octet-stream <-> BilaterallyDefined
- application/octet-stream <-> BilaterallyDefined
- A configuration choice of which application/octet-
stream translation to use
- A configuration choice of which application/octet- stream translation to use
All other parts of this specification MAY be implemented by the gateway. If they are implemented at all, they MUST be implemented conformant to this specification.
All other parts of this specification MAY be implemented by the gateway. If they are implemented at all, they MUST be implemented conformant to this specification.
In this context, a feature is "implemented" in a product if it is possible to configure the product in such a way that this feature is used. This specification does not restrict the product to only be configured in such a fashion.
In this context, a feature is "implemented" in a product if it is possible to configure the product in such a way that this feature is used. This specification does not restrict the product to only be configured in such a fashion.
Alvestrand Standards Track [Page 37] RFC 2157 X.400/MIME Body Mapping January 1998
Alvestrand Standards Track [Page 37] RFC 2157 X.400/MIME Body Mapping January 1998
9. Security Considerations
9. Security Considerations
The security issues identified in this memo are:
The security issues identified in this memo are:
(1) Security implications of using filenames that
arrive in body part headers (section 2.3.2)
(1) Security implications of using filenames that arrive in body part headers (section 2.3.2)
(2) Security implications of letting a gateway handle
encrypted and/or signed content (section 7.3 and 7.4)
(2) Security implications of letting a gateway handle encrypted and/or signed content (section 7.3 and 7.4)
If a gateway fetches message/external-body on behalf of the recipient, as described in section 7.1, it may be tricked into performing inappropriate actions by malicious senders.
If a gateway fetches message/external-body on behalf of the recipient, as described in section 7.1, it may be tricked into performing inappropriate actions by malicious senders.
In addition, all the normal caveats that apply to sending data that may contain executable code apply to UAs on both sides of the gateway.
In addition, all the normal caveats that apply to sending data that may contain executable code apply to UAs on both sides of the gateway.
10. Author's Address
10. Author's Address
Harald Tveit Alvestrand UNINETT P.O.box 6883 Elgeseter N-7002 Trondheim NORWAY
Harald Tveit Alvestrand UNINETT P.O.box 6883 Elgeseter N-7002 Trondheim NORWAY
EMail: Harald.T.Alvestrand@uninett.no
EMail: Harald.T.Alvestrand@uninett.no
11. Acknowledgements
11. Acknowledgements
The author wishes to thank all the members of the MIXER WG for their valuable input, and in particular (in no particular order):
The author wishes to thank all the members of the MIXER WG for their valuable input, and in particular (in no particular order):
Steve Kille, Peter Sylvester, Ned Freed, Julian Onions, Ruth Moulton, Keith Moore, Alain Zahm, Urs Eppenberger, Kevin Jordan, Jeroen Houttuin, Claudio Allocchio, Colin Robbins, Steven Thomson, Jim Craigie, Efifiom Edem, David Wilson, and many others who have been active over the long lifetime of this document.
Steve Kille, Peter Sylvester, Ned Freed, Julian Onions, Ruth Moulton, Keith Moore, Alain Zahm, Urs Eppenberger, Kevin Jordan, Jeroen Houttuin, Claudio Allocchio, Colin Robbins, Steven Thomson, Jim Craigie, Efifiom Edem, David Wilson, and many others who have been active over the long lifetime of this document.
References
References
[RFC-822]
Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August, 1982.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August, 1982.
Alvestrand Standards Track [Page 38] RFC 2157 X.400/MIME Body Mapping January 1998
Alvestrand Standards Track [Page 38] RFC 2157 X.400/MIME Body Mapping January 1998
[MIME]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MIME-HDR]
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996.
[MIME-HDR] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[HARPOON]
Alvestrand, H., Romaguera, J., and K. Jordan, "Rules for
downgrading messages from X.400/88 to X.400/84 when MIME
content-types are present in the messages", RFC 1496, August
1993.
[HARPOON] Alvestrand, H., Romaguera, J., and K. Jordan, "Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages", RFC 1496, August 1993.
[MIMETRANS]
Vaudreuil, G., "Transition of Internet Mail from Just-Send-8 to
8Bit-SMTP/MIME", RFC 1428, February 1993.
[MIMETRANS] Vaudreuil, G., "Transition of Internet Mail from Just-Send-8 to 8Bit-SMTP/MIME", RFC 1428, February 1993.
[MIXER]
Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC-822",
RFC 1327, May 1992.
[MIXER] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC-822", RFC 1327, May 1992.
[T.4]
CCITT Recommendation T.4, Standardization of Group 3 Facsimile
Apparatus for Document Transmission (1988)
[T.4] CCITT Recommendation T.4, Standardization of Group 3 Facsimile Apparatus for Document Transmission (1988)
[T.30]
CCITT Recommendation T.30, Procedures For Document Facsimile
Transmission in the General Switched Telephone Network (1988)
[T.30] CCITT Recommendation T.30, Procedures For Document Facsimile Transmission in the General Switched Telephone Network (1988)
[T.411]
CCITT Recommendation T.411 (1988), Open Document Architecture
(ODA) and Interchange Format, Introduction and General Principles
[T.411] CCITT Recommendation T.411 (1988), Open Document Architecture (ODA) and Interchange Format, Introduction and General Principles
[MOTIS]
ISO/IEC International Standard 10021, Information technology -
Text Communication - Message-Oriented Text Interchange Systems
(MOTIS) (Parts 1 to 8)
[MOTIS] ISO/IEC International Standard 10021, Information technology - Text Communication - Message-Oriented Text Interchange Systems (MOTIS) (Parts 1 to 8)
[X.400]
CCITT, Data Communication Networks - Message Handling Systems -
Recommendations X.400 - X.420 (1988 version)
[X.400] CCITT, Data Communication Networks - Message Handling Systems - Recommendations X.400 - X.420 (1988 version)
Alvestrand Standards Track [Page 39] RFC 2157 X.400/MIME Body Mapping January 1998
Alvestrand Standards Track [Page 39] RFC 2157 X.400/MIME Body Mapping January 1998
[X.420]
CCITT Recommendation X.420 (1988), Interpersonal Messaging System
[X.420] CCITT Recommendation X.420 (1988), Interpersonal Messaging System
[RFC-X400USE]
Alvestrand, H., "X.400 use of extended Character Sets", RFC 1502,
August 1993.
[RFC-X400USE] Alvestrand, H., "X.400 use of extended Character Sets", RFC 1502, August 1993.
[MAWG]
Electronic Messaging Association Message Attachment Working Group
(MAWG): File Transfer Body Part Feasibility Project Guide -
version 1.5 - September 1995
[MAWG] Electronic Messaging Association Message Attachment Working Group (MAWG): File Transfer Body Part Feasibility Project Guide - version 1.5 - September 1995
[CDISP]
Troost, R., and S. Dorner, "Communicating Presentation Information
in Internet Messages: The Content-Disposition Header", RFC 1806,
June 1995.
[CDISP] Troost, R., and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.
[POSTSCRIPT]
Alvestrand, H., "Carrying PostScript in X.400 and MIME", RFC 2160,
June 1997.
[POSTSCRIPT] Alvestrand, H., "Carrying PostScript in X.400 and MIME", RFC 2160, June 1997.
[IMAGES]
Alvestrand, H., "X.400 Image Body Parts", RFC 2158, June 1997.
[IMAGES] Alvestrand, H., "X.400 Image Body Parts", RFC 2158, June 1997.
[ODA]
Alvestrand, H., "A MIME Body Part for ODA", RFC 2161, June 1997.
[ODA] Alvestrand, H., "A MIME Body Part for ODA", RFC 2161, June 1997.
[ISO 2022]
ISO/IEC 2022:1994(E): Information technology - Character code
structure and extension techniques
[ISO 2022] ISO/IEC 2022:1994(E): Information technology - Character code structure and extension techniques
[ISO 8859]
ISO 8859: Information processing -- 8-bit single-byte coded
graphic character sets (various parts)
[ISO 8859] ISO 8859: Information processing -- 8-bit single-byte coded graphic character sets (various parts)
[2022-JP]
Murai, J., Crispin, M., and E. van der Poel, "Japanese Character
Encoding for Internet Messages", RFC 1468, June 1993.
[2022-JP] Murai, J., Crispin, M., and E. van der Poel, "Japanese Character Encoding for Internet Messages", RFC 1468, June 1993.
[MUST]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[MUST] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
Alvestrand Standards Track [Page 40] RFC 2157 X.400/MIME Body Mapping January 1998
Alvestrand Standards Track [Page 40] RFC 2157 X.400/MIME Body Mapping January 1998
APPENDIXES
APPENDIXES
Appendix A: Escape code normalization
Appendix A: Escape code normalization
The algorithm given here in pseudocode will reduce a GeneralString ISO-2022 unlimited use of shifts sequence to a pure 8-bit sequence that does not use shift sequences, if possible.
The algorithm given here in pseudocode will reduce a GeneralString ISO-2022 unlimited use of shifts sequence to a pure 8-bit sequence that does not use shift sequences, if possible.
Some error conditions, like EOF, are not tested for. It crashes if asked to do something it cannot. Control character set switching is missing.
Some error conditions, like EOF, are not tested for. It crashes if asked to do something it cannot. Control character set switching is missing.
A similar routine, albeit more complex, can be written for normalizing to the ISO-2022-JP character set.
A similar routine, albeit more complex, can be written for normalizing to the ISO-2022-JP character set.
BEGIN: (from X.209)
g0 = 6 (should be 2, but ignore the difference)
g1 = NULL
g2 = NULL
g3 = NULL
c0 = 1 (ASCII control)
c1 = NULL
leftset = &g0 (current input set, low)
rightset = &g1 (current input set, high)
lowset = 6 (output set, low)
highset = NULL (output set, high)
charset = US-ASCII
BEGIN: (from X.209) g0 = 6 (should be 2, but ignore the difference) g1 = NULL g2 = NULL g3 = NULL c0 = 1 (ASCII control) c1 = NULL leftset = &g0 (current input set, low) rightset = &g1 (current input set, high) lowset = 6 (output set, low) highset = NULL (output set, high) charset = US-ASCII
(Init for the set tables)
chartoid[{2D,2E,2F}, 41] = 100
.....
idtoname[100] = "ISO-8859-1"
.....
(Init for the set tables) chartoid[{2D,2E,2F}, 41] = 100 ..... idtoname[100] = "ISO-8859-1" .....
WHILE (more data)
CASE head of input
{These are the locking shift sequences}
INCASE "00/14": (LS0, SO)
leftset = &g0;
INCASE "00/15": (LS1, SI)
leftset = &g
INCASE "ESC 07/14": (LS1R)
rightset = &g1;
INCASE "ESC 07/13": (LS2R)
rightset = &g2;
INCASE "ESC 07/12": (LS3R)
rightset = &g3;
{There is missing code for handling the single shift function}
WHILE (more data) CASE head of input {These are the locking shift sequences} INCASE "00/14": (LS0, SO) leftset = &g0; INCASE "00/15": (LS1, SI) leftset = &g INCASE "ESC 07/14": (LS1R) rightset = &g1; INCASE "ESC 07/13": (LS2R) rightset = &g2; INCASE "ESC 07/12": (LS3R) rightset = &g3; {There is missing code for handling the single shift function}
Alvestrand Standards Track [Page 41] RFC 2157 X.400/MIME Body Mapping January 1998
Alvestrand Standards Track [Page 41] RFC 2157 X.400/MIME Body Mapping January 1998
{These are the changes of graphic character sets}
{Note that G0 can contain only 94-character charsets}
INCASE "ESC 28"
g0 = chartoid[lastchar, next character]
sethiset(g0)
INCASE "ESC 2D", "ESC 29"
g1 = chartoid[lastchar, next character]
sethiset(g1)
INCASE "ESC 2E", "ESC 2A"
g2 = chartoid[lastchar, next character]
sethiset(g2)
INCASE "ESC 2F", "ESC 2B"
g3 = chartoid[lastchar, next character]
sethiset(g3)
{control characters. There is missing code for changing these}
INCASE 00/00-01/15 {normal control}
write(char)
INCASE 08/00-09/15 {upper control}
write(char)
{Normal characters}
INCASE 02/00-07/15 (Left)
IF (*leftset == lowset)
write(char)
ELSIF (*leftset == highset)
write(char+80)
ELSE
ERROR "Shift error"
ENDIF
INCASE 10/00-15/15
IF (*rightset == highset)
write(char)
ELSIF (*rightset == lowset)
write(char-80)
ELSE
ERROR "Shift error"
ENDIF
ENDCASE
ENDWHILE
{These are the changes of graphic character sets} {Note that G0 can contain only 94-character charsets} INCASE "ESC 28" g0 = chartoid[lastchar, next character] sethiset(g0) INCASE "ESC 2D", "ESC 29" g1 = chartoid[lastchar, next character] sethiset(g1) INCASE "ESC 2E", "ESC 2A" g2 = chartoid[lastchar, next character] sethiset(g2) INCASE "ESC 2F", "ESC 2B" g3 = chartoid[lastchar, next character] sethiset(g3) {control characters. There is missing code for changing these} INCASE 00/00-01/15 {normal control} write(char) INCASE 08/00-09/15 {upper control} write(char) {Normal characters} INCASE 02/00-07/15 (Left) IF (*leftset == lowset) write(char) ELSIF (*leftset == highset) write(char+80) ELSE ERROR "Shift error" ENDIF INCASE 10/00-15/15 IF (*rightset == highset) write(char) ELSIF (*rightset == lowset) write(char-80) ELSE ERROR "Shift error" ENDIF ENDCASE ENDWHILE
SUBROUTINE sethighset(g1)
SUBROUTINE sethighset(g1)
IF (highset == NULL)
charset = idtoname[g1]
highset = g1
ELSIF (highset == g1)
(it's OK)
ELSE
ERROR "Too many charsets encountered"
IF (highset == NULL) charset = idtoname[g1] highset = g1 ELSIF (highset == g1) (it's OK) ELSE ERROR "Too many charsets encountered"
Alvestrand Standards Track [Page 42] RFC 2157 X.400/MIME Body Mapping January 1998
Alvestrand Standards Track [Page 42] RFC 2157 X.400/MIME Body Mapping January 1998
ENDIF
ENDIF
ENDROUTINE
ENDROUTINE
Alvestrand Standards Track [Page 43] RFC 2157 X.400/MIME Body Mapping January 1998
Alvestrand Standards Track [Page 43] RFC 2157 X.400/MIME Body Mapping January 1998
Appendix B: OID Assignments
Appendix B: OID Assignments
MIXER-MAPPINGS DEFINITIONS ::= BEGIN EXPORTS -- everything --;
MIXER-MAPPINGS DEFINITIONS ::= BEGIN EXPORTS -- everything --;
IMPORTS
IMPORTS
mixer -- { iso(1) org(3) dod(6) internet(1) mail(7) mixer(1) }
FROM MIXER --Companion RFC--;
mixer -- { iso(1) org(3) dod(6) internet(1) mail(7) mixer(1) } FROM MIXER --Companion RFC--;
mixer-headings OBJECT IDENTIFIER ::=
{ mixer 1 } -- called mime-mhs-headings in RFC 1495 --
mixer-headings OBJECT IDENTIFIER ::= { mixer 1 } -- called mime-mhs-headings in RFC 1495 --
mixer-bodies OBJECT IDENTIFIER ::=
{ mixer 2 } -- called mime-mhs-bodies in RFC 1495 --
mixer-bodies OBJECT IDENTIFIER ::= { mixer 2 } -- called mime-mhs-bodies in RFC 1495 --
-- mixer-core is defined as { mixer core(3) } in [MIXER]
-- mixer-core is defined as { mixer core(3) } in [MIXER]
mixer-bp-data OBJECT IDENTIFIER ::=
{ mixer-bodies 1 }; -- called mime-mhs-bp-data in RFC 1494 --
mixer-bp-data OBJECT IDENTIFIER ::= { mixer-bodies 1 }; -- called mime-mhs-bp-data in RFC 1494 --
mixer-bp-parameter OBJECT IDENTIFIER ::=
{ mixer-bodies 2 };
mixer-bp-parameter OBJECT IDENTIFIER ::= { mixer-bodies 2 };
id-mime-bp-data OBJECT IDENTIFIER ::=
{ mixer-bp-data 1 };
-- for debugging: mixer-bp-data is 1.3.6.1.7.1.2.1.1
id-mime-bp-data OBJECT IDENTIFIER ::= { mixer-bp-data 1 }; -- for debugging: mixer-bp-data is 1.3.6.1.7.1.2.1.1
id-mime-bp-parameters OBJECT IDENTIFIER ::=
{ mixer-bp-parameter 1 };
id-mime-bp-parameters OBJECT IDENTIFIER ::= { mixer-bp-parameter 1 };
-- the following assignments were done in RFC 1494, using
-- slightly different names, but the same numbers.
-- their defining text is now is now in other documents
id-mime-postscript-body OBJECT IDENTIFIER ::=
{ mixer-bp-data 2 }
-- the following assignments were done in RFC 1494, using -- slightly different names, but the same numbers. -- their defining text is now is now in other documents id-mime-postscript-body OBJECT IDENTIFIER ::= { mixer-bp-data 2 }
id-mime-jpeg-body OBJECT IDENTIFIER ::=
{ mixer-bp-data 3 }
id-mime-jpeg-body OBJECT IDENTIFIER ::= { mixer-bp-data 3 }
id-mime-gif-body OBJECT IDENTIFIER ::=
{ mixer-bp-data 4 }
id-mime-gif-body OBJECT IDENTIFIER ::= { mixer-bp-data 4 }
-- This is a new definition, and defines an FTAM application
reference,
-- not a BP15 data OID.
id-mime-ftbp-data OBJECT IDENTIFIER ::=
{ mixer-bp-data 5 }
-- This is a new definition, and defines an FTAM application reference, -- not a BP15 data OID. id-mime-ftbp-data OBJECT IDENTIFIER ::= { mixer-bp-data 5 }
Alvestrand Standards Track [Page 44] RFC 2157 X.400/MIME Body Mapping January 1998
Alvestrand Standards Track [Page 44] RFC 2157 X.400/MIME Body Mapping January 1998
-- The following heading extensions are defined
id-hex-partial-message OBJECT IDENTIFIER ::=
{ mixer-headings 1 }
-- The following heading extensions are defined id-hex-partial-message OBJECT IDENTIFIER ::= { mixer-headings 1 }
id-hex-multipart-message OBJECT IDENTIFIER ::=
{ mixer-headings 2 } -- from RFC 1495; obsolete
id-hex-multipart-message OBJECT IDENTIFIER ::= { mixer-headings 2 } -- from RFC 1495; obsolete
id-hex-multipart-message-v2 OBJECT IDENTIFIER ::=
{ mixer-headings 3 }
id-hex-multipart-message-v2 OBJECT IDENTIFIER ::= { mixer-headings 3 }
END
END
Alvestrand Standards Track [Page 45] RFC 2157 X.400/MIME Body Mapping January 1998
Alvestrand Standards Track [Page 45] RFC 2157 X.400/MIME Body Mapping January 1998
Appendix C: Registration information for the Teletex
character set
Appendix C: Registration information for the Teletex character set
The Teletex character set is a character set in which the ISO 2022 character set switching mechanism may be used to switch between the following registered ISO character sets:
The Teletex character set is a character set in which the ISO 2022 character set switching mechanism may be used to switch between the following registered ISO character sets:
ISO-IR-87 - JIS_C6226-1983; a 16-bit Japanese character set ISO-IR-102 - a fairly standard US-ASCII variant ISO-IR-103 - Latin characters using non-spacing accents ISO-IR-106 - Control characters for C0 use; CR, LF, FF and a few more. ISO-IR-107 - Control characters for C1 use
ISO-IR-87 - JIS_C6226-1983; a 16-bit Japanese character set ISO-IR-102 - a fairly standard US-ASCII variant ISO-IR-103 - Latin characters using non-spacing accents ISO-IR-106 - Control characters for C0 use; CR, LF, FF and a few more. ISO-IR-107 - Control characters for C1 use
Its intended use of this character set is to represent data that comes from ISO protocols that use the ASN.1 construct "TeletexString" or "T61string" without conversion.
Its intended use of this character set is to represent data that comes from ISO protocols that use the ASN.1 construct "TeletexString" or "T61string" without conversion.
The set of allowed character sets can be found in CCITT recommendation X.208(1988), chapter 31.2 and Table 6/X.208.
The set of allowed character sets can be found in CCITT recommendation X.208(1988), chapter 31.2 and Table 6/X.208.
The rules for encoding the data type can be found in CCITT recommendation X.209(1988), chapter 23. It states that at the beginning of the string, G0 is always ISO-IR-102, C0 is ISO-IR-106, and C1 is ISO-IR-107.
The rules for encoding the data type can be found in CCITT recommendation X.209(1988), chapter 23. It states that at the beginning of the string, G0 is always ISO-IR-102, C0 is ISO-IR-106, and C1 is ISO-IR-107.
The specification seems somehow to have missed the implicit assumption that ISO-IR-103 is designated and invoked as G1 and shifted into the upper half of the character set which seems to be assumed at least by the X.400 and X.500 software that uses TeletexStrings; implementors should act as if the sequence ESC 2/9 7/6 LS1R is always present at the beginning of the data; however, when generating Teletex strings, implementors should include the sequence ESC 2/9 7/6 within the string before the first occurence of a character from ISO-IR-103.
The specification seems somehow to have missed the implicit assumption that ISO-IR-103 is designated and invoked as G1 and shifted into the upper half of the character set which seems to be assumed at least by the X.400 and X.500 software that uses TeletexStrings; implementors should act as if the sequence ESC 2/9 7/6 LS1R is always present at the beginning of the data; however, when generating Teletex strings, implementors should include the sequence ESC 2/9 7/6 within the string before the first occurence of a character from ISO-IR-103.
The rules for interpreting T.61 data are found (I believe) in CCITT recommendations T.51, T.52 and T.53 (data from the ITU WWW server):
The rules for interpreting T.61 data are found (I believe) in CCITT recommendations T.51, T.52 and T.53 (data from the ITU WWW server):
T.51 (09/92) [Rev.1] [26 pp.] [Publ.: May.93]
Latin based coded character sets for telematic services
T.52 (1993) [New] [88 pp.] [Publ.: Apr.94]
Non-Latin coded character sets for telematic services
T.53 (04/94) [New] [68 pp.] [Publ.: Jan.95]
Character coded control functions for telematic services
T.51 (09/92) [Rev.1] [26 pp.] [Publ.: May.93] Latin based coded character sets for telematic services T.52 (1993) [New] [88 pp.] [Publ.: Apr.94] Non-Latin coded character sets for telematic services T.53 (04/94) [New] [68 pp.] [Publ.: Jan.95] Character coded control functions for telematic services
The Teletex character set is closely related to (but not identical with) that specified in ISO 6937.
The Teletex character set is closely related to (but not identical with) that specified in ISO 6937.
Alvestrand Standards Track [Page 46] RFC 2157 X.400/MIME Body Mapping January 1998
Alvestrand Standards Track [Page 46] RFC 2157 X.400/MIME Body Mapping January 1998
No further restrictions are imposed by this registration; in particular, character set switching can occur anywhere, and there is no guarantee that the character sets will be switched "back" at the end.
No further restrictions are imposed by this registration; in particular, character set switching can occur anywhere, and there is no guarantee that the character sets will be switched "back" at the end.
Alvestrand Standards Track [Page 47] RFC 2157 X.400/MIME Body Mapping January 1998
Alvestrand Standards Track [Page 47] RFC 2157 X.400/MIME Body Mapping January 1998
Appendix D: IANA Registration form for new mappings
Appendix D: IANA Registration form for new mappings
To: IANA@isi.edu Subject: Registration of new X.400/MIME content type mapping
To: IANA@isi.edu Subject: Registration of new X.400/MIME content type mapping
MIME type name:
MIME type name:
(this must have been registered previously with IANA)
(this must have been registered previously with IANA)
X.400 body part:
X.400 body part:
IF BP15:
IF BP15:
- X.400 Object Identifier for Data:
- X.400 Object Identifier for Data:
(If left empty, an OID will be assigned by IANA under mixer-bp-data)
(If left empty, an OID will be assigned by IANA under mixer-bp-data)
- X.400 Object Identifier for Parameters:
- X.400 Object Identifier for Parameters:
(If left empty, an OID will be assigned by IANA under mixer-bp- parameter. If it is not used, fill in the words NOT USED.)
(If left empty, an OID will be assigned by IANA under mixer-bp- parameter. If it is not used, fill in the words NOT USED.)
X.400 ASN.1 Syntax:
X.400 ASN.1 Syntax:
(must be an EXTENDED-BODY-PART-TYPE macro, or reference to a Basic body part type)
(must be an EXTENDED-BODY-PART-TYPE macro, or reference to a Basic body part type)
IF FTBP:
IF FTBP:
- FTAM Object Identifier for application-reference:
- FTAM Object Identifier for application-reference:
- FTAM Object Identifier for contents-type:
- FTAM Object Identifier for contents-type:
(if left empty, unstructured-binary is assumed)
(if left empty, unstructured-binary is assumed)
Conversion algorithm:
Conversion algorithm:
(must be defined completely enough for independent implementation. It may be defined by reference to RFCs). Person & email address to contact for further information:
(must be defined completely enough for independent implementation. It may be defined by reference to RFCs). Person & email address to contact for further information:
INFORMATION TO THE SUBMITTER:
INFORMATION TO THE SUBMITTER:
The accepted registrations will be listed in the "Assigned Numbers" series of RFCs. The information in the registration form is freely distributable.
The accepted registrations will be listed in the "Assigned Numbers" series of RFCs. The information in the registration form is freely distributable.
Alvestrand Standards Track [Page 48] RFC 2157 X.400/MIME Body Mapping January 1998
Alvestrand Standards Track [Page 48] RFC 2157 X.400/MIME Body Mapping January 1998
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Alvestrand Standards Track [Page 49]
Alvestrand Standards Track [Page 49]
一覧
スポンサーリンク
