RFC1494 日本語訳
1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies. H.Alvestrand, S. Thompson. August 1993. (Format: TXT=37273 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Alvestrand
Request for Comments: 1494 SINTEF DELAB
S. Thompson
Soft*Switch, Inc.
August 1993
Alvestrandがコメントのために要求するワーキンググループH.をネットワークでつないでください: *スイッチInc.1993年8月に優しい1494SINTEF DELAB S.トンプソン
Equivalences between 1988 X.400 and RFC-822 Message Bodies
1988X.400とRFC-822メッセージボディーの間の等価性
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction ............................................. 2 2. Equivalence Table Definition ............................. 2 3. Generic conversions ...................................... 3 3.1. Byte copy .............................................. 3 3.2. Text Conversion ........................................ 3 3.3. Image Conversion ....................................... 3 3.4. Tunneling .............................................. 3 4. Conversion Table for known X.400 and MIME Types ......... 4 4.1. MIME to X.400 Table .................................... 4 4.2. X.400 to MIME Table .................................... 4 5. Newly defined X.400 Body Parts ........................... 5 5.1. Use of OBJECT IDENTIFIERs and ASN.1 MACROS ............. 5 5.2. The Generic MIME Extended Body Part .................... 6 5.3. The PostScript body part ............................... 7 5.4. The JPEG body part ..................................... 7 5.5. The GIF body part ...................................... 8 6. Newly defined MIME content-types ......................... 8 6.1. The application/x400-bp content-type ................... 8 6.2. The image/g3fax content-type ........................... 9 6.2.1. G3Fax Parameters ..................................... 9 6.2.2. Content Encoding ..................................... 10 6.3. The Application/ODA content-type ....................... 11 7. Equivalence Definitions ................................... 11 7.1. IA5Text - text/plain .................................... 11 7.2. GeneralText - text/plain (ISO-8859) ..................... 12 7.3. BilaterallyDefined - application/octet-stream .......... 13 7.4. ODA - application/oda ................................... 14 7.5. g3-facsimile - image/g3fax .............................. 15 7.6. application/postscript - postscript-body-part .......... 16 7.7. application/jpeg - jpeg-body-part ....................... 16
1. 序論… 2 2. 等価性テーブル定義… 2 3. 一般的な変換… 3 3.1. バイトコピー… 3 3.2. テキスト変換… 3 3.3. イメージ変換… 3 3.4. トンネリング… 3 4. 知られているX.400とMIMEの種類のための変換Table… 4 4.1. X.400テーブルにまねてください… 4 4.2. テーブルをまねるX.400… 4 5. 新たに、X.400ボディ・パーツを定義します… 5 5.1. 物の識別子とASN.1マクロの使用… 5 5.2. 一般的なMIMEは身体の部分を広げました… 6 5.3. ポストスクリプト本体は離れています… 7 5.4. JPEG身体の部分… 7 5.5. GIF身体の部分… 8 6. 新たに、MIMEの満足しているタイプを定義します… 8 6.1. x400-bpの満足しているアプリケーション/タイプ… 8 6.2. g3faxの満足しているイメージ/タイプ… 9 6.2.1. G3Faxパラメタ… 9 6.2.2. 満足しているコード化… 10 6.3. Application/ODAは内容でタイプします… 11 7. 等価性定義… 11 7.1. IA5Text--テキスト/平野… 11 7.2. GeneralText--テキスト/平野(ISO-8859)… 12 7.3. BilaterallyDefined--八重奏アプリケーション/流れ… 13 7.4. ODA--アプリケーション/oda… 14 7.5g3-ファクシミリ--イメージ/g3ファックス… 15 7.6アプリケーション/追伸--追伸身体の部分… 16 7.7アプリケーション/jpeg--jpeg身体の部分… 16
Alvestrand & Thompson [Page 1] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[1ページ]RFC1494MIMEボディー等価性1993年X.400/8月
7.8. image/gif - gif-body-part ............................... 16 8. OID Assignments ........................................... 17 9. IANA Registration form for new mappings ................... 17 10. Security Considerations .................................. 18 11. Authors' Addresses ....................................... 18 12. References ............................................... 19
7.8. イメージ/gif(gif身体の部分)… 16 8. OID課題… 17 9. IANA Registrationは新しいマッピングのために形成します… 17 10. セキュリティ問題… 18 11. 作者のアドレス… 18 12. 参照… 19
1. Introduction
1. 序論
This document is a companion to [1], which defines the principles behind interworking between MIME-based RFC-822 mail and X.400 mail. This document describes the content of the "IANA MHS/MIME Equivalence table" referenced in the companion document, and defines the initial configuration of this table. Mappings for new MIME content-types and/or X.400 body part types should be registered with the IANA to minimize redundancy and promote interoperability.
このドキュメントは[1]への仲間です。([1]はMIMEベースのRFC-822メールとX.400メールの間の織り込む後ろで原則を定義します)。 このドキュメントは、仲間ドキュメントで参照をつけられる「IANA MHS/MIME Equivalenceテーブル」の内容について説明して、このテーブルの初期の構成を定義します。 新しいMIME満足しているタイプ、そして/または、X.400ボディー部分タイプへのマッピングは、冗長を最小にして、相互運用性を促進するためにIANAに登録されるべきです。
In MIME, the term "content-type" is used to refer to an information object contained in the body of a message. In contrast, X.400 uses the term "body part type." In this document, the term "body part" is used to refer to either.
MIMEでは、「満足しているタイプ」という用語は、メッセージのボディーに含まれた情報物を示すのに使用されます。 対照的に、X.400は「ボディー部分タイプ」という用語を使用します。 本書では、「身体の部分」という用語は、どちらかについて言及するのに使用されます。
Please send comments to the MIME-MHS mailing list: <mime-mhs@surfnet.nl>.
MIME-MHSメーリングリストにコメントを送ってください: mhs@surfnet.nlをまねている<>。
2. Equivalence Table Definition
2. 等価性テーブル定義
For each MIME content-type/X.400 body part pair, the Equivalence Table will contain an entry with the following sections:
それぞれのMIME満足しているタイプ/X.400ボディー部分組のために、Equivalence Tableは以下のセクションによるエントリーを含むでしょう:
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に示さなければなりません。
Conversion Type
This section identifies the type of conversion applied. See the
section on Generic Conversions for an explanation of the
possible values.
変換Type This部は適用された変換のタイプを特定します。 可能な値の説明に関してGeneric Conversionsの上のセクションを見てください。
Alvestrand & Thompson [Page 2] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[2ページ]RFC1494MIMEボディー等価性1993年X.400/8月
Comments (optional)
This section gives any additional commentary that might be
useful in understanding the mapping between the X.400 and MIME
representations.
このセクションがどんな追加論評にもそれを与えるというコメント(任意の)はX.400とMIME表現の間のマッピングを理解する際に役に立つかもしれません。
The initial Equivalence Table entries in this document are described using this convention. Any future submissions to the IANA should follow this format.
初期のEquivalence Tableエントリーは、このコンベンションを使用することで本書では説明されます。 IANAへのどんな今後の差出もこの形式に続くべきです。
3. Generic conversions
3. 一般的な変換
3.1. Byte copy
3.1. バイトコピー
This is the trivial case, that is, no conversion at all. The byte stream is simply copied between MIME and X.400.
これは些細なケース、すなわち、全く変換ではありません。 バイト・ストリームはMIMEとX.400の間に単にコピーされます。
This is the preferred conversion, since it is the simplest.
それが最も簡単であるので、これは都合のよい変換です。
Implementors and vendors will be registering OBJECT IDENTIFIERs and MIME content-types for their various objects. They are STRONGLY ENCOURAGED to specify their content formats such that a gateway can use Byte Copy to map between them.
作成者と業者は彼らの様々な物のための満足しているタイプのOBJECT IDENTIFIERsとMIMEを登録するでしょう。 それらはゲートウェイがそれらの間の地図にByte Copyを使用できるようにそれらの満足している形式を指定するSTRONGLY ENCOURAGEDです。
Note that in some cases, it is necessary to define exactly which ASN.1 construct to replace with the content of the MIME object.
いくつかの場合、どのASN.1構造物をMIME物の内容に取り替えたらよいかをまさに定義するのが必要であることに注意してください。
3.2. Text Conversion
3.2. テキスト変換
This type of conversion applies to text objects that cannot be mapped using a simple Byte Copy. Conversion involves scanning and reformatting the object. For example, the MIME and X.400 objects might differ in their encoding of nonstandard characters, or line or page breaks.
このタイプの変換は簡単なByte Copyを使用することで写像できないテキストオブジェクトに適用されます。 変換は、物をスキャンして、再フォーマットすることを伴います。 例えば、MIMEとX.400物はそれらの外字、線またはページブレークのコード化において異なるかもしれません。
3.3. Image Conversion
3.3. 画像変換
This conversion type applies to raster images, like Group 3 Facsimile or JPEG. Again, it differs from Byte Copy in that it involves scanning reformatting the byte stream. It differs from Text Conversion in that it is pixel- oriented, rather than character- oriented.
この転換型はGroup3FacsimileやJPEGのようなラスター・イメージに当てはまります。 一方、それはバイト・ストリームを再フォーマットしながらスキャンすることを伴うという点においてByte Copyと異なっています。 それはそれが適応するキャラクタよりむしろ適応する画素であるという点においてText Conversionと異なっています。
3.4. Tunneling
3.4. トンネリング
This is not a conversion at all, but an encapsulation of the object. This is the fallback conversion, used when no explicit mapping applies.
これは全く変換ではなく、物のカプセル化です。 これはどんな明白なマッピングも適用されないとき使用される後退変換です。
Alvestrand & Thompson [Page 3] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[3ページ]RFC1494MIMEボディー等価性1993年X.400/8月
4. Conversion Table for known X.400 and MIME Types
4. 知られているX.400とMIMEの種類のための変換Table
This section itemizes the equivalences for all currently known MIME content-types and X.400 body parts.
このセクションはすべての現在知られているMIME満足しているタイプとX.400身体の部分に等価性を箇条書きします。
4.1. MIME to X.400 Table
4.1. X.400テーブルにまねてください。
MIME content-type X.400 Body Part Section
----------------- ------------------ -------
text/plain
charset=us-ascii ia5-text 7.1
charset=iso-8859-x EBP - GeneralText 7.2
text/richtext no mapping defined 5.2
application/oda EBP - ODA 7.4
application/octet-stream bilaterally-defined 7.3
application/postscript EBP - mime-postscript-body 5.4, 7.6
image/g3fax g3-facsimile 6.2, 7.5
image/jpeg EBP - mime-jpeg-body 5.5, 7.7
image/gif EBP - mime-gif-body 5.6, 7.8
audio/basic no mapping defined 5.2
video/mpeg no mapping defined 5.2
MIME満足しているタイプX.400 Body Partセクション----------------- ------------------ ------- 明瞭なcharset=私たちテキスト/ASCII ia5-テキスト7.1charset=iso-8859-x EBP--7.8のオーディオ的、または、基本的なノーが写像でないのが5.2に定義した定義された5.2ビデオ/mpegを写像して、定義された5.2アプリケーション/oda EBP--ODA7.4八重奏アプリケーション/流れの相互的に定義された7.3アプリケーション/追伸EBP(パントマイム追伸ボディー5.4、7.6g3fax g3イメージ/ファクシミリ6.2、7.5イメージ/jpeg EBP)パントマイムjpegボディー5.5、7.7イメージ/gif EBP--パントマイムgifボディー5.6を写像しないGeneralText7.2テキスト/richtext
Abbreviation: EBP - Extended Body Part
略語: EBP--拡張身体の部分
4.2. X.400 to MIME Table
4.2. テーブルをまねるX.400
Basic Body Parts
基本的なボディ・パーツ
X.400 Basic Body Part MIME content-type Section
--------------------- -------------------- -------
ia5-text text/plain;charset=us-ascii 7.1
voice No Mapping Defined 6.1
g3-facsimile image/g3fax 6.2, 7.5
g4-class1 no mapping defined 6.1
teletex no mapping defined 6.1
videotex no mapping defined 6.1
encrypted no mapping defined 6.1
bilaterally-defined application/octet-stream 7.3
nationally-defined no mapping defined 6.1
externally-defined See Extended Body Parts 6.1
X.400の基本的なBody Part MIME満足しているタイプセクション--------------------- -------------------- ------- ia5-テキストテキスト/平野; charsetは-g3-ファクシミリイメージ/g3faxのASCII7.1声のノーMapping Defined6.1 6.2に私たちと等しいです、7.5g4-class1が定義された6.1外部的に定義されたSee Extendedを写像しない7.3が全国的に定義した定義された6.1相互的に定義された八重奏アプリケーション/流れのボディ・パーツ6.1を写像しないコード化されて、写像でないのが6.1に定義した定義された6.1ビデオテックスを写像しない定義された6.1テレテックスを写像しないで
X.400 Extended Body Part MIME content-type Section
------------------------- -------------------- -------
GeneralText text/plain;charset=iso-8859-x 7.2
ODA application/oda 7.4
mime-postscript-body application/postscript 5.3, 7.6
mime-jpeg-body image/jpeg 5.4, 7.7
mime-gif-body image/gif 5.5, 7.8
X.400はBody Part MIME満足しているタイプセクションを広げました。------------------------- -------------------- ------- GeneralTextテキスト/平野; charset=iso-8859-x7.2ODAアプリケーション/oda7.4パントマイム追伸ボディーアプリケーション/追伸5.3、7.6パントマイムjpegホディー・イメージ/jpeg5.4、7.7パントマイムgifホディー・イメージ/gif5.5、7.8
Alvestrand & Thompson [Page 4] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[4ページ]RFC1494MIMEボディー等価性1993年X.400/8月
5. Newly defined X.400 Body Parts
5. 新たに定義されたX.400ボディ・パーツ
This section defines new X.400 Body Parts for the purposes of interworking with MIME.
このセクションはMIMEとの織り込むことの目的のために新しいX.400ボディ・パーツを定義します。
All new X.400 Body Parts defined here will be Extended Body Parts, as defined in CCITT Recommendation X.420 [2].
ここで定義されたすべての新しいX.400ボディ・パーツがCCITT Recommendation X.420[2]で定義されるようにExtendedボディ・パーツになるでしょう。
5.1. Use of OBJECT IDENTIFIERs and ASN.1 MACROS
5.1. 物の識別子とASN.1マクロの使用
X.420 dictates that Extended Body Parts shall:
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を使用します。
mime-mhs-bodies
パントマイムmhsボディー
defined in [1], as the root OID for X.400 Extended Body Parts defined for MIME interworking.
[1]では、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 mime-mhs-bodies, one for Data, and the other for Parameters:
OIDによってそれぞれ命名されて、各Extended Body PartはDataと任意のParametersを含んでいます。 このために、2つのOID下位木がパントマイムmhsボディー、Dataのための1つ、およびParametersのためのもう片方の下で定義されます:
mime-mhs-bp-data OBJECT IDENTIFIER ::=
{ mime-mhs-bodies 1 }
mime-mhs-bp-parameter OBJECT IDENTIFIER ::=
{ mime-mhs-bodies 2 }
パントマイムmhs-bpデータOBJECT IDENTIFIER:、:= パントマイムmhsボディー1パントマイムmhs-bpパラメタOBJECT IDENTIFIER:、:= パントマイムmhsボディー2
All definitions of X.400 body parts submitted to the IANA for registration must use the Extended Body Part Type macro for the definition. See the next section for an example.
登録のためにIANAに提出されたX.400身体の部分のすべての定義が定義にExtended Body Part Typeマクロを使用しなければなりません。 例に関して次のセクションを見てください。
Alvestrand & Thompson [Page 5] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[5ページ]RFC1494MIMEボディー等価性1993年X.400/8月
Lastly, the IANA will use the mime-mhs-bp-data and mime-mhs-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としてもパントマイムmhs-bpデータとパントマイム-mhs-bpパラメタOIDsを使用するでしょう。
5.2. The Generic MIME Extended Body Part
5.2. 一般的なMIME拡張身体の部分
The following X.400 Body Part is defined to carry any MIME content- type for which there is no explicit IANA registered mapping.
以下のX.400 Body Partは、登録された明白なIANAがないのがあるどんなMIME内容タイプも運ぶために写像しながら、定義されます。
mime-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS MimeParameters
IDENTIFIED BY mime-generic-parameters
DATA OCTET STRING
::= mime-generic-data
一般的なパラメタをまねているパントマイム身体のパートEXTENDED-BODY-PART-TYPE PARAMETERS MimeParameters IDENTIFIED BY DATA OCTET STRING:、:= 一般的なデータをまねてください。
MimeParameters ::=
SEQUENCE {
content-type IA5String,
content-parameters SEQUENCE OF
SEQUENCE {
parameter IA5String,
parameter-value IA5String
}
MimeParameters:、:= SEQUENCE、満足しているタイプIA5String、満足しているパラメタSEQUENCE OF SEQUENCEパラメタIA5String、パラメタ価値のIA5String
-- from RFC-1327, sec. 5.1.12
other-header-fields RFC822FieldList
}
-- RFC-1327、秒から 5.1.12 他のヘッダーフィールドRFC822FieldList
mime-generic-parameters OBJECT IDENTIFIER ::=
{ mime-mhs-bp-parameter 1 }
mime-generic-data OBJECT IDENTIFIER ::=
{ mime-mhs-bp-data 1 }
一般的なパラメタをまねているOBJECT IDENTIFIER:、:= パントマイムmhs-bpパラメタ1パントマイムジェネリックデータOBJECT IDENTIFIER:、:= パントマイムmhs-bpデータ1
To convert the MIME content-type into the X.400 mime- body-part:
MIMEの満足しているタイプをX.400に変換するには、身体部分をまねてください:
(1) Copy the "type/subtype" string from the MIME
Content-Type: header field into
MimeParameters.content-type
(1) MIMEコンテントタイプから「タイプ/「副-タイプ」」ストリングをコピーしてください: MimeParameters.content-タイプへのヘッダーフィールド
(2) For each "parameter=value" string in the MIME
Content-Type header field, create a
MimeParameters.content-parameters structure, and copy
the "parameter" string into MimeParameters.content-
parameters.parameter field and the "value" string
into the paired MimeParameters.content-
parameters.parameter-value field.
(2) MIMEコンテントタイプヘッダーフィールドにおけるそれぞれの「パラメタ=価値」ストリングのために、MimeParameters.content-パラメタ構造を作成してください、そして、MimeParameters.content parameters.parameter分野と対にされたMimeParameters.content parameters.parameter-値の分野への「値」ストリングに「パラメタ」ストリングをコピーしてください。
(3) Convert the MIME body part into its canonical form.
(3) MIME身体の部分を標準形に変換してください。
Alvestrand & Thompson [Page 6] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[6ページ]RFC1494MIMEボディー等価性1993年X.400/8月
(See appendix H of RFC 1341 [3] for a discussion
of canonical in this context.) Said another way,
reverse the transfer encoding to recover the original
byte stream.
(このような関係においては正準の議論のためのRFC1341[3]の付録Hを見てください。) 別の道に言われていて、転送コード化を逆にして、元のバイト・ストリームを回復してください。
(4) Copy the canonical byte stream into the mime-body-
part.data octet string.
(4) ボディー-part.dataをまねている八重奏ストリングに正準なバイト・ストリームをコピーしてください。
(5) Remove the Content-type and the Content-transfer-
encoding header fields from the MIME body part's
RFC822 header.
(5) MIME身体の部分のRFC822ヘッダーから文書内容とContentコード化を移しているヘッダーフィールドを取り除いてください。
(6) Any header fields starting with "Content-" in the
MIME body part is placed in the optional other-
header-fields structure. Note that this can only
occur when the MIME content-type occurs as part of a
"multipart" content-type.
(6) MIME本体の「内容」をきっかけに分野が分けるどんなヘッダーも他の任意のヘッダーフィールド構造に置かれます。 MIMEの満足しているタイプが満足している「複合」のタイプの一部として起こるとこれが起こることができるだけであることに注意してください。
The mapping from the X.400 mime-body-part to a MIME content-type is the inverse of the above steps.
X.400パントマイム身体の部分から満足しているMIMEタイプまでのマッピングは上のステップの逆です。
5.3. The PostScript body part
5.3. ポストスクリプト身体の部分
The following Extended Body Part is defined for PostScript data streams. It has no parameters.
以下のExtended Body Partはポストスクリプトデータ・ストリームのために定義されます。それには、パラメタが全くありません。
postscript-body-part EXTENDED-BODY-PART-TYPE
追伸身体のパートEXTENDED-BODY-PART-TYPE
DATA OCTET STRING
::= mime-postscript-body
データ八重奏は以下を結びます:= パントマイム追伸ボディー
mime-postscript-body OBJECT IDENTIFIER ::=
{ mime-mhs-bp-data 2 }
パントマイム追伸ボディーOBJECT IDENTIFIER:、:= パントマイムmhs-bpデータ2
5.4. The JPEG body part
5.4. JPEG身体の部分
The following Extended Body Part is defined for JPEG data streams. It has no parameters.
以下のExtended Body PartはJPEGデータ・ストリームのために定義されます。それには、パラメタが全くありません。
jpeg-body-part EXTENDED-BODY-PART-TYPE
DATA OCTET STRING
::= mime-jpeg-body
jpeg身体のパートEXTENDED-BODY-PART-TYPE DATA OCTET STRING:、:= パントマイムjpegボディー
mime-jpeg-body OBJECT IDENTIFIER ::=
{ mime-mhs-bp-data 3 }
パントマイムjpegボディーOBJECT IDENTIFIER:、:= パントマイムmhs-bpデータ3
Alvestrand & Thompson [Page 7] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[7ページ]RFC1494MIMEボディー等価性1993年X.400/8月
5.5. The GIF body part
5.5. GIF身体の部分
The following Extended Body Part is defined for GIF data streams. It has no parameters.
以下のExtended Body PartはGIFデータ・ストリームのために定義されます。それには、パラメタが全くありません。
gif-body-part EXTENDED-BODY-PART-TYPE
DATA OCTET STRING
::= mime-gif-body
gif身体のパートEXTENDED-BODY-PART-TYPE DATA OCTET STRING:、:= パントマイムgifボディー
mime-gif-body OBJECT IDENTIFIER ::=
{ mime-mhs-bp-data 4 }
パントマイムgifボディーOBJECT IDENTIFIER:、:= パントマイムmhs-bpデータ4
6. Newly defined MIME content-types
6. 新たに定義されたMIME満足しているタイプ
This section defines new MIME content-types for the purposes of interworking with X.400.
このセクションはX.400との織り込むことの目的のための満足しているタイプの新しいMIMEを定義します。
6.1. The application/x400-bp content-type
6.1. x400-bpの満足しているアプリケーション/タイプ
This content-type is defined to carry any X.400(88) body part for which there is no registered IANA mapping.
この満足しているタイプは、登録されたIANAマッピングが全くないどんなX.400(88)身体の部分も運ぶために定義されます。
The content-type field is
満足しているタイプ分野はそうです。
application/x400-bp
アプリケーション/x400-bp
The parameters are:
パラメタは以下の通りです。
bp-type=<INTEGER or OBJECT IDENTIFIER>
bp-タイプは<整数か物の識別子>と等しいです。
The body contains the raw ASN.1 IPM.body octet stream, including the initial tag octet.
ボディーは初期のタグ八重奏を含む生のASN.1IPM.body八重奏の流れを含みます。
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 bp-type parameter is set to the OBJECT IDENTIFIER from
ボディーがExtended Body Partであるなら、bp-型引数はOBJECT IDENTIFIERに設定されます。
IPMS.body.externally-defined.data.direct-reference
IPMS.body.externally-defined.data.direct-reference
No attempt is made to turn the parameters of Extended Body Parts into MIME parameters. (This task is the responsibility of the recipient's UA).
Extendedボディ・パーツのパラメタをMIMEパラメタに変えるのを試みを全くしません。 (このタスクは受取人のUAの責任です。)
For example, a basic VideotexBodyPart will have
例えば、基本的なVideotexBodyPartはそうしてしまうでしょう。
Alvestrand & Thompson [Page 8] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[8ページ]RFC1494MIMEボディー等価性1993年X.400/8月
Content-type=application/x400-bp; bp-type=6
文書内容はアプリケーション/x400-bpと等しいです。 bp-タイプ=6
whilst a Extended Videotex body part will have
Extended Videotex身体の部分はそうしてしまうでしょうが
Content-type=application/x400-bp; bp-type=2.6.1.4.5
文書内容はアプリケーション/x400-bpと等しいです。 タイプ=2.6.1.4をbpしている.5
application/x400-bp will need a content-transfer-encoding of base64 or quoted-printable when carried in 7-bit MIME. Since there is no way to know beforehand the content, it is recommended to just inspect the first 1 KByte or so of data and choose the one that seems to produce the more compact encoding.
7ビットのMIMEで運ばれると、アプリケーション/x400-bpはbase64か引用されて印刷可能の満足している転送コード化を必要とするでしょう。 あらかじめ内容を知る方法が全くないので、ただデータの最初のおよそ1KByteを点検して、よりコンパクトなコード化を生産するように思えるものを選ぶのはお勧めです。
If this is not feasible, Base64 is recommended.
これが可能でないなら、Base64はお勧めです。
6.2. The image/g3fax content-type
6.2. g3faxの満足しているイメージ/タイプ
This content-type is defined to carry G3 Facsimile byte streams.
この満足しているタイプは、G3 Facsimileバイト・ストリームを運ぶために定義されます。
In general, a G3Fax image contains 3 pieces of information:
一般に、G3Faxイメージは3つの情報を含んでいます:
(1) A set of flags indicating the particular coding
scheme. CCITT Recommendation T.30 defines how the
flags are transmitted over telephones. In this
medium, the flags are carried as parameters in the
MIME content-type header field.
(1) 特定のコード構成を示す1セットの旗。 CCITT Recommendation T.30は旗がどう電話の上に送られるかを定義します。 この媒体では、旗はMIME満足しているタイプヘッダーフィールドにおけるパラメタとして運ばれます。
(2) A structure that divides the bits into pages. CCITT
recommendation T.30 describes how to define page
boundaries. A page break algorithm is defined here
that is independent of how the image data is
conveyed.
(2) ビットをページに分割する構造。 CCITT推薦T.30はページ・バウンダリを定義する方法を説明します。 イメージデータがどう伝えられるかから独立しているページブレークアルゴリズムはここで定義されます。
(3) For each page, a sequence of bits that form the
encoding of the image. CCITT recommendation T.4
defines the bit image format. This is used without
change.
各ページ、イメージのコード化を形成するビットの系列のための(3)。 CCITT推薦T.4は噛み付いている画像形式を定義します。 これは変化なしで使用されます。
6.2.1. G3Fax Parameters
6.2.1. G3Faxパラメタ
The following parameters are defined:
以下のパラメタは定義されます:
(1) page-length - possible values: A4, B4 and Unlimited
(1)ページ長--可能な値: B4の、そして、無制限なA4
(2) page-width - possible values: A3, A4, B4
(2)ページ幅--可能な値: A3、A4、B4
(3) encoding - possible values: 1-dimensional, 2-
dimensional, Uncompressed
(3)コード化--可能な値: 1次元である、2 次元である、Uncompressed
Alvestrand & Thompson [Page 9] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[9ページ]RFC1494MIMEボディー等価性1993年X.400/8月
(4) resolution - possible values: Fine, Coarse
(4) 解決--可能な値: すばらしくて、粗いです。
(5) DCS - a bit string, represented in Base64.
(5)DCS--Base64に表されて、少し結びます。
(6) pages - an integer, giving the number of pages in the
document
(6)ページ--ドキュメントのページ数を与える整数
If nothing is specified, the default parameter settings are:
何も指定されないなら、デフォルトパラメタ設定は以下の通りです。
page-length=A4
page-width=A4
encoding=1-dimensional
resolution=Coarse
A4ページページ長=幅は=1次元の解決=をコード化するA4と粗い状態で等しいです。
It is possible (but misleading) to view the representation of these values as single-bit flags. They correspond to the following bits of the T.30 control string and X.400 G3FacsimileParameters:
これらの値の表現を単一のビット旗であるとみなすのは、可能、そして、(紛らわしい。)です。 彼らはT.30コントロールストリングとX.400 G3FacsimileParametersの以下のビットに対応します:
Parameter T.30 bit X.400 bit
パラメタT.30ビットX.400は噛み付きました。
page-length=A4 no bit set
page-length=B4 19 21
page-length=Unlimited 20 20
噛み付かれなかったページ長=A4は無制限なB4 19 21ページ長=ページ長=20 20を設定します。
page-width=A4 no bit set
page-width=A3 18 22
page-width=B4 17 23
噛み付かれなかったページ幅=A4はA3 18 22ページページ幅=幅=B4 17 23を設定します。
encoding=1-dimensional no bit set
encoding=2-dimensional 16 8
encoding=Uncompressed 26 30
=をコード化する=1次元のノー噛み付いているセットコード化=2次元の16 8をコード化すると、26 30は解凍しました。
resolution=Coarse no bit set
resolution=Fine 15 9
解決は粗いノー噛み付いているセット解決=罰金15 9と等しいです。
The reason for the different bit numbers is that X.400 counts bits in an octet from the MSB down to the LSB, while T.30 uses the opposite numbering scheme.
異なった噛み付いている数の理由はX.400が八重奏でビットをMSBからLSBまで数えるということです、T.30が反対のナンバリングスキームを使用しますが。
If any bit but these are set in the Device Control String, the DCS parameter should be supplied.
Device Control Stringにこれらだけをどんなビット設定するならも、DCSパラメタを提供するべきです。
6.2.2. Content Encoding
6.2.2. 満足しているコード化
X.400 defines the g3-facsimile data stream as a SEQUENCE of BIT STRINGs. Each BIT STRING is a page of facsimile image data, encoded as defined by Recommendation T.4. The following content encoding is reversible between MIME and X.400 and ensures that page breaks are
X.400はg3-ファクシミリデータ・ストリームをBIT STRINGsのSEQUENCEと定義します。 各BIT STRINGはRecommendation T.4によって定義されるようにコード化された1ページのファクシミリイメージデータです。 以下の満足しているコード化は、MIMEとX.400の間でリバーシブルであり、ページブレークがそうであることを確実にします。
Alvestrand & Thompson [Page 10] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[10ページ]RFC1494MIMEボディー等価性1993年X.400/8月
honored in the MIME representation.
MIME表現を光栄に思います。
An EOL is defined as a bit sequence of
EOLはしばらく系列と定義されます。
000000000001 (eleven zeroes and a one).
000000000001 (11のゼロと1つ。)
Each page of the message is delimited by a sequence of six (6) EOLs that MUST start on a byte boundary. The image bit stream is padded as needed to achieve this alignment.
メッセージの各ページはバイト境界を始めなければならない6(6)EOLsの系列によって区切られます。 イメージビットストリームは、この整列を達成するために必要に応じて水増しされます。
Searching for the boundary is a matter of searching for the byte sequence (HEX) 00 10 01 00 10 01 00 10 01, which cannot occur inside the image.
境界を捜し求めるのは、バイト列(HEX)00 10 01 00 10 01 00 10 01を捜し求める問題です。(00 10 01 00 10 01 00 10 01はイメージで起こることができません)。
See Section 7.5 for the algorithm on conversion between this encoding and the X.400 encoding.
アルゴリズムに関してこのコード化とX.400コード化の間の変換にセクション7.5を見てください。
The Base64 content-transfer-encoding is appropriate for carrying this content-type.
この満足しているタイプを運ぶのに、Base64の満足している転送コード化は適切です。
6.3. The Application/ODA content-type
6.3. ODAの満足しているApplication/タイプ
The "ODA" subtype of application is used to indicate that a body contains information encoded according to the Office Document Architecture [4] standards, using the ODIF representation format. For application/oda, the Content- Type line should also specify an attribute/value pair that indicates the document application profile (DAP), using the key word "profile", and the document class, using the keyword "class".
アプリケーションの「小田」「副-タイプ」はボディーが事務文書体系[4]規格に従ってコード化された情報を含むのを示すのに使用されます、ODIF表現形式を使用して。 また、アプリケーション/odaとして、Contentタイプ線はドキュメントアプリケーションプロフィール(DAP)を示す属性/値の組を指定するはずです、「プロフィール」というキーワード、およびドキュメントのクラスを使用して、「クラス」というキーワードを使用して。
For the keyword "class", the values "formatted", "processable" and "formatted-processable" are legal values.
「クラス」というキーワードに関しては、「フォーマットされた」値、"処理可能"、および「フォーマットされた処理可能」は法定価格です。
Thus an appropriate header field might look like this:
したがって、適切なヘッダーフィールドはこれに似るかもしれません:
Content-Type: application/oda; profile=Q112;
class=formatted
コンテントタイプ: アプリケーション/oda。 =Q112の輪郭を描いてください。 =がフォーマットしたクラス
Consult the ODA standard [4] for further information.
詳細のODA規格[4]に相談してください。
The Base64 content-transfer-encoding is appropriate for carrying ODA.
ODAを運ぶのに、Base64の満足している転送コード化は適切です。
7. Equivalence Definitions
7. 等価性定義
7.1. IA5Text - text/plain
7.1. IA5Text--テキスト/平野
X.400 Body Part: IA5Text MIME Content-type: text/plain; charset=US-ASCII
X.400身体の部分: IA5Textは文書内容をまねます: テキスト/平野。 charsetは米国-ASCIIと等しいです。
Alvestrand & Thompson [Page 11] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[11ページ]RFC1494MIMEボディー等価性1993年X.400/8月
Conversion Type: Byte copy Comments:
転換型: バイトコピー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は他の違いではありません。)
7.2. GeneralText - text/plain (ISO-8859)
7.2. GeneralText--テキスト/平野(ISO-8859)
X.400 Body Part: GeneralText; CharacterSets in
6,100,101,109,110,126,127,138,144,148
MIME Content-Type: text/plain; charset=ISO-8859-(1-9)
Conversion Type: Byte copy
Comments:
X.400身体の部分: GeneralText。 6,100,101,109,110,126,127,138,144,148におけるキャラクタセットはコンテントタイプをまねます: テキスト/平野。 charset=ISO-8859-(1-9)転換型: バイトコピーComments:
When mapping from X.400 to MIME, the character-set chosen from table below according to the value of Parameters.CharacterSets.
X.400からMIMEまで写像するとき、Parameters.CharacterSetsの値に従って以下のテーブルから選ばれた文字の組です。
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 [5], 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が[5]、パート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は以下のテーブルから用意ができています。
NOTE: The GeneralText body part is defined in ISO 10021-8 [5], and NOT in the corresponding CCITT recommendation. Its parameters were heavily modified in a defect report, and will be a SET OF INTEGER (indicating the ISO registry numbers of all the used sets) in the next version of the standard.
以下に注意してください。 GeneralText身体の部分は対応するCCITT推薦で定義されるのではなく、ISO10021-8[5]で定義されます。 パラメタは、不具合報告で大いに変更されて、規格の次のバージョンのSET OF INTEGER(すべての中古のセットのISO登録番号を示す)でしょう。
Alvestrand & Thompson [Page 12] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[12ページ]RFC1494MIMEボディー等価性1993年X.400/8月
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-8 6, 148 Other Latin-using languages
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-8 6、148のラテン語を使用するOther言語
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 number in the above table, and then appending it to the id-
cs-eit-authority {1 0 10021 7 1 0} OID.
MIMEからX.400まで変換するときにはメッセージ封筒のEncoded情報Typesにおける使用のために上のテーブルでISO IR番号を調べて、次に、イドCs eit権威にそれを追加することによって正しいOIDsを発生させてください、1 0、10021、7 1 0、OID。
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文字列の前部に加えなければなりません。
7.3. BilaterallyDefined - application/octet-stream
7.3. BilaterallyDefined--八重奏アプリケーション/流れ
X.400 Body Part: BilaterallyDefined MIME Content-Type: Application/Octet-Stream (no parameters) Conversion Type: Byte copy Comments:
X.400身体の部分: BilaterallyDefinedはコンテントタイプをまねます: 八重奏アプリケーション/流れ(パラメタがない)の変換Type: バイトコピーComments:
When mapping from MIME to X.400, if there are parameters present in the Content-Type: header field, the conversion fails since the BilaterallyDefined Body Part does not have any corresponding ASN.1 parameters.
パラメタがあれば、MIMEからX.400まで写像するときにはコンテントタイプで以下を提示してください。 BilaterallyDefined Body Partにはどんな対応するASN.1パラメタもないので、ヘッダーフィールド、変換は失敗します。
DISCUSSION: The parameters "name" "type" and "conversions" are advisory, but may in some cases give vital hints on the expected handling of the file. The parameter "conversions" is not fully defined, but it is expected that it will be useful, so we cannot drop it and expect people to be satisfied.
議論: パラメタ「名前」「タイプ」と「変換」は、顧問ですが、いくつかの場合、ファイルの予想された取り扱いのときに重大なヒントを与えるかもしれません。 「変換」というパラメタは完全に定義されるというわけではありませんが、私たちが満たされるために人々を止めて、期待できないように、それが役に立つと予想されます。
The parameter "padding" changes the interpretation of the last byte of the data, and so cannot be deleted.
データの最後のバイトの解釈を変えるので、「詰め物」というパラメタを削除できません。
An option is to prepend an IA5 body part that contains the parameter text; this will aid unmodified readers, and can probably be made
オプションはIA5身体のprependに関係しますパラメタテキストを含む。 これは、変更されていない読者を支援して、たぶん作ることができます。
Alvestrand & Thompson [Page 13] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[13ページ]RFC1494MIMEボディー等価性1993年X.400/8月
reversible with suitable chicanery, but is it worth it????
適当なごまかしによるリバーシブル、それはそれの価値があります。
Also, 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. 1992 X.400 defines a File Transfer Body Part to solve this problem (i.e. binary file transfer through email). The standard and its regional profiles are not solid enough yet to exploit as a solution for this problem.
また、BilaterallyDefinedボディ・パーツの使用は1988と1992X.400の両方で明確に非難されます。 それは唯一1984台のシステムとの後方の互換性のために保有されます。1992X.400は、この問題(すなわち、メールによるバイナリーファイル転送)を解決するためにFile Transfer Body Partを定義します。 標準のプロフィールとその地方のプロフィールはこの問題の解決としてまだ利用しているくらいには確実ではありません。
7.4. ODA - application/oda
7.4. ODA--アプリケーション/oda
X.400 Body Part: ODA MIME Content-Type: application/oda Conversion Type: Byte copy Comments:
X.400身体の部分: ODA MIMEコンテントタイプ: アプリケーション/oda Conversion Type: バイトコピーComments:
The ODA body part is defined in the CCITT document T.411 [6], appendix E, section E.2, "ODA identification in the P2 protocol of MHS"
ODA身体の部分はCCITTドキュメントT.411[6]で定義されます、付録E、E.2、「MHSのP2プロトコルにおけるODA識別」というセクション
An abbreviated version of its ASN.1 definition is:
ASN.1定義の簡略版は以下の通りです。
oda-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS OdaBodyPartParameters
DATA OdaData
::= id-et-oda
oda身体のパートEXTENDED-BODY-PART-TYPE PARAMETERS OdaBodyPartParameters DATA OdaData:、:= イド-et-oda
OdaBodyPartParameters ::= SET {
document-application-profile [0] OBJECT IDENTIFIER
document-architecture-class [1] INTEGER {
formatted (0)
processable (1)
formatted-processable(2)}}
OdaBodyPartParameters:、:= セットします。ドキュメントアプリケーションプロフィール[0]OBJECT IDENTIFIERドキュメント構造のクラス[1]INTEGERは(0) 処理可能(1)のフォーマットされたprocessable(2)をフォーマットしました。
id-et-oda OBJECT IDENTIFIER ::= { 2 8 1 0 1 }
イド-et-oda OBJECT IDENTIFIER:、:= { 2 8 1 0 1 }
Mapping from X.400 to MIME, the following is done:
X.400からMIMEまで写像して、以下をします:
The Parameters.document-application-profile is mapped onto the MIME parameter "profile" according to the table below.
以下のテーブルに従って、Parameters.documentアプリケーションプロフィールは「プロフィール」というMIMEパラメタに写像されます。
Profile OBJECT IDENTIFIER
プロフィール物の識別子
Q112 { iso (1) identified-organization (3) ewos (16)
eg (2) oda (6) profile (0) q112 (1) }
Q112isoの(1)の特定された組織(3) ewos(16)eg(2)oda(6)プロフィール(0)q112(1)
The Parameters.document-architecture-class is mapped onto the MIME parameter "class" according to the table below
以下のテーブルに従って、Parameters.document構造のクラスは「クラス」というMIMEパラメタに写像されます。
Alvestrand & Thompson [Page 14] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[14ページ]RFC1494MIMEボディー等価性1993年X.400/8月
String Integer
ストリング整数
formatted formatted(0)
processable processable(1)
formatted-processable formatted-processable(2)
フォーマットされたフォーマットされた(0)processable processable(1)フォーマットされた処理可能フォーマットされた処理可能(2)
NOTE: This parameter is not defined in RFC 1341.
以下に注意してください。 このパラメタはRFC1341で定義されません。
The body of the MIME content-type is the Data part of the ODA body part.
MIMEの満足しているタイプのボディーはODA身体の部分のData一部分です。
When mapping from MIME to X.400, the following steps are done:
MIMEからX.400まで写像するとき、以下のステップをします:
The Parameters.document-application-profile and Parameters.document- architecture-class are set from the tables above. If any of the parameters are missing, the values for Q112 and formatted-processable are used.
Parameters.documentアプリケーションプロフィールとParameters.document構造クラスは上のテーブルから設定されます。 パラメタのどれかがなくなるなら、Q112とフォーマットされた処理可能のための値は使用されています。
It is an option for the gateway implementor to try to access them from inside the document, where they are defined as
それはゲートウェイ作成者がドキュメントの中からそれらにアクセスしようとするオプションです。そこでは、それらが定義されます。
document-profile.document-characteristics.document-architecture-class
ドキュメントprofile.document-characteristics.document構造のクラス
document-profile.document-characteristics.document-application-profile
ドキュメントprofile.document-characteristics.documentアプリケーションプロフィール
Gateways are NOT required to do this, since the document- characteristics are optional parameters. If a gateway does not, it simply uses the defaulting rules defined above.
ゲートウェイは、ドキュメントの特性が任意のパラメタであるので、これをする必要はありません。 ゲートウェイがそうしないなら、それは単に規則が上で定義したデフォルトを使用します。
The OBJECT IDENTIFIERs for the document application profile and for
ODA {2 8 0 0} must be added to the Encoded Information Types
parameter of the message envelope.
ドキュメントアプリケーションプロフィールとODA2 8 0 0のためのOBJECT IDENTIFIERsをメッセージ封筒のEncoded情報Typesパラメタに追加しなければなりません。
7.5. g3-facsimile - image/g3fax
7.5. g3-ファクシミリ--イメージ/g3fax
X.400 Body part: g3-facsimile MIME Content-Type: image/g3fax Conversion Type: nearly Byte copy Comments:
X.400身体の部分: g3-ファクシミリMIMEコンテントタイプ: イメージ/g3fax Conversion Type: ほとんどByteはCommentsをコピーします:
The Parameters of the X.400 G3Fax body part are mapped to the corresponding Parameters on the MIME Image/G3Fax body part and vice versa. Note that:
X.400 G3Fax身体の部分のParametersは逆もまた同様にMIME Image/G3Fax身体の部分の上の対応するParametersに写像されます。 以下のことに注意してください。
(1) If fineResolution is not specified, pixels will be
twice as tall as they are wide
(1) fineResolutionが指定されないと、画素はそれらが広いというよりも2倍高くなるでしょう。
(2) If any bit not corresponding to a specially named
もしあれば(2)は、特に、指定されたaに対応しないことで噛み付きました。
Alvestrand & Thompson [Page 15] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[15ページ]RFC1494MIMEボディー等価性1993年X.400/8月
option is set in the G3Fax NonBasicParameters, the
"DCS" parameter must be used.
オプションはG3Fax NonBasicParametersに設定されて、「DCS」パラメタを使用しなければなりません。
(3) Interworking is not guaranteed if any bit apart from
those specially named are used in the
NonBasicParameters
(3) 何か特に、指定されたものは別としてビットがNonBasicParametersで使用されるなら、織り込むことは保証されません。
From X.400 to G3Fax, the body is created in the following way:
X.400からG3Faxまで、ボディーは以下の方法で作成されます:
(1) Any trailing EOL markers on each bitstring is
removed. The bistring is padded to a byte boundary.
(1) いくらか、各bitstringのときにEOLマーカーを引きずるのを取り除きます。 bistringはバイト境界に水増しされます。
(2) 6 consecutive EOL markers are appended to each
bitstring.
(2) 6人の連続したEOLマーカーを各bitstringに追加します。
(3) The padded bitstrings are concatenated together
(3) そっと歩いているbitstringsは一緒に連結されます。
An EOL marker is the bit sequence 000000000001 (11 zeroes and a one).
EOLマーカーは噛み付いている系列000000000001です(11のゼロと1つ)。
From G3Fax to X.400, the body is created in the following way:
G3FaxからX.400まで、ボディーは以下の方法で作成されます:
(1) The body is split into bitstrings at each occurrence
of 6 consecutive EOL markers, and trailing EOLs and
padding are removed
(1) ボディーは6人の連続したEOLマーカーの各発生のときにbitstringsに分けられます、そして、引きずっているEOLsと詰め物は取り外されます。
(2) Each bitstring is made into an ASN.1 BITSTRING
(2) 各bitstringをASN.1BITSTRINGにします。
(3) The bitstrings are made into an ASN.1 SEQUENCE, which
forms the body of the G3Fax body part.
(3) bitstringsをASN.1SEQUENCEにします。(SEQUENCEはG3Fax身体の部分のボディーを形成します)。
7.6. application/postscript - postscript-body-part
7.6. アプリケーション/追伸--追伸身体の部分
X.400 Body Part: Extended Body Part, OID postscript-body-part MIME Content-Type: application/postscript Conversion Type: Byte Copy
X.400身体の部分: 拡張Body Part、OID追伸身体の部分MIMEコンテントタイプ: アプリケーション/追伸Conversion Type: バイトコピー
7.7. application/jpeg - jpeg-body-part
7.7. アプリケーション/jpeg--jpeg身体の部分
X.400 Body Part: Extended Body Part, OID jpeg-body-part MIME Content-Type: application/jpeg Conversion Type: Byte Copy
X.400身体の部分: 拡張Body Part、OID jpeg身体の部分MIMEコンテントタイプ: アプリケーション/jpeg Conversion Type: バイトコピー
7.8. image/gif - gif-body-part
7.8. イメージ/gif--gif身体の部分
X.400 Body Part: Extended Body Part, OID gif-body-part MIME Content-Type: application/gif Conversion Type: Byte Copy
X.400身体の部分: 拡張Body Part、OID gif身体の部分MIMEコンテントタイプ: アプリケーション/gif Conversion Type: バイトコピー
Alvestrand & Thompson [Page 16] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[16ページ]RFC1494MIMEボディー等価性1993年X.400/8月
8. OID Assignments
8. OID課題
MIME-MHS-MAPPINGS DEFINITIONS ::= BEGIN
MIME MHSマッピング定義:、:= 始まってください。
IMPORTS
mail, mime-mhs, mime-mhs-bodies
FROM MIME-MHS;
IMPORTSメール、パントマイム-mhs、パントマイムmhsボディーFROM MIME-MHS。
mime-mhs-bp-data OBJECT IDENTIFIER ::=
{ mime-mhs-bodies 1}
パントマイムmhs-bpデータOBJECT IDENTIFIER:、:= パントマイムmhsボディー1
mime-mhs-bp-parameter OBJECT IDENTIFIER ::=
{ mime-mhs-bodies 2}
パントマイムmhs-bpパラメタOBJECT IDENTIFIER:、:= パントマイムmhsボディー2
mime-generic-data OBJECT IDENTIFIER ::=
{ mime-mhs-bp-data 1}
一般的なデータをまねているOBJECT IDENTIFIER:、:= パントマイムmhs-bpデータ1
mime-generic-parameters OBJECT IDENTIFIER ::=
{ mime-mhs-bp-parameter 1}
一般的なパラメタをまねているOBJECT IDENTIFIER:、:= パントマイムmhs-bpパラメタ1
mime-postscript-body OBJECT IDENTIFIER ::=
{ mime-mhs-bp-data 2}
パントマイム追伸ボディーOBJECT IDENTIFIER:、:= パントマイムmhs-bpデータ2
mime-jpeg-body OBJECT IDENTIFIER ::=
{ mime-mhs-bp-data 3}
パントマイムjpegボディーOBJECT IDENTIFIER:、:= パントマイムmhs-bpデータ3
mime-gif-body OBJECT IDENTIFIER ::=
{ mime-mhs-bp-data 4};
パントマイムgifボディーOBJECT IDENTIFIER:、:= パントマイムmhs-bpデータ4。
9. IANA Registration form for new mappings
9. IANA Registrationは新しいマッピングのために形成します。
To: IANA@isi.edu Subject: Registration of new X.400/MIME content type mapping
To: IANA@isi.edu Subject: 新しいX.400/MIMEの満足しているタイプマッピングの登録
MIME type name:
MIMEの種類名:
(this must have been registered previously with IANA)
(これは以前に、IANAに登録されたに違いありません)
X.400 body part:
X.400身体の部分:
X.400 Object Identifier for Data:
データのためのX.400物の識別子:
(If left empty, an OID will be assigned by IANA under mime-mhs-bp-data)
(空のままにされると、OIDはパントマイムmhs-bpデータの下でIANAによって割り当てられるでしょう)
X.400 Object Identifier for Parameters:
パラメタのためのX.400物の識別子:
Alvestrand & Thompson [Page 17] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[17ページ]RFC1494MIMEボディー等価性1993年X.400/8月
(If left empty, an OID will be assigned by IANA under mime-mhs-bp-parameter. If it is not used, fill in the words NOT USED.)
(空のままにされると、OIDはパントマイムmhs-bpパラメタの下でIANAによって割り当てられるでしょう。 それが使用されていないなら、NOT USEDという単語に記入してください。)
X.400 ASN.1 Syntax:
X.400 ASN.1構文:
(must be an EXTENDED-BODY-PART-TYPE macro, or reference to a Basic body part type)
(EXTENDED-BODY-PART-TYPEマクロ、またはBasicボディー部分タイプに言及でなければなりません)
Conversion algorithm:
変換アルゴリズム:
(must be defined completely enough for independent implementation. It may be defined by reference to RFCs).
(独立している実現のために十分完全に定義しなければなりません。 それはRFCsの参照で定義されるかもしれません。).
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
INFORMATION TO THE SUBMITTER:
SUBMITTERへの情報:
The accepted registrations will be listed in the "Assigned Numbers" series of RFCs. The information in the registration form is freely distributable.
受け入れられた登録証明書はRFCsの「規定番号」シリーズで記載されるでしょう。 登録用紙の情報は自由に配置可能です。
10. Security Considerations
10. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
11. Authors' Addresses
11. 作者のアドレス
Harald Tveit Alvestrand SINTEF DELAB N-7034 Trondheim NORWAY
ハラルド・Tveit Alvestrand SINTEF DELAB N-7034トロンヘイムノルウェー
EMail: Harald.Alvestrand@delab.sintef.no
メール: Harald.Alvestrand@delab.sintef.no
Steven J. Thompson Soft*Switch, Inc. 640 Lee Road Wayne, PA 19087
スティーブン・J.トンプソン柔らかい*スイッチInc.640リー・Roadウェイン、PA 19087
Phone: (215) 640-7556 EMail: sjt@gateway.ssw.com
以下に電話をしてください。 (215) 640-7556 メールしてください: sjt@gateway.ssw.com
Alvestrand & Thompson [Page 18] RFC 1494 X.400/MIME Body Equivalences August 1993
Alvestrandとトンプソン[18ページ]RFC1494MIMEボディー等価性1993年X.400/8月
12. References
12. 参照
[1] Alvestrand, H., Kille, S., Miles, R., Rose, M., and S. Thompson,
"Mapping between X.400 and RFC-822 Message Bodies", RFC 1495,
SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc, Dover Beach
Consulting, Inc., Soft*Switch, Inc., August 1993.
[1] Alvestrand、H.、Kille、S.、マイル、R.、ローズ、M.、およびS.トンプソンRFC1495、SINTEF DELAB、ISODE共同体、柔らかい*「X.400とRFC-822メッセージの間でボディーを写像し」て、は切り替わります、Inc、ドーヴァービーチコンサルティングInc.、柔らかい*スイッチInc.、1993年8月。
[2] CCITT Recommendation X.420 (1988), Interpersonal Messaging
System.
[2] CCITT推薦X.420(1988)、個人間のメッセージシステム。
[3] Borenstein, N, and N. Freed, "MIME: Mechanisms for Specifying
and Describing the Format of Internet Message Bodies", RFC 1341,
Bellcore, Innosoft, June 1992.
[3] Borenstein(N、および解放されたN.)は「以下をまねます」。 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1341、Bellcore、Innosoft、1992年6月。
[4] ISO 8613; Information Processing: Text and Office System; Office
Document Architecture (ODA) and Interchange Format (ODIF), Part
1-8, 1989.
[4] ISO8613。 情報処理: テキストとオフィス・システム。 事務文書体系(ODA)と置き換えは(ODIF)、第1部-8、1989をフォーマットします。
[5] ISO/IEC International Standard 10021, Information technology -
Text Communication - Message-Oriented Text Interchange Systems
(MOTIS) (Parts 1 to 8).
[5] ISO/IEC国際規格10021(情報技術(テキストCommunication))はText Interchange Systems(MOTIS)(パート1〜8)をメッセージで適応させました。
[6] CCITT Recommendation T.411 (1988), Open Document Architecture
(ODA) and Interchange Format, Introduction and General
Principles.
[6] CCITT推薦T.411(1988)、文書体系(ODA)、置き換え形式、序論、および綱領を開いてください。
[7] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[7] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
[8] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
and RFC-822", RFC 1327, University College London, May 1992.
[8] Hardcastle-Kille、S.、「X.400(1988)/ISO10021とRFC-822の間のマッピング」、RFC1327、ユニバーシティ・カレッジロンドンは1992がそうするかもしれません。
[9] CCITT Recommendation T.4, Standardization of Group 3 Facsimile
Apparatus for Document Transmission (1988).
[9] CCITT推薦T.4、ドキュメントトランスミッション(1988)のためのグループ3ファクシミリ装置の規格化。
[10] CCITT Recommendation T.30, Procedures For Document Facsimile
Transmission in the General Switched Telephone Network (1988).
[10] CCITT推薦T.30、司令官におけるドキュメントファクシミリ伝送のための手順は電話網(1988)を切り換えました。
[11] CCITT, Data Communication Networks - Message Handling Systems -
Recommendations X.400 - X.420 (1988 version).
[11]CCITT、Data Communication Networks--メッセージHandling Systems--推薦X.400--X.420(1988年のバージョン)。
[12] Alvestrand, H., "X.400 Use of Extended Character Sets", RFC
1502, SINTEF DELAB, August 1993.
[12]Alvestrand、H.、「拡張文字集合のX.400使用」、RFC1502、SINTEF DELAB、1993年8月。
Alvestrand & Thompson [Page 19]
Alvestrandとトンプソン[19ページ]
一覧
スポンサーリンク
