RFC2392 日本語訳
2392 Content-ID and Message-ID Uniform Resource Locators. E. Levinson. August 1998. (Format: TXT=11141 bytes) (Obsoletes RFC2111) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Levinson Request for Comments: 2392 August 1998 Obsoletes: 2111 Category: Standards Track
コメントを求めるワーキンググループE.レヴィンソン要求をネットワークでつないでください: 2392 1998年8月は以下を時代遅れにします。 2111年のカテゴリ: 標準化過程
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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身体の部分が同じメッセージの他の部分の埋め込まれた指示するものを含むかもしれません。
Changes from (RFC 2111)
変化します。(RFC2111)
Clarified the example on page 3 on of converting cid URLs to Content-IDs. The example now uses a cid URL instead of an mid.
Cid URLをコンテントIDに変換するのにおいてオンな3ページの例をはっきりさせました。 の代わりにする、例が現在Cid URLを使用する、中間です。
Corrected the example messages to have the correct Content-ID form; they now use the angle brackets. Added a Message-ID header to the second example.
正しいコンテントIDが形成させられる例のメッセージを修正します。 彼らは現在、角ブラケットを使用します。 Message-IDヘッダーを2番目の例に追加しました。
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が計画を提供する、「中間:、」、「リソース」のようなメッセージを示すために。
Levinson Standards Track [Page 1] RFC 2392 Message- & Content-ID URLs August 1998
レヴィンソン標準化過程2392年のRFCメッセージとコンテントID URL[1ページ]1998年8月
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つのどちらか)のヘッダーとボディーについて言及します。
2. The MID and CID URL Schemes
2. 中間とCid URL計画
RFC 1738 [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=」」:、」 メッセージイド[「/」満足しているイド]
Notes: In Internet mail messages, the addr-spec in a Content-ID
[MIME] or Message-ID [822] header is 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の中に許容されなかったキャラクタを含むかもしれません。 「どんなそのようなキャラクタ、も(」 /を含んでいる、」、どれが「中間」の計画) 必須の中で予約されるかは、十六進法によって[URL]の%hhな逃避機制を使用することでコード化されています。
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長いフォームは、相互運用性を支持するのに必要である文脈にそのようなシステムを供給するように設計されました。
Levinson Standards Track [Page 2] RFC 2392 Message- & Content-ID URLs August 1998
レヴィンソン標準化過程2392年のRFCメッセージとコンテントID URL[2ページ]1998年8月
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. In those cases, conforming implementations are required to use the rules of the containing MIME entity (e.g., multipart/alternate) to select the body part to which the Content-ID refers.
限られた事情(例えば、複合か交互な中の)では、ただ一つのメッセージは同じコンテントIDを持っているいくつかの身体の部分を含むかもしれません。 異なった方法で同じデータにアクセスできるとき、例えば、それは起こります。 それらの場合では、従う実現が、コンテントIDが参照される身体の部分を選択するのに含んでいるMIME実体(例えば、複合/補欠)の規則を使用するのに必要です。
A "cid" URL is converted to the corresponding Content-ID message header [MIME] by removing the "cid:" prefix, converting the % encoded character to their equivalent US-ASCII characters, and enclosing the remaining parts with an angle bracket pair, "<" and ">". For example, "cid:foo4%25foo1@bar.net" corresponds to
「Cid」URLが取り外すことによって対応するコンテントIDメッセージヘッダー[MIME]に変換される、「Cid:」 接頭語、%を変換すると、彼らの同等な米国-ASCII文字、角ブラケット組がある残存部分を同封する、"<"、および">"へのキャラクタはコード化されました。 例えば、「Cid: foo4%25foo1@bar.net 」は相当しています。
Content-ID: <foo4%25foo1@bar.net>
コンテントID: <foo4%25foo1@bar.net>。
Reversing the process and converting URL special characters to their % encodings produces the original cid.
それらの%encodingsに過程を逆にして、URL特殊文字を変換すると、オリジナルのCidは生産されます。
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をタイプしてください。
Levinson Standards Track [Page 3] RFC 2392 Message- & Content-ID URLs August 1998
レヴィンソン標準化過程2392年のRFCメッセージとコンテントID URL[3ページ]1998年8月
--boundary-example 1
Content-Type: Text/HTML; charset=US-ASCII
--境界例の1つのコンテントタイプ: テキスト/HTML。 charsetは米国-ASCIIと等しいです。
to the other body part, for example through a statement such as:
<IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">
もう片方のボディーに、例えば、以下などの声明を通して離れてください。 <IMG SRCが「Cid: foo4*foo1@bar.net 」ALT=と等しい、「IETFロゴ">"
--boundary-example-1
--境界例1
Content-ID: <foo4*foo1@bar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
コンテントID: <foo4*foo1@bar.net>コンテントタイプ: GIFの満足している転送イメージ/コード化: BASE64
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
Message-ID: <970701.32784@VIers.none.com>
Content-type: text/html; charset=usascii
From: bar@none.com To: phooey@all.com Subject: ここに、どうMessage-IDをそれにするかがあります: <970701.32784@VIers.none.com>文書内容: テキスト/html。 charset=usascii
<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の既存のメール使用を扱うために、それらの注意が適所に既にあるべきです。
Levinson Standards Track [Page 4] RFC 2392 Message- & Content-ID URLs August 1998
レヴィンソン標準化過程2392年のRFCメッセージとコンテントID URL[4ページ]1998年8月
4. References
4. 参照
[822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", August 1982, STD 11, RFC 822, August 1982.
[822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、1982年8月、STD11、RFC822、1982年8月。
[MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[まねます] Borenstein、N.、およびN.フリード、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[URL] バーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[MULREL] Levinson, E., "The MIME Multipart/Related Content-type",
RFC 2387, August 1998.
[MULREL]レヴィンソン、1998年8月のE.、「MIMEの複合の、または、関連の文書内容」RFC2387。
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
エドワードレヴィンソン47クライヴ通りメタチェン、ニュージャージー08840-1060米国
Phone: +1 908 549 3716 EMail: XIson@cnj.digex.net
以下に電話をしてください。 +1 3716年の908 549メール: XIson@cnj.digex.net
Levinson Standards Track [Page 5] RFC 2392 Message- & Content-ID URLs August 1998
レヴィンソン標準化過程2392年のRFCメッセージとコンテントID URL[5ページ]1998年8月
7. Full Copyright Statement
7. 完全な著作権宣言文
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 6]
レヴィンソン標準化過程[6ページ]
一覧
スポンサーリンク
