RFC2111 日本語訳
2111 Content-ID and Message-ID Uniform Resource Locators. E. Levinson. March 1997. (Format: TXT=9099 bytes) (Obsoleted by RFC2392) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Levinson Request for Comments: 2111 XIson, Inc. Category: Standards Track March 1997
コメントを求めるワーキンググループE.レヴィンソン要求をネットワークでつないでください: 2111年のXIson Inc.カテゴリ: 1997年の標準化過程行進
Content-ID and Message-ID Uniform Resource Locators
コンテントIDとMessage ID Uniform Resource Locator
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message.
Uniform Resource Locator(URL)計画、「Cid:」 そして、「中間:、」 メッセージの参照とメッセージの身体の部分を許容してください。 例えば、ただ一つの複合メッセージの中では、1つのHTML身体の部分が同じメッセージの他の部分の埋め込まれた指示するものを含むかもしれません。
1. Introduction
1. 序論
The use of [MIME] within email to convey Web pages and their associated images requires a URL scheme to permit the HTML to refer to the images or other data included in the message. The Content-ID Uniform Resource Locator, "cid:", serves that purpose.
ウェブページを伝えるメールとそれらの関連イメージの中の[MIME]の使用は、HTMLがメッセージに含まれていたイメージか他のデータを示すことを許可するためにURL計画を必要とします。 コンテントID Uniform Resource Locator、「Cid:」、その目的に役立ちます。
Similarly Net News readers use Message-IDs to link related messages together. The Message-ID URL provides a scheme, "mid:", to refer to such messages as a "resource".
同様に、ネットNews読者は、関連するメッセージを結びつけるのにMessage-IDを使用します。 Message-ID URLが計画を提供する、「中間:、」、「リソース」のようなメッセージを示すために。
The "mid" (Message-ID) and "cid" (Content-ID) URL schemes provide identifiers for messages and their body parts. The "mid" scheme uses (a part of) the message-id of an email message to refer to a specific message. The "cid" scheme refers to a specific body part of a message; its use is generally limited to references to other body parts in the same message as the referring body part. The "mid" scheme may also refer to a specific body part within a designated message, by including the content-ID's address.
「中間」の(Message ID)と「Cid」(コンテントID)URL計画はメッセージのための識別子とそれらの身体の部分を提供します。 「中間」の計画が使用する、(aが離れている、)、特定のメッセージを示すメールメッセージのメッセージイド。 「Cid」計画はメッセージの特定の身体の部分について言及します。 一般に、使用は参照している身体の部分と同じメッセージの他の身体の部分の参照に制限されます。 また、満足しているIDのアドレスを含んでいることによって、「中間」の計画は指定されたメッセージの中の特定の身体の部分について言及するかもしれません。
A note on terminology. The terms "body part" and "MIME entity" are used interchangeably. They refer to the headers and body of a MIME message, either the message itself or one of the body parts contained in a Multipart message.
用語に関する注。 用語「身体の部分」と「MIME実体」は互換性を持って使用されます。 彼らはMIMEメッセージ(Multipartメッセージに含まれたメッセージ自体か身体の部分の1つのどちらか)のヘッダーとボディーについて言及します。
Levinson Standards Track [Page 1] RFC 2111 CID and MID URLs March 1997
レヴィンソン標準化過程[1ページ]RFC2111Cidと1997年の中旬のURL行進
2. The MID and CID URL Schemes
2. 中間とCid URL計画
RFC1738 [URL] reserves the "mid" and "cid" schemes for Message-ID and Content-ID respectively. This memorandum defines the syntax for those URLs. Because they use the same syntactic elements they are presented together.
RFC1738[URL]はそれぞれMessage-IDとコンテントIDの「中間」と「Cid」計画を予約します。 このメモはそれらのURLのために構文を定義します。 彼らが同じ構文の要素を使用するので、それらは一緒に提示されます。
The URLs take the form
URLは形を取ります。
content-id = url-addr-spec
満足しているイド=url-addr-仕様
message-id = url-addr-spec
メッセージイド=url-addr-仕様
url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec
url-addr-仕様はaddr-仕様と等しいです。 RFC822addr-仕様のURLコード化
cid-url = "cid" ":" content-id
「Cid-urlは「Cid」と等しい」:、」 満足しているイド
mid-url = "mid" ":" message-id [ "/" content-id ]
「「中間中間のurl=」」:、」 メッセージイド[「/」満足しているイド]
Note: in Internet mail messages, the addr-spec in a Content-ID
[MIME] or Message-ID [822] header are enclosed in angle brackets
(<>). Since addr-spec in a Message-ID or Content-ID might contain
characters not allowed within a URL; any such character (including
"/", which is reserved within the "mid" scheme) must be hex-
encoded using the %hh escape mechanism in [URL].
以下に注意してください。 インターネット・メールでは、メッセージ、コンテントID[MIME]かMessage-ID[822]ヘッダーのaddr-仕様は角ブラケット(<>)に同封されます。 以来、Message-IDかコンテントIDにおけるaddr-仕様はURLの中に許容されなかったキャラクタを含むかもしれません。 「どんなそのようなキャラクタ、も(」 /を含んでいる、」、「中間」の計画の中で予約されるもの) %を使用することでコード化された十六進法がhhであったに違いないなら、中のメカニズム[URL]から逃げてください。
A "mid" URL with only a "message-id" refers to an entire message. With the appended "content-id", it refers to a body part within a message, as does a "cid" URL. The Content-ID of a MIME body part is required to be globally unique. However, in many systems that store messages, body parts are not indexed independently their context (message). The "mid" URL long form was designed to supply the context needed to support interoperability with such systems.
「メッセージイド」だけ、がある「中間」のURLは全体のメッセージを示します。 追加された「満足しているイド」で、それは「Cid」URLのようにメッセージの中の身体の部分について言及します。 MIME身体の部分のコンテントIDが、グローバルに特有になるのに必要です。 しかしながら、店からのメッセージ、身体の部分がそうでない多くのシステムでは、独自に、それらの文脈(メッセージ)は索引をつけていました。 「中間」のURL長いフォームは、相互運用性を支持するのに必要である文脈にそのようなシステムを供給するように設計されました。
A implementation conforming to this specification is required to support the "mid" URL long form (message-id/content-id). Conforming implementations can choose to, but are not required to, take advantage of the content-id's uniqueness and interpret a "cid" URL to refer to any body part within the message store.
この仕様に従う実現が、「中間」のURL長いフォーム(満足しているメッセージイド/イドの)を支持するのに必要です。 従う実現は、選ぶことができますが、必要ではありません、そして、満足しているイドのユニークさを利用してください、そして、「Cid」URLを解釈して、メッセージ店の中のあらゆる身体の部分について言及してください。
In limited circumstances (e.g., within multipart/alternate), a single message may contain several body parts that have the same Content-ID. That occurs, for example, when identical data can be accessed through different methods [MIME, sect. 7.2.3]. In those cases, conforming implementations are required to use the rules of the containing MIME entity (e.g., multi-part/alternate) to select the body part to which the Content-ID refers.
限られた事情(例えば、複合か交互な中の)では、ただ一つのメッセージは同じコンテントIDを持っているいくつかの身体の部分を含むかもしれません。 異なった方法で同じデータにアクセスできるとき、例えば、それは起こります。[MIME、セクト。 7.2.3]. それらの場合では、従う実現が、コンテントIDが参照される身体の部分を選択するのに含んでいるMIME実体(例えば、複合/補欠)の規則を使用するのに必要です。
Levinson Standards Track [Page 2] RFC 2111 CID and MID URLs March 1997
レヴィンソン標準化過程[2ページ]RFC2111Cidと1997年の中旬のURL行進
A "cid" URL is converted to the corresponding Content-ID message header [MIME] by removing the "cid:" prefix, converting %hh hex- escaped characters to their ASCII equivalents and enclosing the remaining parts with an angle bracket pair, "<" and ">". For example, "mid:foo4%25foo1@bar.net" corresponds to
「Cid」URLが取り外すことによって対応するコンテントIDメッセージヘッダー[MIME]に変換される、「Cid:」 接頭語、%hh十六進法を変換すると、彼らのASCII同等物へのキャラクタと角ブラケット組に残存部分を同封する、"<"、および">"逃げられました。 例えば、「中間、: foo4%25foo1@bar.net 、」、相当しています。
Message-ID: <foo4%foo1@bar.net>
Message ID: <foo4%foo1@bar.net>。
A "mid" URL is converted to a Message-ID or Message-ID/Content-ID pair in a similar fashion.
「中間」のURLは同様にMessage-IDかMessage-ID/コンテントID組に変えられます。
Both message-id and content-id are required to be globally unique. That is, no two different messages will ever have the same Message-ID addr-spec; no different body parts will ever have the same Content-ID addr-spec. A common technique used by many message systems is to use a time and date stamp along with the local host's domain name, e.g., 950124.162336@XIson.com.
メッセージイドと満足しているイドの両方が、グローバルに特有になるのに必要です。 すなわち、2つの異なったメッセージには、同じMessage-ID addr-仕様がないでしょう。 どんな異なった身体の部分にも、同じコンテントID addr-仕様がないでしょう。 多くのメッセージシステムによって使用される一般的なテクニックはローカル・ホストのドメイン名(例えば、 950124.162336@XIson.com )に伴うタイムスタンプを使用することです。
Some Examples
いくつかの例
The following message contains an HTML body part that refers to an image contained in another body part. Both body parts are contained in a Multipart/Related MIME entity. The HTML IMG tag contains a cidurl which points to the image.
以下のメッセージは別の身体の部分に含まれたイメージを示すHTML身体の部分を含んでいます。 両方の身体の部分はMultipart/関連のMIME実体に含まれています。 HTML IMGタグはイメージを示すcidurlを含んでいます。
From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example-1";
type=Text/HTML
From: foo1@bar.net To: foo2@bar.net Subject: 簡単な例のMime-バージョン: 1.0コンテントタイプ: 複合か関連する。 境界の=「境界例の1インチ」。 =テキスト/HTMLをタイプしてください。
--boundary-example 1
Content-Type: Text/HTML; charset=US-ASCII
--境界例の1つのコンテントタイプ: テキスト/HTML。 charsetは米国-ASCIIと等しいです。
... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as:
<IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">
… HTMLドキュメントの原本。(それは、例えば、他の身体の部分、以下などの声明を通してハイパーリンクを含むかもしれません)。 <IMG SRCが「Cid: foo4*foo1@bar.net 」ALT=と等しい、「IETFロゴ">"
--boundary-example-1
Content-ID: foo4*foo1@bar.net
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
--境界例1のコンテントID: foo4*foo1@bar.net コンテントタイプ: GIFの満足している転送イメージ/コード化: BASE64
Levinson Standards Track [Page 3] RFC 2111 CID and MID URLs March 1997
レヴィンソン標準化過程[3ページ]RFC2111Cidと1997年の中旬のURL行進
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4Aなど。
--boundary-example-1--
--境界例1--
The following message points to another message (hopefully still in the recipient's message store).
以下のメッセージは別のメッセージ(まだうまくいけば受取人のメッセージ店の)を示します。
From: bar@none.com
To: phooey@all.com
Subject: Here's how to do it
Content-type: text/html; charset=usascii
From: bar@none.com To: phooey@all.com Subject: ここに、どうそれに文書内容をするかがあります: テキスト/html。 charset=usascii
... The items in my
<A HREF= "mid:960830.1639@XIson.com/partA.960830.1639@XIson.com">
previous message</A>, shows how the approach you propose can be
used to accomplish ...
... 私の<A HREFの項目が等しい、「中間、: 960830.1639@XIson.com/partA.960830.1639@XIson.com、「>前のメッセージ</A>、…を達成するのに、あなたが提案するアプローチを使用できるショー」
3. Security Considerations
3. セキュリティ問題
The URLs defined here provide an addressing or referencing mechanism. The values of these URLs disclose no more about the originators environment than the corresponding Message-ID and Content-ID values. Where concern exists about such disclosures the originator of a message using mid and cid URLs must take precautions to insure that confidential information is not disclosed. Those precautions should already be in place to handle existing mail use of the Message-ID and Content-ID.
ここで定義されたURLはアドレシングか参照箇所メカニズムを提供します。 これらのURLの値は、対応するMessage-IDとコンテントID値より創始者環境に関していいえを明らかにします。 関心がそのような公開に関して存在しているところでは、中間とCid URLを使用するメッセージの創始者は、秘密情報が明らかにされないのを保障するために予防策を講しなければなりません。 Message-IDとコンテントIDの既存のメール使用を扱うために、それらの注意が適所に既にあるべきです。
4. References
4. 参照
[822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages," August 1982, University of Delaware, STD 11, RFC
822.
[822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、1982年8月、デラウエア大学、STD11(RFC822)。
[MIME] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies,"
September 1993, RFC 1521.
[まねます] N.Borenstein、N.フリード、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 1993年RFC1521年9月の「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム。」
[URL] Berners-Lee, T., Masinter, L., and McCahill, M., "Uniform
Resource Locators (URL)," December 1994.
1994年12月のバーナーズ・リーとT.とMasinter、L.とMcCahill、M.、「Uniform Resource Locator(URL)」という[URL。]
[MULREL] E. Levinson, "The MIME Multipart/Related Content-type,"
December 1995, RFC 1874.
「MIMEの複合の、または、関連の文書内容」、1995年RFC1874年12月の[MULREL]E.レヴィンソン。
Levinson Standards Track [Page 4] RFC 2111 CID and MID URLs March 1997
レヴィンソン標準化過程[4ページ]RFC2111Cidと1997年の中旬のURL行進
5. Acknowledgments
5. 承認
The original concept of "mid" and "cid" URLs were part of the Tim Berners-Lee's original vision of the World Wide Web. The ideas and design have benefited greatly by discussions with Harald Alvestrand, Dan Connolly, Roy Fielding, Larry Masinter, Jacob Palme, and others in the MHTML working group.
「中間」と「Cid」URLのオリジナルの概念はティム・バーナーズ・リーのWWWのオリジナルのビジョンの一部です。 考えとデザインは大いにMHTMLワーキンググループでハラルドAlvestrand、ダン・コノリー、ロイFielding、ラリーMasinter、ヤコブ・パルメ、および他のものとの議論の利益を得ました。
6. Author's Address
6. 作者のアドレス
Edward Levinson 47 Clive Street Metuchen, NJ 08840-1060 USA +1 908 549 3716 <XIson@cnj.digex.net>
エドワード・レヴィンソン47クライヴメタチェン、通りニュージャージー08840-1060米国+1 908 549 3716 <XIson@cnj.digex.net 、gt。
Levinson Standards Track [Page 5]
レヴィンソン標準化過程[5ページ]
一覧
スポンサーリンク
