[要約] RFC 5064は、電子メールのヘッダーフィールドであるArchived-Atの定義と使用方法を提供しています。このヘッダーフィールドは、メールのアーカイブされたバージョンの場所を示すために使用されます。
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.
このメモは、個々の電子メールメッセージのアーカイブされた形式への直接リンクを提供するために、新しい電子メールヘッダーフィールド、Archived-ATを定義します。
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]は、電子メール配布リストまたはNetNewsで送信されたものなどのインターネットメッセージに追加できる多くのヘッダーフィールドを定義します[RFC1036]。そのうちの1つは、リストのアーカイブにアクセスする方法を説明するリストアーカイブヘッダーフィールドです。これにより、アーカイブ全体にアクセスできますが、個々のメッセージはアクセスできません。
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-ATを定義しています。これにより、リストアーカイブのメーリングリストメッセージの場所へのすばやいアクセスが提供されます。また、特定のメッセージをアーカイブするための法的要件に関連して、メーリングリストとは独立して使用することもできます。
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].
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"[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.
アーカイブされたヘッダーフィールドの場合、フィールド名は「アーカイブアット」です。フィールドボディは、角度ブラケット（ '<'、 '>'）に囲まれたURI [STD66]で構成されています。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>
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に変換するには、最初に標準[RFC2822]の展開ルール（FWSを単一のSPに置き換える）を適用し、残りの非エンコードされた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.
メッセージがリストからサブリストに転送され、両方のリストがアーカイブされたヘッダーフィールドの追加サポートをサポートする場合、サブリストは、ヘッダーフィールドが存在しない限り、既存のヘッダーを削除せずに新しいアーカイブされたヘッダーフィールドを追加する必要があります。既存のものとまったく同じです。その場合、新しいヘッダーフィールドを追加しないでください。
[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]は、メッセージの断片化と再組み立てを可能にします。Archived-atヘッダーフィールドは、コメントヘッダーフィールドと同じ方法で扱われます。つまり、断片化に関する最初のフラグメントメッセージヘッダーにコピーされ、そこから再構築されたメッセージのヘッダーまでコピーされます。
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テキストの一般的な直接エンコードのルールに従います。IRISと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-Archived-atヘッダーフィールドも解析される場合がありますが、生成されないでください。
The following is the syntax of the X-Archived-At header field in ABNF according to [RFC4234] (which also defines SP):
以下は、[RFC4234]（SPを定義する）によると、ABNFのX-Archived-ATヘッダーフィールドの構文です。
obs-archived-at = "X-Archived-At:" SP URI CRLF
Obs-Archived-at = "x-archived-at：" sp uri crlf
The X-Archived-At header field does not allow whitespace inside URI.
X-Archived-ATヘッダーフィールドでは、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からアーカイブされたメッセージを提供するために使用される形式に制限はありません。多くの場合、アーカイブされたメッセージは（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により、アーカイブされたメッセージをブラウザでの人間の消費のためのテキスト/HTMLとして、および郵便ユーザーエージェント（MUA）が損失なしで使用するメッセージ/RFC822の両方として提供することを可能にする可能性があります。情報の。
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"。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/で入手できます。.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に、または着信メッセージにいくつかの認証メカニズムを使用します。
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.
最初は、同じメッセージのヘッダーフィールドにアーカイブされた形式のメッセージへのポインターがあるのは奇妙に思えるかもしれません。結局のところ、メッセージがある場合、なぜそれに対するポインターが必要なのでしょうか？そのようなポインターは非常に便利であることがわかります。このセクションでは、それらの使用のシナリオのいくつかについて説明します。
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を介してアクセスすると問題が発生します。この理由の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.
アーカイブされたヘッダーフィールドは、メッセージ自体のアーカイブされた形式を指します。これには、アーカイブされたフィールドが含まれる場合があります。これにより、アーカイブされたヘッダーフィールドの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]）にArchived-atヘッダーフィールドを登録しています。
Header field name: Archived-At
ヘッダーフィールド名：Archived-at
Applicable protocol: mail (RFC 2822) and netnews (RFC 1036)
該当するプロトコル：Mail（RFC 2822）およびNetNews（RFC 1036）
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document(s): RFC 5064
仕様文書：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-Archived-ATヘッダーフィールドを登録しています。
Header field name: X-Archived-At
ヘッダーフィールド名：X-Archived-at
Applicable protocol: mail (RFC 2822) and netnews (RFC 1036)
該当するプロトコル：Mail（RFC 2822）およびNetNews（RFC 1036）
Status: deprecated
ステータス：非推奨
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document(s): RFC 5064
仕様文書：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システムチームのメンバー、特にジェラルド・オスコボイニー、オリビエ・セー、ホセ・カハン、およびエリック・プルド・ホンモーは、中間ベースの電子メールアーカイブルックアップシステムとアーカイブされたヘッダーの実験形式を作成しました。Pete Resnikは、このメモを書く動機を提供しました。IETF-822@imc.orgメーリングリスト、特にフランクエルマン、Arnt Gulbrandsen、Graham Klyne、Bruce Lilly、Charles Lindsey、Keith Mooreによる貢献に関する議論により、提案のさらなる改善が行われました。クリス・ニューマン、クリス・ロンヴィック、ステファン・ボルズマイヤー、ヴィジェイ・K・グルバニ、およびS.ムーネミーは、追加の貴重なコメントを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P.、ed。、「インターネットメッセージフォーマット」、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.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、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、「国際化されたリソース識別子（IRIS）」、RFC 3987、2005年1月。
[RFC4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.
[RFC1036] Horton、M。およびR. Adams、「Usenetメッセージの交換の標準」、RFC 1036、1987年12月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、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] Neufeld、G。およびJ. Baer、「コアメールリストのコマンドとメッセージヘッダーフィールドを介したトランスポートのメタシンタックスとしてのURLの使用」、RFC 2369、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
Martin Duerst（注：可能な限りU-Umlaut、たとえば「D＆＃252; rst」としてu-umlautで「Duerst」を書いてください。
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/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。