Network Working Group M. Duerst
Request for Comments: 5064 Aoyama Gakuin University
Category: Standards Track December 2007
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
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]定义了许多可以添加到Internet消息中的标题字段，例如通过电子邮件分发列表或netnews[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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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>
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]展开规则（用单个SP替换FWS），然后删除所有剩余的未编码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.
此语法保持简单，因为每个头字段只允许一个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单独设置一个存档At字段。应避免使用相同URI的多个存档At标头字段。只有当消息在标题字段中给定的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.
如果邮件从列表转发到子列表，并且两个列表都支持添加存档的At报头字段，则子列表应添加新的存档At报头字段，而不删除已存在的字段，除非报头字段与已存在的字段完全相同，在这种情况下，不应添加新的报头字段。
[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]允许消息的分段和重新组合。归档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.
选择这种处理方式是为了与现有基础设施兼容。这意味着，第一个片段消息中的存档At头字段可能指的是整个未分段消息的存档版本。为避免混淆，不应将存档的At标头添加到片段消息中。
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文本的一般直接编码规则。对于IRI和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-Archived-At报头字段，它是归档At报头字段的前身。X-archive-At头字段也可以被解析，但不应生成。
The following is the syntax of the X-Archived-At header field in ABNF according to [RFC4234] (which also defines SP):
以下是ABNF中X-Archived-At头字段的语法，根据[RFC4234]（它还定义了SP）：
obs-archived-at = "X-Archived-At:" SP URI CRLF
obs存档地址=“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.
在存档的At报头字段中，用于从URI提供存档消息的格式没有限制。预计在许多情况下，存档的消息将作为（X）HTML、纯文本或其原始形式作为message/rfc822[rfc246]使用。某些形式的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.
如果用于检索消息的协议允许内容协商，那么也可以以几种不同的格式为归档消息提供服务。例如，存档At报头中的HTTP URI可以使得在不丢失信息的情况下将存档消息作为文本/html供浏览器中的人使用，以及作为消息/rfc822供邮件用户代理（MUA）使用。
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.
邮件列表扩展器和电子邮件存档通常是独立的软件。因此，在邮件列表扩展器软件中创建存档的At标头字段可能很困难。
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.
解决此困难的一种方法是让邮件列表扩展器软件生成明确的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>”，被重定向到W3C邮件列表存档中此邮件的URI，地址为http://lists.w3.org/Archives/Public/uri/2004Oct/0017.html.
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的响应中提供多个选项来解决，或者对传入消息使用某种身份验证机制。
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.
用户可能希望在非消息上下文中引用消息，例如在网页、即时消息或电话对话中。在这种情况下，用户可以从存档的At头字段中提取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未提供的方式链接。Archived At header字段提供了一个链接，指向存档中查找相关邮件的起点。
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.
请注意，在上述使用场景中，主要是人工阅读器，而不是电子邮件客户端软件，使用了存档At头中的URI。但是，这并不排除电子邮件客户端或其他软件在存档At头中使用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.
Archived At header字段指向消息本身的某种存档形式。这又可能包含存档的At字段。这可能会在存档位置标头字段中的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]）中注册了存档的At头字段，如下所示：
Header field name: Archived-At
标题字段名称：存档于
Applicable protocol: mail (RFC 2822) and netnews (RFC 1036)
适用协议：邮件（RFC 2822）和网络新闻（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-archive-At头字段，如下所示：
Header field name: X-Archived-At
标题字段名称：X-Archived-At
Applicable protocol: mail (RFC 2822) and netnews (RFC 1036)
适用协议：邮件（RFC 2822）和网络新闻（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系统团队的成员，特别是Gerald Oskoboiny、Olivier Thereaux、Jose Kahan和Eric Prud'hommeaux，创建了基于mid的电子邮件归档查找系统和归档At头的实验形式。皮特·雷斯尼克为撰写这份备忘录提供了动机。关于ietf的讨论-822@imc.org邮件列表，特别是Frank Ellermann、Arnt Gulbrandsen、Graham Klyne、Bruce Lilly、Charles Lindsey和Keith Moore的贡献，进一步改进了提案。Chris Newman、Chris Lonvick、Stephane Borzmeyer、Vijay K.Gurbani和S.Moonesamy提供了其他有价值的评论。
[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，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[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]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年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写“Duerst”，例如用XML和HTML写“Dü；rst”）。青山学院大学5-10-1 Fuchinobe Sagamihara，神奈川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/
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）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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.