RFC1873 日本語訳
1873 Message/External-Body Content-ID Access Type. E. Levinson. December 1995. (Format: TXT=5878 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Levinson
Request for Comments: 1873 Accurate Information Systems, Inc.
Category: Experimental J. Clark
December 1995
コメントを求めるワーキンググループE.レヴィンソン要求をネットワークでつないでください: 1873年の的確な情報システムInc.カテゴリ: 実験的なJ.クラーク1995年12月
Message/External-Body Content-ID Access Type
外部のメッセージ/ボディーコンテントIDアクセス型
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
When using MIME [MIME] to encapsulate a structured object that consist of many elements, for example an SGML [SGML] document, a single element may occur several times. An encapsulation normally maps each of the structured objects elements to a MIME entity. It is useful to include elements that occur multiple time exactly once. To accomplish that and to preserve the object structure it is desirable to unambiguously refer to another body part of the same message.
多くの要素から成る構造化されたオブジェクト、例えばSGML[SGML]ドキュメントをカプセル化するのに、MIME[MIME]を使用するとき、ただ一つの要素は何度か現れるかもしれません。 通常、カプセル化はそれぞれの構造化されたオブジェクト要素をMIME実体に写像します。 まさに複数の回の間に一度現れる要素を含んでいるのは役に立ちます。 それを達成して、オブジェクト構造を保存するために、明白に同じメッセージの別の身体の部分について言及するのは望ましいです。
The existing MIME Content-Type Message/External-Body access-types allow a MIME entity (body-part) to refer to an object that is not in the message by specifying how to access that object. The Content-ID access method described in this document provides the capability to refer to an object within the message.
既存のMIMEコンテントタイプ外部のMessage/本体アクセス型はMIME実体(身体部分)をメッセージにそのオブジェクトにアクセスする方法を指定することによってないオブジェクトについて言及させます。 本書では説明されたコンテントIDアクセス法はメッセージの中でオブジェクトについて言及する能力を提供します。
1. Introduction
1. 序論
Consider a MIME multipart entity several of whose body parts contain the same data (body) but different parameters or Content-* headers. Representing those body parts without duplicating the data in each one promotes efficient use of resources (bandwidth and storage space). To achieve these benefits an access-type is defined that permits one message part to refer to another one in the same message.
いくつかの身体の部分が同じデータ(ボディー)を含むMIMEの複合実体にもかかわらず、異なったパラメタかContent-*がヘッダーであると考えてください。 それぞれにデータをコピーしないでそれらの身体の部分を表すと、リソース(帯域幅と集積スペース)の効率的な使用は促進されます。 これらの利益を達成するために、1つのメッセージ部分が同じメッセージの別の1つについて言及することを許可するアクセス型は定義されます。
Levinson & Clark Experimental [Page 1] RFC 1873 Access Type Content-ID December 1995
レヴィンソンとクラーク実験的な[1ページ]RFC1873Accessは1995年12月にコンテントIDをタイプします。
2. The Content-ID Access Type
2. コンテントIDアクセス型
2.1 Registration Information
2.1 レジスト情報
MIME access-type name: content-id
MIMEアクセス型は以下を命名します。 満足しているイド
Required parameters: none
必要なパラメタ: なし
Optional parameters: none
任意のパラメタ: なし
Published specification: this document
広められた仕様: このドキュメント
Person & email address
to contact for further
information: Ed Levinson <ELevinson@accurate.com>
詳細のために連絡する人とEメールアドレス: エド Levinson <ELevinson@accurate.com 、gt。
Additional requirements:
追加要件:
The content-id header of the access-type=content-id MIME
entity must match (be identical to) exactly one content-id
in the same message, excluding other access-type=content-id
entities. Thus, the content-id access type can only occur
within a multipart message and can refer to another body
part anywhere in the same message.
満足しているイドのMIMEアクセス型の満足しているイドヘッダー=実体が合わなければならない、(同じである、)、まさに同じメッセージの1つの満足しているイド、他のアクセス型を遮断するのは満足しているイドの実体と等しいです。 したがって、満足しているイドアクセス型は、複合メッセージの中に起こることができるだけであって、別の身体の部分を同じメッセージでどこでもと呼ぶことができます。
A MIME User Agent (MUA) constructs the resultant MIME body
part as described below. We call the access-type=content-id
MIME entity the referring body part and the MIME body part
to which it refers, the one with the matching content-id,
the referenced body part. The MIME entity that results from
content-id access type consists of:
MIME Userエージェント(MUA)は以下で説明されるように結果のMIME身体の部分を構成します。 私たちは、満足しているイドのMIMEアクセス型=実体を参照している身体の部分とそれが参照されるMIME身体の部分と呼びます、合っている満足しているイドがあるもの、参照をつけられた身体の部分。 満足しているイドアクセスからの結果がタイプするMIME実体は以下から成ります。
(a) the referenced body part's content-type header,
(a) 参照をつけられた身体の部分のcontent typeヘッダー
(b) the referring body part's headers except its content-type
header,
(b) content typeヘッダー以外の参照している身体の部分のヘッダー
(c) any headers in the referenced body part not in the referring
one,
(c) 参照をつけられたボディーのどんなヘッダーもいずれの参照ものでも離れていません。
(d) the line separating the headers from the body, and
そして(d) ボディーからヘッダーを分離する系列。
(e) the referenced body part's body.
(e) 参照をつけられた身体の部分のボディー。
Levinson & Clark Experimental [Page 2] RFC 1873 Access Type Content-ID December 1995
レヴィンソンとクラーク実験的な[2ページ]RFC1873Accessは1995年12月にコンテントIDをタイプします。
2.2 Example Usage
2.2 例の用法
The following example shows a message that consists of two identical images.
以下の例は2つの同じイメージから成るメッセージを示しています。
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
boundary=tiger-lily
MIMEバージョン: 1.0コンテントタイプ: 複合/は混入しました。 境界=オニユリ
--tiger-lily
Content-Type: image/jpeg
Content-ID: <950323.1552@XIson.com>
--オニユリコンテントタイプ: イメージ/jpegコンテントID: <950323.1552@XIson.com>。
AAAcdb...
--tiger-lily
Content-type: Message/External-Body;
access-type=content-id
Content-ID: <950323.1552@XIson.com>
Content-Description:
This body part is duplicated by reference
AAAcdb… --オニユリ文書内容: 外部のメッセージ/ボディー。 アクセス型は満足しているイドのコンテントIDと等しいです: <の950323.1552@XIson.comの>の満足している記述: この身体の部分は参照でコピーされます。
--tiger-lily--
--オニユリ--
The equivalent MIME entity for the second body part is:
2番目の身体の部分への同等なMIME実体は以下の通りです。
--tiger-lily
Content-Type: image/jpeg
Content-ID: <950323.1552@XIson.com>
Content-Description:
This body part is duplicated by reference
--オニユリコンテントタイプ: イメージ/jpegコンテントID: <の950323.1552@XIson.comの>の満足している記述: この身体の部分は参照でコピーされます。
AAAcdb...
--tiger-lily
AAAcdb… --オニユリ
3. Security Considerations
3. セキュリティ問題
The content-id access-type does not impact the security of messages or systems. The referenced MIME entity may have security implications.
満足しているイドアクセス型はメッセージかシステムのセキュリティに影響を与えません。参照をつけられたMIME実体には、セキュリティ意味があるかもしれません。
Levinson & Clark Experimental [Page 3] RFC 1873 Access Type Content-ID December 1995
レヴィンソンとクラーク実験的な[3ページ]RFC1873Accessは1995年12月にコンテントIDをタイプします。
4. References
4. 参照
[822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, UDEL, August 1982.
[822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
[SGML] ISO 8879:1988, Information processing -- Text and office
systems -- Standard Generalized Markup Language (SGML).
[SGML]ISO、8879:1988 情報処理--テキストとオフィス・システム--標準のGeneralized Markup Language(SGML)。
[MIME] Borenstein, N., and N. Freed, "MIME (Multipurpose
Internet Mail Extensions) Part One: Mechanisms for
Specifying and Describing the Format of Internet
Message Bodies", RFC 1521, Bellcore, Innosoft,
September 1993.
[まねます] Borenstein、N.、およびN.フリード、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。
5. Authors' Addresses
5. 作者のアドレス
Edward Levinson Accurate Information Systems, Inc. 2 Industrial Way Eatontown, NJ 07724-2265 USA
エドワード・レヴィンソンAccurateの情報システムInc.2の産業道Eatontown、ニュージャージー07724-2265米国
Phone: +1 908 389 5550 EMail: <ELevinson@Accurate.com>
以下に電話をしてください。 +1 5550年の908 389メール: <ELevinson@Accurate.com>。
James Clark 90 Clarendon Road London W11 2HR UK
ジェームスクラーク90クラレンドン道路のロンドンのW11の2時間のイギリス
EMail: <jjc@jclark.com>
メール: <jjc@jclark.com>。
Levinson & Clark Experimental [Page 4]
レヴィンソンとクラークExperimentalです。[4ページ]
一覧
スポンサーリンク
