Network Working Group M. Duerst
Request for Comments: 5064 Aoyama Gakuin University
Category: Standards Track December 2007
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
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.
このメモは、個々の電子メールメッセージのアーカイブ形式への直接リンクを提供するために、新しい電子メールヘッダフィールド、アーカイブアットを:,定義します。
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
[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]で送信されるようなインターネットメッセージに追加することができるヘッダフィールドの数を定義します。そのうちの一つは、リストのアーカイブにアクセスする方法について説明リスト・アーカイブ・ヘッダフィールドです。これは、個々のメッセージを全体としてアーカイブへのアクセスを許可しますが、ありません。
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節を参照してください。このメモは、アーカイブの場所で単一のメッセージを参照するために新しいヘッダ、アーカイブアットを、定義します。これは、リストのアーカイブ内のメーリングリストメッセージの場所への迅速なアクセスを提供します。また、特定のメッセージをアーカイブする法的要件に関連して、たとえば、メーリングリストとは独立して使用することができます。
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"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" [RFC2119]に記載されているように解釈されるべきです。
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.
アーカイブアットヘッダフィールドは、フィールド名が「-にアーカイブされます」。フィールド体（「<」、「>」）[STD66]角括弧で囲まれたURIから成ります。 URIは無視される折り畳み空白を（FWS、[RFC2822]）含有してもよいです。メール転送エージェント（MTA）は、角括弧内の空白を挿入してはなりませんが、クライアント・アプリケーションは悪い行儀のMTAによって挿入された可能性がある空白を無視すべきです。 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]:
[RFC4234]に従って増大しているBNF（ABNF）で次のように、より正式には、ヘッダフィールドが定義されます。
archived-at = "Archived-At:" [FWS] "<" folded-URI ">" CRLF folded-URI = <URI, but free insertion of FWS permitted>
アーカイブアット= "アットアーカイブ：" CRLFが折り畳ま-URI = [FWS] "<" 折り畳ま-URI ">" <URIが、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を変換するために、最初の（単一のSPとFWSを交換）標準[RFC2822]展開規則を適用し、残りの未符号化されたSPの文字を削除します。
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つだけのURIが許可されているという点で、この構文は、単純な保持されます。この点で、構文は[RFC2369]と異なっています。また、コメントは許可されていません。
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.
各アーカイブアットヘッダフィールドは、単一のURIを含みます。それは、メッセージのアーカイブコピーを見つけることができる複数のURIを一覧表示することが望まれる場合は、URIごとに別々のアーカイブアットフィールドが必要です。同じURIを持つ複数のアーカイブアットヘッダフィールドは避けるべきです。メッセージが実際にヘッダフィールドで指定された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.
メッセージがリストからアーカイブアットヘッダフィールドを追加サブリストおよび両方のリストのサポートに転送された場合、ヘッダフィールドである場合を除き、その後、サブリストは、すでに既存の（S）を除去せずに新しいアーカイブアットヘッダフィールドを追加すべきです新たなヘッダフィールドを追加すべきでない場合には、すでに既存のもの、と全く同じ。
[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]はメッセージのフラグメンテーション及び再組み立てを可能にします。アーカイブアットヘッダフィールド、すなわち、断片の最初のフラグメントメッセージヘッダにコピーされ、戻ってそこから再組立てメッセージのヘッダに、コメントヘッダフィールドと同じように扱われるべきです。
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.
この処理は、既存のインフラストラクチャとの互換性のために選ばれました。これは、最初のフラグメントメッセージでアーカイブアットヘッダフィールド全体、断片化されていないメッセージのアーカイブされたバージョンを参照することができることを意味します。混乱を避けるために、アーカイブアットヘッダは、フラグメントメッセージに追加しないでください。
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]で定義されるように国際化リソース識別子（IRI）によって置換されます。 IRIの実際のオクテットの符号化の詳細は、非ASCIIテキストの一般的なダイレクトエンコーディングのための規則に従います。虹彩とURIの間の変換のために、[RFC3987]で定義された手順が適用されます。
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-アーカイブアットヘッダフィールド、アーカイブアットヘッダフィールドの前駆体が記載されています。 X-アーカイブアットヘッダフィールドも解析されてもよいが、生成されるべきではありません。
The following is the syntax of the X-Archived-At header field in ABNF according to [RFC4234] (which also defines SP):
以下は、（また、SPを定義）[RFC4234]に従ってABNFにおけるX-アーカイブアットヘッダフィールドの構文です。
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内の空白を許可しません。
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からアーカイブメッセージを提供するために使用される形式に制限はありません。多くの場合、アーカイブされたメッセージは、プレーンテキストとして、またはメッセージ/ RFC822 [RFC2046]のように元の形で、（X）HTMLとして提供されることが期待されます。これが依拠すべきではありませんが、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を損失することなくブラウザとメールユーザエージェント（MUA）で使用するためのメッセージ/ RFC822のように人間の消費のための両方のtext / htmlとしてアーカイブされたメッセージを配信することを可能にしてもよいです情報の。
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.
メーリングリストパンダと電子メールのアーカイブは、多くの場合、ソフトウェアの独立した作品です。したがって、メーリングリストエキスパンダーソフトウェアでアーカイブアットヘッダフィールドを作成することは困難です。
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の要求をリダイレクトするようにアーカイブシステムを設定する必要があります実際のメッセージ。電子メールは、メッセージ識別子が含まれていない場合は、一意の識別子を生成することができます。
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で生産使用されているれています。一例として、URIは「http://www.w3.org/mid/0I5U00G08DFGCR@mailsj-v1.corp.adobe.com」、メッセージ識別子「<0I5U00G08DFGCR@mailsj-v1.corpのかなりの部分を含みます。 adobe.com>」、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/cgi/mid.plとHTTPで、http://dev.w3.org/cvsweb/search/で提供されています：// DEV .w3.orgが/ cvsweb /検索/ 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への、または着信メッセージのいくつかの認証メカニズムを使用します。
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.
ユーザーは、インスタントメッセージ、または電話での会話では、このようなWebページ上などの非メッセージコンテキスト内のメッセージを参照することもできます。このような場合に、ユーザは、アーカイブ内の正しいメッセージの検索を回避する、アーカイブアットヘッダフィールドからURIを抽出することができます。
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.
ユーザーは、メッセージコンテキストに他のメッセージを参照することもできます。単一のメッセージを参照するには、多くの場合、そのメッセージに返信することによって行われます。しかし、複数のメッセージを参照するとき、アーカイブされたメッセージへのポインタを提供する広範的な方法です。アーカイブアットヘッダフィールドは、それが簡単にこれらのポインタを提供することができます。
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に関連するメッセージを見つける好むかもしれません。アーカイブアットヘッダフィールドに関連するメッセージを検索するためのアーカイブの開始点へのリンクを提供します。
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を使用する電子メールクライアントソフトウェア、より、主に人間の読者であることに注意してください。そのような使用が役に立ったと評価されている場合ただし、これは電子メールクライアントまたは他のソフトウェアでアーカイブアットヘッダー内のURIの使用を排除するものではありません。
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を介してアクセスされる場合には、問題を生じさせます。この理由の一つは、一部のコンテンツが適切にエスケープされていなかったアーカイブに使用される形式であってもよいです。これは、適切なエスケープを使用することによって対処することができます。
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.
メッセージ自体のいくつかのアーカイブ形式にアーカイブアットヘッダフィールドポイント。これは、順番にアーカイブアットフィールドが含まれていてもよいです。これは、サーバー上のサービス拒否攻撃の可能性がアーカイブアットヘッダフィールドにURIによって指さ作成します。条件は、メッセージのアーカイブされたフォームが自動的にダウンロードし、そのメッセージの更なるURIはすでにダウンロードしたリソースをチェックせずに続くと再帰的にダウンロードされていることをされていることです。しかし、このようなシナリオを簡単に実装することで回避することができます。まず、アーカイブアットヘッダフィールド内のURIが自動的に逆参照されるべきではありません。第二に、ループ検出のための適切な措置を使用する必要があります。
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を壊すことができることが記載されています。可能な対応策についても説明します。
IANA has registered the Archived-At header field in the Message Header Fields Registry ([RFC3864]) as follows:
次のようにIANAは、メッセージヘッダフィールドレジストリ（[RFC3864]）でアーカイブアットヘッダフィールドを登録しました。
Header field name: Archived-At
ヘッダフィールド名：アーカイブアット
Applicable protocol: mail (RFC 2822) and netnews (RFC 1036)
該当するプロトコル：メール（2822 RFC）とネットニュース（RFC 1036）
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document(s): RFC 5064
仕様書（S）：RFC 5064
Related information: none
関連情報：なし
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は、メッセージヘッダフィールドレジストリ（[RFC3864]）でX-アーカイブアットヘッダフィールドを登録しました。
Header field name: X-Archived-At
ヘッダフィールド名：X-アーカイブアット
Applicable protocol: mail (RFC 2822) and netnews (RFC 1036)
該当するプロトコル：メール（2822 RFC）とネットニュース（RFC 1036）
Status: deprecated
ステータス：非推奨
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document(s): RFC 5064
仕様書（S）：RFC 5064
Related information: none
関連情報：なし
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、ホセカハン、そしてエリック・プラオモーで、ミッドベースの電子メールアーカイブの検索システムおよびアーカイブアットヘッダーの実験的なフォームを作成しました。ピートRESNIKは、このメモを書くための動機を提供します。 ietf-822@imc.orgメーリングリスト上の議論は、フランクEllermann、ARNT Gulbrandsenの、グラハムKlyne、ブルース・リリー、チャールズリンジー、そしてキース・ムーアによって特定の貢献で、提案のさらなる改善につながりました。クリス・ニューマン、クリスLonvick、ステファンBorzmeyer、ビジェイK. Gurbani、およびS. Moonesamyは、追加の貴重なコメントを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[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.モーグル、BCP 90、RFC 3864、2004年9月 "メッセージヘッダフィールドの登録手順"。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[RFC4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
"構文仕様のための増大しているBNF：ABNF" [RFC4234]クロッカー、D.、エド、およびP. Overell、。、RFC 4234、2005年10月。
[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、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.
、RFC 1036、1987年12月 "USENETメッセージの交換のための標準的な" [RFC1036]ホートン、M.およびR.アダムス。
[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：メディアタイプ"、RFC 2046、1996年11月。
[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.ベア、RFC 2369、1998年7月「コアメールリストコマンドとメッセージヘッダフィールドを通じてそれらの輸送のためのメタ構文としてのURLの使用」。
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（注：。、可能な限りのuウムラウトで「Duerstを」書く「D＆＃252; RST」として例えば下さいXMLとHTMLで）青山学院大学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 6329ファックス：+81 42 759 6495 Eメール：URI duerst@it.aoyama.ac.jp：http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。