RFC2387 日本語訳
2387 The MIME Multipart/Related Content-type. E. Levinson. August 1998. (Format: TXT=18864 bytes) (Obsoletes RFC2112) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Levinson Request for Comments: 2387 August 1998 Obsoletes: 2112 Category: Standards Track
コメントを求めるワーキンググループE.レヴィンソン要求をネットワークでつないでください: 2387 1998年8月は以下を時代遅れにします。 2112年のカテゴリ: 標準化過程
The MIME Multipart/Related Content-type
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。
Abstract
要約
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use.
Multipart/関連のcontent typeは関連するMIME身体の部分の集合であるオブジェクトを表すのに一般的なメカニズムを提供します。 このドキュメントは、Multipart/関連のcontent typeを定義して、使用に関する例を提供します。
1. Introduction
1. 序論
Several applications of MIME, including MIME-PEM, and MIME-Macintosh and other proposals, require multiple body parts that make sense only in the aggregate. The present approach to these compound objects has been to define specific multipart subtypes for each new object. In keeping with the MIME philosophy of having one mechanism to achieve the same goal for different purposes, this document describes a single mechanism for such aggregate or compound objects.
MIME-PEM、MIMEマッキントッシュ、および他の提案を含むMIMEのいくつかのアプリケーションが集合だけで理解できる複数の身体の部分を必要とします。 これらの合成オブジェクトへの現在の取り組み方はそれぞれの新しいオブジェクトのために特定の複合血液型亜型を定義することです。 異なる役割の同じ目標を達成するために有のMIME哲学で1つのメカニズムを保つ際に、このドキュメントはそのような集合か合成オブジェクトのためにただ一つのメカニズムについて説明します。
The Multipart/Related content-type addresses the MIME representation of compound objects. The object is categorized by a "type" parameter. Additional parameters are provided to indicate a specific starting body part or root and auxiliary information which may be required when unpacking or processing the object.
Multipart/関連のcontent typeは、MIMEが合成オブジェクトの表現であると扱います。 オブジェクトは「タイプ」パラメタによって分類されます。 オブジェクトをアンパックするか、または処理するとき、必要であるかもしれない特定の始めの身体の部分か根と補助の情報を示すために追加パラメタを提供します。
Multipart/Related MIME entities may contain Content-Disposition headers that provide suggestions for the storage and display of a body part. Multipart/Related processing takes precedence over Content-Disposition; the interaction between them is discussed in section 4.
複合の、または、関連のMIME実体は身体の部分のストレージとディスプレイのための提案を提供するContent-気質ヘッダーを含むかもしれません。 複合の、または、関連の処理はContent-気質に優先します。 セクション4でそれらの間の相互作用について議論します。
Levinson Standards Track [Page 1] RFC 2387 Multipart/Related August 1998
レヴィンソンStandardsは複合の、または、関連の1998年8月にRFC2387を追跡します[1ページ]。
Responsibility for the display or processing of a Multipart/Related's constituent entities rests with the application that handles the compound object.
Multipart/のディスプレイか処理が関係したので、合成オブジェクトを処理するアプリケーションで責任は構成している実体休息です。
2. Multipart/Related Registration Information
2. 複合の、または、関連のレジスト情報
The following form is copied from RFC 1590, Appendix A.
Appendix A、以下のフォームはRFC1590からコピーされます。
To: IANA@isi.edu
Subject: Registration of new Media Type content-type/subtype
To: IANA@isi.edu Subject: 新しいメディアType content type/「副-タイプ」の登録
Media Type name: Multipart
メディアTypeは以下を命名します。 複合
Media subtype name: Related
メディア「副-タイプ」は以下を命名します。 関係します。
Required parameters: Type, a media type/subtype.
必要なパラメタ: タイプ、メディアタイプ/「副-タイプ」。
Optional parameters: Start
Start-info
任意のパラメタ: スタートインフォメーションを始めてください。
Encoding considerations: Multipart content-types cannot have
encodings.
問題をコード化します: 複合content typeはencodingsを持つことができません。
Security considerations: Depends solely on the referenced type.
セキュリティ問題: 唯一被参照型に頼っています。
Published specification: RFC-REL (this document).
広められた仕様: RFC-REL(このドキュメント)。
Person & email address to contact for further information:
Edward Levinson
47 Clive Street
Metuchen, NJ 08840-1060
+1 908 494 1606
XIson@cnj.digex.net
詳細のために連絡する人とEメールアドレス: エドワードレヴィンソン47クライヴ通りメタチェン、ニュージャージー08840-1060+1 908 494 1606 XIson@cnj.digex.net
3. Intended usage
3. 意図している用法
The Multipart/Related media type is intended for compound objects consisting of several inter-related body parts. For a Multipart/Related object, proper display cannot be achieved by individually displaying the constituent body parts. The content-type of the Multipart/Related object is specified by the type parameter. The "start" parameter, if given, points, via a content-ID, to the body part that contains the object root. The default root is the first body part within the Multipart/Related body.
Multipart/関連のメディアタイプはいくつかの相互関連する身体の部分から成る合成オブジェクトのために意図します。 Multipart/関連のオブジェクトに関しては、個別に選挙母体の部品を表示することによって、適切なディスプレイを達成できません。 Multipart/関連のオブジェクトのcontent typeは型引数によって指定されます。 考えて、「始め」パラメタは満足しているID経由でオブジェクト根を含む身体の部分に指します。 デフォルト根はMultipart/関連のボディーの中の最初の身体の部分です。
The relationships among the body parts of a compound object distinguishes it from other object types. These relationships are often represented by links internal to the object's components that
合成オブジェクトの身体の部分の中の関係は他のオブジェクト・タイプとそれを区別します。 これらの関係がしばしばオブジェクトのコンポーネントへの内部のリンクによって表される、それ
Levinson Standards Track [Page 2] RFC 2387 Multipart/Related August 1998
レヴィンソンStandardsは複合の、または、関連の1998年8月にRFC2387を追跡します[2ページ]。
reference the other components. Within a single operating environment the links are often file names, such links may be represented within a MIME message using content-IDs or the value of some other "Content-" headers.
他のコンポーネントに参照をつけてください。 しばしばリンクがただ一つの操作環境の中では、ファイル名である、そのようなリンクは、MIMEメッセージの中に満足しているIDかある他の「内容」ヘッダーの値を使用することで表されるかもしれません。
3.1. The Type Parameter
3.1. 型引数
The type parameter must be specified and its value is the MIME media type of the "root" body part. It permits a MIME user agent to determine the content-type without reference to the enclosed body part. If the value of the type parameter and the root body part's content-type differ then the User Agent's behavior is undefined.
型引数を指定しなければなりません、そして、値は「根」身体の部分のMIMEメディアタイプです。 それは、MIMEユーザエージェントが同封の身体の部分の参照なしでcontent typeを決定することを許可します。 型引数の値と根の身体の部分のcontent typeが異なるなら、Userエージェントの振舞いは未定義です。
3.2. The Start Parameter
3.2. スタートパラメタ
The start parameter, if given, is the content-ID of the compound object's "root". If not present the "root" is the first body part in the Multipart/Related entity. The "root" is the element the applications processes first.
考えて、スタートパラメタは合成オブジェクトの「根」の満足しているIDです。 プレゼントでないなら、「根」はMultipart/関連の実体で最初の身体の部分です。 「根」はアプリケーションが最初に処理する要素です。
3.3. The Start-Info Parameter
3.3. スタートインフォメーションパラメタ
Additional information can be provided to an application by the start-info parameter. It contains either a string or points, via a content-ID, to another MIME entity in the message. A typical use might be to provide additional command line parameters or a MIME entity giving auxiliary information for processing the compound object.
スタートインフォメーションパラメタで追加情報をアプリケーションに提供できます。 それは満足しているID経由でメッセージの別のMIME実体にストリングかポイントのどちらかを含んでいます。 典型的な使用は処理のための補助の情報に合成オブジェクトを与えながら追加コマンドラインのパラメータかMIME実体を提供することであるかもしれません。
Applications that use Multipart/Related must specify the interpretation of start-info. User Agents shall provide the parameter's value to the processing application. Processes can distinguish a start-info reference from a token or quoted-string by examining the first non-white-space character, "<" indicates a reference.
関係づけられたMultipart/を使用するアプリケーションはスタートインフォメーションの解釈を指定しなければなりません。 ユーザエージェントはパラメタの値を処理アプリケーションに提供するものとします。 プロセスはトークンか引用文字列と最初の非空白類文字を調べることによって、スタートインフォメーション参照を区別できて、"<"は参照を示します。
3.4. Syntax
3.4. 構文
related-param := [ ";" "start" "=" cid ]
[ ";" "start-info" "="
( cid-list / value ) ]
[ ";" "type" "=" type "/" subtype ]
; order independent
「関連してparamな:=[「;」「始め」はCidと「等しい」][(Cidリスト/値)と「等しい」という「;」「スタートインフォメーション」][「;」「タイプ」は」 タイプ」 /「副-タイプ」と「等しいです」]。 オーダー独立者
cid-list := cid cid-list
Cidリスト:=Cid Cidリスト
cid := msg-id ; c.f. [822]
Cid:=msg-イド。 c. f。 [822]
Levinson Standards Track [Page 3] RFC 2387 Multipart/Related August 1998
レヴィンソンStandardsは複合の、または、関連の1998年8月にRFC2387を追跡します[3ページ]。
value := token / quoted-string ; c.f. [MIME]
; value cannot begin with "<"
:=トークン/引用文字列を評価してください。 c. f。 [MIME]。 値は"<"で始まることができません。
Note that the parameter values will usually require quoting. Msg-id contains the special characters "<", ">", "@", and perhaps other special characters. If msg-id contains quoted-strings, those quote marks must be escaped. Similarly, the type parameter contains the special character "/".
通常、パラメタ値が、引用するのを必要とすることに注意してください。 エムエスジーイドは"<"という特殊文字、">"、"@"、および恐らく他の特殊文字を含んでいます。 msg-イドが引用文字列を含んでいるなら、それらの引用符から逃げなければなりません。 「同様に、型引数は特殊文字を含んでいる」という/、」
4. Handling Content-Disposition Headers
4. 取り扱い満足している気質ヘッダー
Content-Disposition Headers [DISP] suggest presentation styles for MIME body parts. [DISP] describes two presentation styles, called the disposition type, INLINE and ATTACHMENT. These, used within a multipart entity, allow the sender to suggest presentation information. [DISP] also provides for an optional storage (file) name. Content-Disposition headers could appear in one or more body parts contained within a Multipart/Related entity.
満足している気質Headers[DISP]はMIME身体の部分にプレゼンテーションスタイルを勧めます。 気質のタイプ、INLINE、およびATTACHMENTは、[DISP]が2つのプレゼンテーションスタイルについて説明すると呼びました。 複合実体の中で使用されたこれらで、送付者はプレゼンテーション情報を勧めることができます。 また、[DISP]は任意のストレージ(ファイル)名に備えます。 満足している気質ヘッダーは、1つ以上の身体の部分でMultipart/関連の実体の中に含まれているように見えることができました。
Using Content-Disposition headers in addition to Multipart/Related provides presentation information to User Agents that do not recognize Multipart/Related. They will treat the multipart as Multipart/Mixed and they may find the Content-Disposition information useful.
Multipart/関連に加えてContent-気質ヘッダーを使用すると、プレゼンテーション情報はMultipart/が関係したと認めないUserエージェントに提供されます。 彼らはMultipart/Mixedとして複合を扱うでしょう、そして、Content-気質情報が役に立つのがわかるかもしれません。
With Multipart/Related however, the application processing the compound object determines the presentation style for all the contained parts. In that context the Content-Disposition header information is redundant or even misleading. Hence, User Agents that understand Multipart/Related shall ignore the disposition type within a Multipart/Related body part.
しかしながら、Multipart/が関係づけられている状態で、合成オブジェクトを処理するアプリケーションはすべての含まれた部品にプレゼンテーションスタイルを決定します。 その文脈では、Content-気質ヘッダー情報は、余分であるか、または紛らわしくさえあります。 したがって、Multipart/が関係したのを理解しているUserエージェントはMultipart/関連の身体の部分の中で気質タイプを無視するものとします。
It may be possible for a User Agent capable of handling both Multipart/Related and Content-Disposition headers to provide the invoked application the Content-Disposition header's optional filename parameter to the Multipart/Related. The use of that information will depend on the specific application and should be specified when describing the handling of the corresponding compound object. Such descriptions would be appropriate in an RFC registering that object's media type.
Multipart/が関係づけた両方を扱うことができるUserエージェントとContent-気質ヘッダーがMultipart/へのContent-気質ヘッダーの任意のファイル名パラメタが関係づけた呼び出された利用を提供するのは、可能であるかもしれません。 その情報の使用は、特定のアプリケーションによって、対応する合成オブジェクトの取り扱いについて説明するとき、指定されるべきです。 そのような記述はそのオブジェクトのメディアタイプを示すRFCで適切でしょう。
5. Examples
5. 例
5.1 Application/X-FixedRecord
5.1 アプリケーション/X-FixedRecord
The X-FixedRecord content-type consists of one or more octet-streams and a list of the lengths of each record. The root, which lists the record lengths of each record within the streams. The record length
X-FixedRecord content typeは1つ以上の八重奏ストリームとそれぞれの記録の長さのリストから成ります。 根。(そのそれぞれのレコード長のリストはその根のためにストリームの中に. レコード長を記録します)。
Levinson Standards Track [Page 4] RFC 2387 Multipart/Related August 1998
レヴィンソンStandardsは複合の、または、関連の1998年8月にRFC2387を追跡します[4ページ]。
list, type Application/X-FixedRecord, consists of a set of INTEGERs in ASCII format, one per line. Each INTEGER gives the number of octets from the octet-stream body part that constitute the next "record".
Application/X-FixedRecordは、リストがASCII書式、1系列あたり1つでINTEGERsの1セットから成るのをタイプします。 各INTEGERは八重奏ストリーム身体の部分からの次の「記録」を構成する八重奏の数を与えます。
The example below, uses a single data block.
以下の例、ただ一つのデータが妨げる用途。
Content-Type: Multipart/Related; boundary=example-1
start="<950120.aaCC@XIson.com>";
type="Application/X-FixedRecord"
start-info="-o ps"
コンテントタイプ: 複合か関連。 「境界=例-1スタート= "<950120.aaCC@XIson.com 、gt;、」、。 「」 -o=「アプリケーション/X-FixedRecord」スタートインフォメーション=psをタイプしてください」
--example-1
Content-Type: Application/X-FixedRecord
Content-ID: <950120.aaCC@XIson.com>
--例-1コンテントタイプ: アプリケーション/X-FixedRecordコンテントID: <950120.aaCC@XIson.com>。
25
10
34
10
25
21
26
10
--example-1
Content-Type: Application/octet-stream
Content-Description: The fixed length records
Content-Transfer-Encoding: base64
Content-ID: <950120.aaCB@XIson.com>
25 10 34 10 25 21 26 10--例-1コンテントタイプ: 八重奏アプリケーション/ストリームの満足している記述: コード化して、Contentが移している固定長レコード: base64コンテントID: <950120.aaCB@XIson.com>。
T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
NrIHF1YWNrCkUgSSBFIEkgTwo=
T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW NrIHF1YWNrCkUgSSBFIEkgTwo=
--example-1--
--例-1--
Levinson Standards Track [Page 5] RFC 2387 Multipart/Related August 1998
レヴィンソンStandardsは複合の、または、関連の1998年8月にRFC2387を追跡します[5ページ]。
5.2 Text/X-Okie
5.2Xテキスト/移住農業労働者
The Text/X-Okie is an invented markup language permitting the inclusion of images with text. A feature of this example is the inclusion of two additional body parts, both picture. They are referred to internally by the encapsulated document via each picture's body part content-ID. Usage of "cid:", as in this example, may be useful for a variety of compound objects. It is not, however, a part of the Multipart/Related specification.
X Text/移住農業労働者はテキストがあるイメージの包含を可能にする発明されたマークアップ言語です。 両方が、この例の特徴が2つの追加身体の部分の包含であると描写します。 各画像の身体の部分でそれらはカプセル化されたドキュメントによって内部的に満足しているIDであることで言及されます。 用法、「Cid:」 この例のように、さまざまな合成オブジェクトの役に立つかもしれません。 しかしながら、それはMultipart/関連の仕様の一部ではありません。
Content-Type: Multipart/Related; boundary=example-2;
start="<950118.AEBH@XIson.com>"
type="Text/x-Okie"
コンテントタイプ: 複合か関連。 境界は例-2と等しいです。 「= "<950118.AEBH@XIson.com を始動してください、gt;、」 タイプは「xテキスト/移住農業労働者」と等しいです。
--example-2
Content-Type: Text/x-Okie; charset=iso-8859-1;
declaration="<950118.AEB0@XIson.com>"
Content-ID: <950118.AEBH@XIson.com>
Content-Description: Document
--例-2コンテントタイプ: xテキスト/移住農業労働者。 charset=iso-8859-1。 「宣言= "<950118.AEB0@XIson.com 、gt;、」 コンテントID: <の950118.AEBH@XIson.comの>の満足している記述: ドキュメント
{doc}
This picture was taken by an automatic camera mounted ...
{image file=cid:950118.AECB@XIson.com}
{para}
Now this is an enlargement of the area ...
{image file=cid:950118:AFDH@XIson.com}
{/doc}
--example-2
Content-Type: image/jpeg
Content-ID: <950118.AFDH@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture A
取り付けられた自動カメラはこれが描写するdocを取りました… イメージ・ファイルがCid: 950118.AECB@XIson.com と等しい、パラ、現在、これは領域の拡大です… /がdocするイメージ・ファイル=Cid:950118: AFDH@XIson.com --例-2コンテントタイプ: イメージ/jpegコンテントID: <の950118.AFDH@XIson.comの>の満足している転送コード化: BASE64の満足している記述: 画像A
[encoded jpeg image]
--example-2
Content-Type: image/jpeg
Content-ID: <950118.AECB@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture B
[jpegイメージをコード化します]--例-2コンテントタイプ: イメージ/jpegコンテントID: <の950118.AECB@XIson.comの>の満足している転送コード化: BASE64の満足している記述: 画像B
[encoded jpeg image]
--example-2--
[jpegイメージをコード化します]--例-2--
5.3 Content-Disposition
5.3 満足している気質
In the above example each image body part could also have a Content- Disposition header. For example,
また、上記の例に、それぞれのイメージ身体の部分には、Content気質ヘッダーがあるかもしれません。 例えば
Levinson Standards Track [Page 6] RFC 2387 Multipart/Related August 1998
レヴィンソンStandardsは複合の、または、関連の1998年8月にRFC2387を追跡します[6ページ]。
--example-2
Content-Type: image/jpeg
Content-ID: <950118.AECB@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture B
Content-Disposition: INLINE
--例-2コンテントタイプ: イメージ/jpegコンテントID: <の950118.AECB@XIson.comの>の満足している転送コード化: BASE64の満足している記述: B満足している気質について描写してください: インライン
[encoded jpeg image]
--example-2--
[jpegイメージをコード化します]--例-2--
User Agents that recognize Multipart/Related will ignore the Content-Disposition header's disposition type. Other User Agents will process the Multipart/Related as Multipart/Mixed and may make use of that header's information.
Multipart/が関係したと認めるユーザエージェントがContent-気質ヘッダーの気質タイプを無視するでしょう。 他のUserエージェントは、Multipart/Mixedとして関係づけられたMultipart/を処理して、そのヘッダーの情報を利用するかもしれません。
6. User Agent Requirements
6. ユーザエージェント要件
User agents that do not recognize Multipart/Related shall, in accordance with [MIME], treat the entire entity as Multipart/Mixed. MIME User Agents that do recognize Multipart/Related entities but are unable to process the given type should give the user the option of suppressing the entire Multipart/Related body part shall be.
[MIME]に従って、Multipart/が関係したと認めないユーザエージェントはMultipart/Mixedとして全体の実体を扱うものとします。 ユーザに与えるべきであるMultipart/関連の実体を認識しますが、付与を処理できないUserエージェントが全体のMultipart/関連の身体の部分を抑圧するオプションをタイプするMIMEはそうでしょう。
Existing MIME-capable mail user agents (MUAs) handle the existing media types in a straightforward manner. For discrete media types (e.g. text, image, etc.) the body of the entity can be directly passed to a display process. Similarly the existing composite subtypes can be reduced to handing one or more discrete types. Handling Multipart/Related differs in that processing cannot be reduced to handling the individual entities.
既存のMIME有能なメールユーザエージェント(MUAs)は正直な態度で既存のメディアタイプを扱います。 離散的なメディアタイプ(例えば、テキスト、イメージなど)において、実体のボディーをディスプレイプロセスに直接通過できます。 同様に、既存の合成血液型亜型は1つ以上の離散的なタイプを手渡すのに減少できます。 Multipart/が関係づけた取り扱いは個々の実体を扱うのに処理を抑えることができないという点において異なります。
The following sections discuss what information the processing application requires.
以下のセクションは、処理アプリケーションがどんな情報を必要とするかを論じます。
It is possible that an application specific "receiving agent" will manipulate the entities for display prior to invoking actual application process. Okie, above, is an example of this; it may need a receiving agent to parse the document and substitute local file names for the originator's file names. Other applications may just require a table showing the correspondence between the local file names and the originator's. The receiving agent takes responsibility for such processing.
実際のアプリケーション・プロセスを呼び出す前にアプリケーションの特定の「受信エージェント」がディスプレイのために実体を操るのは、可能です。 移住農業労働者は上のこの例です。 それは、受信エージェントが創始者のファイル名のためにドキュメントと代わりのローカルファイル名を分析する必要があるかもしれません。 他のアプリケーションはただローカルファイル名と創始者のものとの通信を示しているテーブルを必要とするかもしれません。 受信エージェントはそのような処理への責任を取ります。
6.1 Data Requirements
6.1 データ要件
MIME-capable mail user agents (MUAs) are required to provide the application:
MIME有能なメールユーザエージェント(MUAs)は利用を提供しなければなりません:
Levinson Standards Track [Page 7] RFC 2387 Multipart/Related August 1998
レヴィンソンStandardsは複合の、または、関連の1998年8月にRFC2387を追跡します[7ページ]。
(a) the bodies of the MIME entities and the entity Content-* headers,
(a) MIME実体のボディーと実体Content-*ヘッダー
(b) the parameters of the Multipart/Related Content-type header, and
そして(b) Multipart/関連の文書内容ヘッダーのパラメタ。
(c) the correspondence between each body's local file name, that
body's header data, and, if present, the body part's content-ID.
(c) 各ボディーのローカルファイル名と、そのボディーのヘッダー・データと、存在しているときの身体の部分の満足しているIDとの通信。
6.2 Storing Multipart/Related Entities
6.2 複合の、または、関連の実体を保存すること。
The Multipart/Related media type will be used for objects that have internal linkages between the body parts. When the objects are stored the linkages may require processing by the application or its receiving agent.
Multipart/関連のメディアタイプは身体の部分の間に内部結合を持っているオブジェクトに使用されるでしょう。 オブジェクトが保存されるとき、リンケージはアプリケーションによる処理かその受信エージェントを必要とするかもしれません。
6.3 Recursion
6.3 再帰
MIME is a recursive structure. Hence one must expect a Multipart/Related entity to contain other Multipart/Related entities. When a Multipart/Related entity is being processed for display or storage, any enclosed Multipart/Related entities shall be processed as though they were being stored.
MIMEは再帰的な構造です。 したがって、Multipart/関連の実体が他のMultipart/関連の実体を含むと予想しなければなりません。 Multipart/関連の実体がディスプレイかストレージのために処理されているとき、まるでそれらが保存されているかのようにどんな同封のMultipart/関連の実体も処理されるものとします。
6.4 Configuration Considerations
6.4 構成問題
It is suggested that MUAs that use configuration mechanisms, see [CFG] for an example, refer to Multipart/Related as Multi- part/Related/<type>, were <type> is the value of the "type" parameter.
[CFG]が、例に関して構成メカニズムを使用するMUAsがタイプ>をMultipartを参照したか、またはMulti part/Related/<として関係づけたのを見て、「タイプ」パラメタの値が<がタイプ>であったならそうであると示唆されます。
7. Security Considerations
7. セキュリティ問題
Security considerations relevant to Multipart/Related are identical to those of the underlying content-type.
Multipart/に関連している問題が関係づけたセキュリティは基本的なcontent typeのものと同じです。
8. Acknowledgments
8. 承認
This proposal is the result of conversations the author has had with many people. In particular, Harald A. Alvestrand, James Clark, Charles Goldfarb, Gary Houston, Ned Freed, Ray Moody, and Don Stinchfield, provided both encouragement and invaluable help. The author, however, take full responsibility for all errors contained in this document.
この提案は作者が多くの人々と共に持っていた会話の結果です。 特に、ハラルドA.Alvestrand(ジェームス・クラーク、チャールズGoldfarb、ゲーリー・ヒューストン、ネッド・フリード、レイMoody、およびドンStinchfield)は奨励と非常に貴重な助けの両方を提供しました。 しかしながら、作者は本書では含まれたすべての誤りへの完全な責任を取ります。
Levinson Standards Track [Page 8] RFC 2387 Multipart/Related August 1998
レヴィンソンStandardsは複合の、または、関連の1998年8月にRFC2387を追跡します[8ページ]。
9. References
9. 参照
[822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, August 1982.
[822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[CID] Levinson, E., and J. Clark, "Message/External-Body
Content-ID Access Type", RFC 1873, December 1995,
Levinson, E., "Message/External-Body Content-ID Access
Type", Work in Progress.
[Cid] レヴィンソン、E.、およびJ.クラーク、「外部のメッセージ/ボディーコンテントIDアクセス型」、RFC1873、1995年12月、レヴィンソン、E.、「外部のメッセージ/ボディーコンテントIDアクセス型」は進行中で働いています。
[CFG] Borenstein, N., "A User Agent Configuration Mechanism For
Multimedia Mail Format Information", RFC 1524, September
1993.
[CFG]Borenstein、N.、「マルチメディアメール書式情報のためのユーザエージェント構成メカニズム」、RFC1524、1993年9月。
[DISP] Troost, R., and S. Dorner, "Communicating Presentation
Information in Internet Messages: The Content-
Disposition Header", RFC 1806, June 1995.
[DISP] Troost、R.、およびS.デルナー、「インターネットでプレゼンテーション情報を伝えるのは通信します」。 「内容気質ヘッダー」、RFC1806、1995年6月。
[MIME] Borenstein, N., and Freed, N., "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
Borenstein、[MIME]N.とフリード、N.、「マルチパーパスインターネットメールエクステンション(MIME)パート1:」 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
9. Author's Address
9. 作者のアドレス
Edward Levinson 47 Clive Street Metuchen, NJ 08840-1060 USA
エドワードレヴィンソン47クライヴ通りメタチェン、ニュージャージー08840-1060米国
Phone: +1 908 494 1606 EMail: XIson@cnj.digex.com
以下に電話をしてください。 +1 1606年の908 494メール: XIson@cnj.digex.com
10. Changes from previous draft (RFC 2112)
10. 前の草稿からの変化(RFC2112)
Corrected cid urls to conform to RFC 2111; the angle brackets were removed.
RFC2111に従う直っているCid urls。 角ブラケットは取り外されました。
Levinson Standards Track [Page 9] RFC 2387 Multipart/Related August 1998
レヴィンソンStandardsは複合の、または、関連の1998年8月にRFC2387を追跡します[9ページ]。
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Levinson Standards Track [Page 10]
レヴィンソン標準化過程[10ページ]
一覧
スポンサーリンク
