RFC5064 日本語訳
5064 The Archived-At Message Header Field. M. Duerst. December 2007. (Format: TXT=20863 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Duerst Request for Comments: 5064 Aoyama Gakuin University Category: Standards Track December 2007
Duerstがコメントのために要求するワーキンググループM.をネットワークでつないでください: 5064年の青山学院大学カテゴリ: 標準化過程2007年12月
The Archived-At Message Header Field
格納、-、メッセージヘッダーフィールド
Status of This 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
要約
This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message.
このメモが新しいメールヘッダーフィールドを定義する、Archived、-、:、個々のメールメッセージの格納されたフォームに直リンクを提供するために。
Table of Contents
目次
1. Introduction ....................................................2
2. Header Field Definition .........................................2
2.1. Syntax .....................................................2
2.2. Multiple Archived-At Header Fields .........................3
2.3. Interaction with Message Fragmentation and Reassembly ......3
2.4. Syntax Extension for Internationalized Message Headers .....3
2.5. The X-Archived-At Header Field .............................4
3. Implementation and Usage Considerations .........................4
3.1. Formats of Archived Message ................................4
3.2. Implementation Considerations ..............................4
3.3. Usage Considerations .......................................5
4. Security Considerations .........................................6
5. IANA Considerations .............................................7
5.1. Registration of the Archive-At Header Field ................7
5.2. Registration of the X-Archived-At Header Field .............7
6. Acknowledgments .................................................8
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................8
1. 序論…2 2. ヘッダーフィールド定義…2 2.1. 構文…2 2.2. 複数、格納、-、ヘッダーフィールド…3 2.3. メッセージ断片化とReassemblyとの相互作用…3 2.4. 国際化しているメッセージヘッダーのための構文拡大…3 2.5. X、格納される、ヘッダーフィールド…4 3. 実装と用法問題…4 3.1. 格納されたメッセージの形式…4 3.2. 実装問題…4 3.3. 用法問題…5 4. セキュリティ問題…6 5. IANA問題…7 5.1. 登録、アーカイブ、-、ヘッダーフィールド…7 5.2. 登録、X、格納される、ヘッダーフィールド…7 6. 承認…8 7. 参照…8 7.1. 標準の参照…8 7.2. 有益な参照…8
Duerst Standards Track [Page 1] RFC 5064 The Archived-At Message Header Field December 2007
Duerst規格がRFC5064を追跡する、[1ページ]格納、-、メッセージヘッダーフィールド2007年12月
1. Introduction
1. 序論
[RFC2369] defines a number of header fields that can be added to Internet messages such as those sent by email distribution lists or in netnews [RFC1036]. One of them is the List-Archive header field that describes how to access archives for the list. This allows access to the archives as a whole, but not an individual message.
[RFC2369]はメール発送先リストの近く、または、ネットニュース[RFC1036]で送られたものなどのインターネットメッセージに追加できる多くのヘッダーフィールドを定義します。 それらの1つはリストのためのアーカイブにアクセスする方法を説明するList-アーカイブヘッダーフィールドです。 これは個々のメッセージではなく、全体でアーカイブへのアクセスを許します。
There is often a need or desire to refer to the archived form of a single message. For more detailed usage scenarios, please see Section 3.3. This memo defines a new header, Archived-At, to refer to a single message at an archived location. This provides quick access to the location of a mailing list message in the list archive. It can also be used independently of mailing lists, for example in connection with legal requirements to archive certain messages.
必要性かただ一つのメッセージの格納された書式を示す願望がしばしばあります。 より詳細な用法シナリオに関しては、セクション3.3を見てください。 このメモが新しいヘッダーを定義する、Archived、-、格納された位置にただ一つのメッセージを示すために。 これはリストアーカイブのメーリングリストメッセージの位置への迅速なアクセスを提供します。 また、メーリングリストの如何にかかわらず例えば、メッセージはある格納するという法的必要条件に関してそれを使用できます。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?
2. Header Field Definition
2. ヘッダーフィールド定義
2.1. Syntax
2.1. 構文
For the Archived-At header field, the field name is "Archived-At".
The field body consist of a URI [STD66] enclosed in angle brackets
('<', '>'). The URI MAY contain folding whitespace (FWS, [RFC2822]),
which is ignored. Mail Transfer Agents (MTAs) MUST NOT insert
whitespace within the angle brackets, but client applications SHOULD
ignore any whitespace, which might have been inserted by poorly
behaved MTAs. The URI points to an archived version of the message.
See Section 3.1 for more details.
Archived、-、ヘッダーフィールド、フィールド名がそうである、「格納、-、」 分野本体は角ブラケット('<'、'>')に同封されたURI[STD66]から成ります。 URIは折りたたみの空白(FWS、[RFC2822])を含むかもしれません。(それは、無視されます)。 メール配達エージェント(MTAs)は角ブラケットの中に空白を挿入してはいけませんが、クライアントアプリケーションSHOULDはどんな空白も無視します。(それは、不十分に振る舞っているMTAsによって挿入されました)。 URIはメッセージの格納されたバージョンを示します。 その他の詳細に関してセクション3.1を見てください。
This header field is subject to the encoding and character restrictions for mail headers as described in [RFC2822].
このヘッダーフィールドは[RFC2822]で説明されるようにメールヘッダのためのコード化とキャラクタ制限を受けることがあります。
More formally, the header field is defined as follows in Augmented BNF (ABNF) according to [RFC4234]:
Augmented BNF(ABNF)で、より正式に、[RFC4234]に従って、ヘッダーフィールドは以下の通り定義されます:
archived-at = "Archived-At:" [FWS] "<" folded-URI ">" CRLF
folded-URI = <URI, but free insertion of FWS permitted>
格納、-、等しさ、「格納、-、:、」 [FWS]"<"折り重ねられたURIの">"CRLFの折り重ねられたユリは<ユリと等しいのですが、>が受入れられたFWSの挿入を解放してください。
where URI is defined in [STD66], and CRLF and FWS are defined in [RFC2822].
URIがどこで[STD66]、およびCRLFで定義されるか、そして、FWSは[RFC2822]で定義されます。
To convert a folded-URI to a URI, first apply standard [RFC2822] unfolding rules (replacing FWS with a single SP), and then delete any remaining un-encoded SP characters.
折り重ねられたURIをURIに変換するために、最初に、規則を繰り広げながら(FWSを独身のSPに取り替えて)、規格[RFC2822]を適用してください、そして、次に、あらゆる残っている暗号化されていないSPキャラクタを削除してください。
Duerst Standards Track [Page 2] RFC 5064 The Archived-At Message Header Field December 2007
Duerst規格がRFC5064を追跡する、[2ページ]格納、-、メッセージヘッダーフィールド2007年12月
This syntax is kept simple in that only one URI per header field is allowed. In this respect, the syntax is different from [RFC2369]. Also, comments are not allowed.
1ヘッダーフィールドあたり1つのURIだけが許容されているので、この構文は簡単に保たれます。 この点で、構文は[RFC2369]と異なっています。 また、コメントは許容されていません。
2.2. Multiple Archived-At Header Fields
2.2. 複数、格納、-、ヘッダーフィールド
Each Archived-At header field only contains a single URI. If it is desired to list multiple URIs where an archived copy of the message can be found, a separate Archived-At field per URI is required. Multiple Archived-At header fields with the same URI SHOULD be avoided. An Archived-At header field SHOULD only be created if the message is actually being made available at the URI given in the header field.
それぞれ、Archived、-、ヘッダーフィールドはただ一つのURIを含むだけです。 メッセージの保存されたコピーを見つけることができるところに複数のURIを記載することを望まれているならa別々である、Archived、-、分野、URI単位で必要です。 複数、Archived、-、同じURI SHOULDが避けられているヘッダーフィールド。 ヘッダーはSHOULDをさばきます。Archived、-、実際にメッセージをヘッダーフィールドで与えられたURIで利用可能にしているなら、単に作成してください。
If a message is forwarded from a list to a sublist and both lists support adding the Archived-At header field, then the sublist SHOULD add a new Archived-At header field without removing the already existing one(s), unless the header field is exactly the same as an already existing one, in which case the new header field SHOULD NOT be added.
リストからサブリストまでメッセージを転送して、両方のリストが付加をサポートする、Archived、-、ヘッダーフィールド、次に、サブリストSHOULDが新しい状態でaを加える、Archived、-、ヘッダーフィールドがまさに既に既存のものと同じであり、どれが新しいヘッダー分野SHOULD NOTをケースに入れるかで加えられないなら既に既存のもの(s)を取り除くことのないヘッダーフィールド。
2.3. Interaction with Message Fragmentation and Reassembly
2.3. メッセージ断片化とReassemblyとの相互作用
[RFC2046] allows for the fragmentation and reassembly of messages. Archived-At header fields are to be treated in the same way as Comments header fields, i.e., copied to the first fragment message header on fragmentation and back from there to the header of the reassembled message.
[RFC2046]はメッセージの断片化と再アセンブリを考慮します。 格納、-、ヘッダーフィールドは同様に、すなわち、Commentsヘッダーフィールドとしてそこから断片化での最初の断片メッセージヘッダーと組み立て直されたメッセージのヘッダーまでコピーされていた状態で扱われることです。
This treatment has been chosen for compatibility with existing infrastructure. It means that Archived-At header fields in the first fragment message MAY refer to an archived version of the whole, unfragmented message. To avoid confusion, Archived-At headers SHOULD NOT be added to fragment messages.
この処理は既存のインフラストラクチャとの互換性に選ばれました。 それを意味する、Archived、-、最初の断片メッセージのヘッダーフィールドは全体の、そして、非断片化しているメッセージの格納されたバージョンを示すかもしれません。 混乱を避けるためにArchived、-、ヘッダーSHOULD NOT、加えられて、メッセージを断片化してください。
2.4. Syntax Extension for Internationalized Message Headers
2.4. 国際化しているメッセージヘッダーのための構文拡大
There are some efforts to allow non-ASCII text directly in message header field bodies. In such contexts, the URI non-terminal in the syntax defined in Section 2.1 is to be replaced by an Internationalized Resource Identifier (IRI) as defined in [RFC3987]. The specifics of the actual octet encoding of the IRI will follow the rules for general direct encoding of non-ASCII text. For conversion between IRIs and URIs, the procedures defined in [RFC3987] are to be applied.
直接メッセージヘッダーフィールド本体に非ASCIIテキストを許容するために、いくつかの取り組みがあります。 そのような文脈では、セクション2.1で定義された構文による非端末のURIは[RFC3987]で定義されるようにInternationalized Resource Identifier(IRI)に取り替えることです。 IRIの実際の八重奏コード化の詳細は非ASCIIテキストの一般的なダイレクトコード化のために約束を守るでしょう。 IRIsとURIの間の変換において、[RFC3987]で定義された手順は適用されていることです。
Duerst Standards Track [Page 3] RFC 5064 The Archived-At Message Header Field December 2007
Duerst規格がRFC5064を追跡する、[3ページ]格納、-、メッセージヘッダーフィールド2007年12月
2.5. The X-Archived-At Header Field
2.5. X、格納される、ヘッダーフィールド
For backwards compatibility, this document also describes the X-Archived-At header field, a precursor of the Archived-At header field. The X-Archived-At header field MAY also be parsed, but SHOULD not be generated.
遅れている互換性、このドキュメント、も説明、X、格納される、ヘッダーフィールド、先駆、Archived、-、ヘッダーフィールド X、格納される、また、しかし、ヘッダーフィールドが分析されるかもしれない、SHOULD、生成されないでください。
The following is the syntax of the X-Archived-At header field in ABNF according to [RFC4234] (which also defines SP):
↓これが構文である、X、格納される、[RFC4234](また、SPを定義する)に従ったABNFのヘッダーフィールド:
obs-archived-at = "X-Archived-At:" SP URI CRLF
obsに格納される、等しさ、「X、格納される、:、」 SP URI CRLF
The X-Archived-At header field does not allow whitespace inside URI.
X、格納される、ヘッダーフィールドは空白内部のURIを許容しません。
3. Implementation and Usage Considerations
3. 実装と用法問題
3.1. Formats of Archived Message
3.1. 格納されたメッセージの形式
There is no restriction on the format used to serve the archived message from the URI in an Archived-At header field. It is expected that in many cases, the archived message will be served as (X)HTML, as plain text, or in its original form as message/rfc822 [RFC2046]. Some forms of URIs may imply the format in which the archived message is served, although this should not be relied upon.
制限が全く中でURIからの格納されたメッセージに役立つのに使用される形式にない、Archived、-、ヘッダーフィールド 多くの場合、格納されたメッセージが(X) HTMLとして、または、プレーンテキストとして、または、元の形のままメッセージ/rfc822[RFC2046]として役立たれると予想されます。 いくつかのフォームのURIは格納されたメッセージに役立っている書式を含意するかもしれません、これを当てにするべきではありませんが。
If the protocol used to retrieve the message allows for content negotiation, then it is also possible to serve the archived message in several different formats. As an example, an HTTP URI in an Archived-At header may make it possible to serve the archived message both as text/html for human consumption in a browser and as message/rfc822 for use by a mail user agent (MUA) without loss of information.
また、メッセージを検索するのに使用されるプロトコルが満足している交渉を考慮するなら、いくつかの異なった形式に格納されたメッセージに役立つのも可能です。 例、中のHTTP URI、Archived、-、ヘッダー、ブラウザにおける人間の消費のためのテキスト/htmlとしてメールユーザエージェント(MUA)による使用のためにメッセージ/rfc822として情報の損失なしで格納されたメッセージに役立つのを可能にするかもしれません。
3.2. Implementation Considerations
3.2. 実装問題
Mailing list expanders and email archives are often separate pieces of software. It may therefore be difficult to create an Archived-At header field in the mailing list expander software.
メーリングリストエキスパンダとメールアーカイブはしばしば別々のソフトウェアです。 したがって、作成するのが難しいかもしれない、Archived、-、メーリングリストエキスパンダソフトウェアのヘッダーフィールド。
One way to address this difficulty is to have the mailing list expander software generate an unambiguous URI, e.g., a URI based on the message identifier of the incoming email, and to set up the archiving system so that it redirects requests for such URIs to the actual messages. If the email does not contain a message identifier, a unique identifier can be generated.
この困難を扱う1つの方法がメーリングリストエキスパンダソフトウェアに明白なURI、例えば入って来るメールに関するメッセージ識別子に基づくURIを生成させて、格納システムにセットすることであるので、それはそのようなURIを求める要求を実際のメッセージに向け直します。 メールがメッセージ識別子を含んでいないなら、ユニークな識別子を生成することができます。
Duerst Standards Track [Page 4] RFC 5064 The Archived-At Message Header Field December 2007
Duerst規格がRFC5064を追跡する、[4ページ]格納、-、メッセージヘッダーフィールド2007年12月
Such a system has been implemented and is in productive use at W3C. As an example, the URI "http://www.w3.org/mid/0I5U00G08DFGCR@mailsj-v1.corp.adobe.com", containing the significant part of the message identifier "<0I5U00G08DFGCR@mailsj-v1.corp.adobe.com>", is redirected to the URI of this message in the W3C mailing-list archive at http://lists.w3.org/Archives/Public/uri/2004Oct/0017.html.
そのようなシステムは、実装されて、W3Cに生産用途であります。 「例、メッセージ識別子 "<0I5U00G08DFGCR@mailsj-v1.corp.adobe.com のかなりの部分を含むURI" http://www.w3.org/mid/0I5U00G08DFGCR@mailsj-v1.corp.adobe.com "、gt;、」、 http://lists.w3.org/Archives/Public/uri/2004Oct/0017.html のW3CメーリングリストアーカイブのこのメッセージのURIに向け直されます。
Source code for this implementation is available at http://dev.w3.org/cvsweb/search/, in particular http://dev.w3.org/cvsweb/search/cgi/mid.pl and http://dev.w3.org/cvsweb/search/bin/msgid-db.pl. These locations may be subject to change.
この実装のためのソースコードは http://dev.w3.org/cvsweb/search/ 、特に http://dev.w3.org/cvsweb/search/cgi/mid.pl 、および http://dev.w3.org/cvsweb/search/bin/msgid-db.pl で利用可能です。 これらの位置は、変化するようになることがあるかもしれません。
When using the message identifier to create an address for the archived mail, care has to be taken to escape characters in the message identifier that are not allowed in the URI, or to remove them, as done above for the "<" and ">" delimiters.
格納されたメールのためのアドレスを作成するのにメッセージ識別子を使用するとき、注意は、メッセージ識別子のURIで許容されていない拡張文字に連れて行かれなければならないか、またはそれらを移さなければなりません、"<"と">"デリミタのために上でするように。
Implementations such as that described above can introduce a security issue. Somebody might deliberately reuse a message identifier to break the link to a message. This can be addressed by checking incoming message identifiers against those of the messages already in the archive and discarding incoming duplicates, by checking the content of incoming duplicates and discarding them if they are significantly different from the first message, by offering multiple choices in the response to the URI, or by using some authentication mechanism on incoming messages.
上で説明されたそれなどの実装は安全保障問題を紹介できます。 だれかが、メッセージにリンクを切り出すために故意にメッセージ識別子を再利用するかもしれません。 既にアーカイブのメッセージのものに対して入力メッセージ識別子をチェックして、入って来る写しを捨てるか、入って来る写しの中身をチェックして、それらが最初のメッセージとかなり異なるならそれらを捨てるか、URIへの応答で選択式を提供するか、または入力メッセージで何らかの認証機構を使用することによって、これを扱うことができます。
3.3. Usage Considerations
3.3. 用法問題
It may at first seem strange to have a pointer to an archived form of a message in a header field of that same message. After all, if one has the message, why would one need a pointer to it? It turns out that such pointers can be extremely useful. This section describes some of the scenarios for their use.
その同じメッセージのヘッダーフィールドにおける、メッセージの格納されたフォームに指針を持っているのは初めに、奇妙に思えるかもしれません。 結局、1つにメッセージがあるなら、人はなぜそれに指針を必要とするでしょうか? そのような指針が非常に役に立つ場合があると判明します。 このセクションは彼らの使用のためにシナリオのいくつかについて説明します。
A user may want to refer to messages in a non-message context, such as on a Web page, in an instant message, or in a phone conversation. In such a case, the user can extract the URI from the Archived-At header field, avoiding the search for the correct message in the archive.
ユーザは非メッセージの文脈のメッセージを示したがっているかもしれません、ウェブページなどのように、インスタントメッセージ、または電話での会話で。 このような場合には、ユーザがURIを抽出できる、Archived、-、ヘッダーフィールド、アーカイブの正しいメッセージの検索を避けます。
A user may want to refer to other messages in a message context. Referring to a single message is often done by replying to that message. However, when referring to more than one message, providing pointers to archived messages is a widespread practice. The Archived-At header field makes it easier to provide these pointers.
ユーザはメッセージの文脈の他のメッセージを示したがっているかもしれません。 ただ一つのメッセージは、そのメッセージに答えることによって、しばしば示されます。 しかしながら、1つ以上のメッセージを示すとき、格納されたメッセージに指針を提供するのは、広範囲の習慣です。 Archived、-、ヘッダーフィールドで、これらの指針を提供するのは、より簡単になります。
Duerst Standards Track [Page 5] RFC 5064 The Archived-At Message Header Field December 2007
Duerst規格がRFC5064を追跡する、[5ページ]格納、-、メッセージヘッダーフィールド2007年12月
A user may want to find messages related to a message at hand. The user may not have received the related messages, and therefore needs to use an archive. The user may also prefer finding related messages in the archive rather than in her MUA, because messages in archives may be linked in ways not provided by the MUA. The Archived-At header field provides a link to the starting point in the archive from which to find related messages.
ユーザは、メッセージに関連するメッセージに近いのがわかりたがっているかもしれません。 ユーザは、関連するメッセージを受け取っていないかもしれなくて、したがって、アーカイブを使用する必要があります。 また、ユーザは、彼女のMUAでというよりむしろアーカイブの関連するメッセージを見つけるのを好むかもしれません、アーカイブのメッセージがMUAによって提供されなかった方法でリンクされるかもしれないので。 Archived、-、ヘッダーフィールドは関連するメッセージを見つけるアーカイブにおける出発点へのリンクを提供します。
Please note that in the above usage scenarios, it is mostly the human reader, rather than the email client software, that makes use of the URI in the Archived-At header. However, this does not rule out the use of the URI in the Archived-At header by the email client or other software if such use is found helpful.
それがほとんどメールクライアントソフトウェアよりむしろ上の用法シナリオでは、人間の読者であるという中でURIを利用するメモを喜ばせる、Archived、-、ヘッダー しかしながら、これが中でURIの使用を除外しない、Archived、-、ヘッダー、そのような使用が役立っているのがわかるなら、クライアントか他のソフトウェアをメールしてください。
4. Security Considerations
4. セキュリティ問題
There are many potential security issues when activating and dereferencing a URI. For more details, including some countermeasures, please see [STD66]. In the context of this proposal, the following are particularly relevant: An intruder may get access to the message transmission and be able to insert a URI pointing to some malicious content. This can be addressed by using a secured way of message transmission. Also, somebody may be able to construct a message that is harmless when received directly, but that produces problems when accessed via the URI. One reason for this may be the format used in the archive, where some content was not adequately escaped. This can be addressed by using adequate escaping.
URIを動かして、「反-参照をつけ」るとき、多くの潜在的安全保障問題があります。 その他の詳細に関しては、いくつかの対策を含んでいて、見てください[STD66]。 この提案の文脈では、以下は特に関連しています: 侵入者は、メッセージ送信に近づく手段を得て、何らかの悪意がある内容を示しながら、URIを挿入できるかもしれません。 メッセージ送信の機密保護している方法を使用することによって、これを扱うことができます。 また、だれかが直接受け取ると無害ですが、URIでアクセスされると問題を生産するメッセージを構成できるかもしれません。 この1つの理由が何らかの内容適切に逃げられなかったアーカイブで使用される形式であるかもしれません。 適切なエスケープを使用することによって、これを扱うことができます。
The Archived-At header field points to some archived form of the message itself. This in turn may contain the Archived-At field. This creates a potential for a denial-of-service attack on the server pointed to by the URI in the Archived-At header field. The conditions are that the archived form of the message is downloaded automatically, and that further URIs in that message are followed and downloaded recursively without checking for already downloaded resources. However, this kind of scenario can easily be avoided by implementations. First, the URI in the Archived-At header field should not be dereferenced automatically. Second, appropriate measures for loop detection should be used.
Archived、-、ヘッダーフィールドはメッセージ自体の何らかの格納された書式を示します。 これが順番に含むかもしれない、Archived、-、分野。 これがURIによって中に示されたサーバにサービス不能攻撃の可能性を作成する、Archived、-、ヘッダーフィールド 状態は既にダウンロードされたリソースがないかどうかチェックしないでそのメッセージのさらなるURIに再帰的に自動的にメッセージの格納されたフォームをダウンロードして、続いて、ダウンロードするということです。 しかしながら、実装は容易にこの種類のシナリオを避けることができます。 最初に、中のURI、Archived、-、自動的にヘッダーフィールドに「反-参照をつけ」るべきではありません。 2番目に、輪の検出のための穏当な処置は使用されるべきです。
In Section 3.2, an attack is described that may break a URI to a message by introducing a new message with the same message identifier. Possible countermeasures are also discussed.
セクション3.2では、同じメッセージ識別子で新しいメッセージを紹介することによってメッセージにURIを切り出すかもしれない攻撃は説明されます。 また、可能な対策について議論します。
Duerst Standards Track [Page 6] RFC 5064 The Archived-At Message Header Field December 2007
Duerst規格がRFC5064を追跡する、[6ページ]格納、-、メッセージヘッダーフィールド2007年12月
5. IANA Considerations
5. IANA問題
5.1. Registration of the Archive-At Header Field
5.1. 登録、アーカイブ、-、ヘッダーフィールド
IANA has registered the Archived-At header field in the Message Header Fields Registry ([RFC3864]) as follows:
IANAが登録した、Archived、-、以下のMessage HeaderフィールズRegistry([RFC3864])のヘッダーフィールド:
Header field name:
Archived-At
ヘッダーフィールド名: 格納、-
Applicable protocol:
mail (RFC 2822) and netnews (RFC 1036)
適切なプロトコル: メール(RFC2822)とネットニュース(RFC1036)
Status:
standard
状態: 規格
Author/Change controller:
IETF
コントローラを書くか、または変えてください: IETF
Specification document(s):
RFC 5064
仕様ドキュメント: RFC5064
Related information:
none
関連情報: なし
5.2. Registration of the X-Archived-At Header Field
5.2. 登録、X、格納される、ヘッダーフィールド
This section is non-normative (specifically, an implementation that ignores this section remains compliant with this specification).
このセクションは非規範的です(明確に、このセクションを無視する実装はこの仕様で言いなりになったままで残っています)。
IANA has registered the X-Archived-At header field in the Message Header Fields Registry ([RFC3864]) as follows:
IANAが登録した、X、格納される、以下のMessage HeaderフィールズRegistry([RFC3864])のヘッダーフィールド:
Header field name:
X-Archived-At
ヘッダーフィールド名: X、格納されます。
Applicable protocol:
mail (RFC 2822) and netnews (RFC 1036)
適切なプロトコル: メール(RFC2822)とネットニュース(RFC1036)
Status:
deprecated
状態: 推奨しない
Author/Change controller:
IETF
コントローラを書くか、または変えてください: IETF
Specification document(s):
RFC 5064
仕様ドキュメント: RFC5064
Duerst Standards Track [Page 7] RFC 5064 The Archived-At Message Header Field December 2007
Duerst規格がRFC5064を追跡する、[7ページ]格納、-、メッセージヘッダーフィールド2007年12月
Related information:
none
関連情報: なし
6. Acknowledgments
6. 承認
The members of the W3C system team, in particular Gerald Oskoboiny, Olivier Thereaux, Jose Kahan, and Eric Prud'hommeaux, created the mid-based email archive lookup system and the experimental form of the Archived-At header. Pete Resnik provided the motivation for writing this memo. Discussion on the ietf-822@imc.org mailing list, in particular contributions by Frank Ellermann, Arnt Gulbrandsen, Graham Klyne, Bruce Lilly, Charles Lindsey, and Keith Moore, led to further improvements of the proposal. Chris Newman, Chris Lonvick, Stephane Borzmeyer, Vijay K. Gurbani, and S. Moonesamy provided additional valuable comments.
W3Cシステムチームのメンバー(特にジェラードOskoboiny、オリビエThereaux、ホセ・カアン、およびエリックPrud'hommeaux)が中間のベースのメールアーカイブルックアップシステムと実験用紙を作成した、Archived、-、ヘッダー ピートレズニックはこのメモを書くことに関する動機を提供しました。 フランクEllermannによる特定の貢献における ietf-822@imc.org メーリングリストについての議論(Arnt Gulbrandsen、グラハムKlyne、ブルース・リリー、チャールズ・リンジー、およびキース・ムーア)は、提案のさらなる改良につながりました。 クリス・ニューマン、クリスLonvick、ステファーヌBorzmeyer、ビジェイK.Gurbani、およびS.Moonesamyは追加貴重なコメントを提供しました。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[RFC3864]KlyneとG.とノッティンガム、M.とJ.ムガール人、「メッセージヘッダーフィールドのための登録手順」BCP90、2004年9月のRFC3864。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] DuerstとM.とM.Suignard、「国際化しているリソース識別子(虹彩)」、RFC3987、2005年1月。
[RFC4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005.
エド[RFC4234]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[STD66] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
7.2. Informative References
7.2. 有益な参照
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of
USENET messages", RFC 1036, December 1987.
[RFC1036] ホートンとM.とR.アダムス、「USENETメッセージの置き換えの規格」、RFC1036、1987年12月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
解放された[RFC2046]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
Duerst Standards Track [Page 8] RFC 5064 The Archived-At Message Header Field December 2007
Duerst規格がRFC5064を追跡する、[8ページ]格納、-、メッセージヘッダーフィールド2007年12月
[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
for Core Mail List Commands and their Transport through
Message Header Fields", RFC 2369, July 1998.
[RFC2369]ニューフェルドとG.とJ.ベヤー、「CoreメールList CommandsとMessage Headerフィールズを通した彼らのTransportのためのMeta-構文としてのURLのUse」、RFC2369、1998年7月。
Author's Address
作者のアドレス
Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever
possible, for example as "Dürst" in XML and HTML.)
Aoyama Gakuin University
5-10-1 Fuchinobe
Sagamihara, Kanagawa 229-8558
Japan
マーチンDuerst(注意: どこでも、例えば、「Dürst」としてXMLとHTMLで可能であるところにu-ウムラウト符号で"Duerst"を書いてください。) 相模原、青山学院大学5-10-1神奈川日本淵野辺229-8558
Phone: +81 42 759 6329 Fax: +81 42 759 6495 EMail: duerst@it.aoyama.ac.jp URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
以下に電話をしてください。 +81 42 759 6329Fax: +81 42 759 6495はメールされます: duerst@it.aoyama.ac.jp ユリ: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
Duerst Standards Track [Page 9] RFC 5064 The Archived-At Message Header Field December 2007
Duerst規格がRFC5064を追跡する、[9ページ]格納、-、メッセージヘッダーフィールド2007年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Duerst Standards Track [Page 10]
Duerst標準化過程[10ページ]
一覧
スポンサーリンク
