Network Working Group G. White
Request for Comments: 4865 Independent
Updates: 3463, 3464 G. Vaudreuil
Category: Standards Track Alcatel-Lucent
May 2007
Network Working Group G. White
Request for Comments: 4865 Independent
Updates: 3463, 3464 G. Vaudreuil
Category: Standards Track Alcatel-Lucent
May 2007
SMTP Submission Service Extension for Future Message Release
用于将来邮件发布的SMTP提交服务扩展
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time.
此备忘录为客户端定义了SMTP提交协议的扩展，以指示将来发布邮件以进行传递的时间。此扩展允许客户机使用基于服务器的存储来存储消息，该消息应保留在队列中，直到将来的指定时间。这对于没有本地存储或无法在指定时间释放邮件以进行传递的客户端非常有用。
There is a widely used feature within the voice messaging community to compose and send a message for delivery in the future. This is useful for sending announcements to be heard at the beginning of a work day, to send birthday greetings a day or so ahead, or to use as a lightweight facility to build a personal reminder service.
语音消息社区中有一个广泛使用的功能，用于编写和发送消息以供将来发送。这对于在工作日开始时发送公告、提前一天左右发送生日问候或作为轻量级工具构建个人提醒服务非常有用。
This extension uses the SMTP submission protocol [n3] to allow a client, when submitting a message, to indicate a future time for the message to be released for delivery.
此扩展使用SMTP提交协议[n3]来允许客户端在提交邮件时指示将来发布邮件以进行传递的时间。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [n1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[n1]中所述进行解释。
The Future Message Release service extension for SMTP submission uses the SMTP service extension mechanism [n4] to extend the SMTP submission protocol [n3]. The following SMTP submission service extension is hereby defined:
SMTP提交的未来邮件发布服务扩展使用SMTP服务扩展机制[n4]扩展SMTP提交协议[n3]。特此定义以下SMTP提交服务扩展：
The name of the SMTP submission service extension is "Future Message Release".
SMTP提交服务扩展名为“Future Message Release”。
1) The Extended Hello (EHLO) keyword associated with this service extension is "FUTURERELEASE".
1) 与此服务扩展关联的扩展Hello（EHLO）关键字是“FUTURERELEASE”。
2) Two required parameters, the max-future-release-interval and the max-future-release-date-time, are combined with the EHLO keyword in the manner specified in [n4].
2) 两个必需的参数，最大未来发布间隔和最大未来发布日期时间，以[n4]中指定的方式与EHLO关键字组合。
The max-future-release-interval is a positive integer indicating the maximum amount of time for which the message submission server (MSA) will hold messages for future release.
max future release interval是一个正整数，表示邮件提交服务器（MSA）保存邮件以供将来发布的最长时间。
Using ABNF [n2], the syntax of this parameter is as follows:
使用ABNF[n2]，此参数的语法如下：
future-release-integer = %x31-39 *8DIGIT
; integer in the range 1-999999999
; measured in seconds
future-release-integer = %x31-39 *8DIGIT
; integer in the range 1-999999999
; measured in seconds
max-future-release-interval = future-release-integer
max-future-release-interval = future-release-integer
The max-future-release-date-time is a timestamp, normalized to Universal Coordinated Time (UTC), indicating the most remote date and time in the future until which the MSA will hold messages for future release.
最大未来发布日期时间是一个时间戳，标准化为世界协调时间（UTC），指示未来最遥远的日期和时间，直到MSA保存消息以供未来发布。
Using ABNF [n2], the syntax of this parameter is as follows:
使用ABNF[n2]，此参数的语法如下：
max-future-release-date-time = date-time
max-future-release-date-time = date-time
where the format of date-time is defined in [n10].
其中日期时间格式在[n10]中定义。
3) When forming the portion of the EHLO reply containing the FUTURERELEASE keyword, the keyword is followed by the max-future-release-interval, and then the max-future-release-date-time. The keyword and two values are delimited by spaces.
3) 当形成包含FUTURERELEASE关键字的EHLO回复部分时，该关键字后面跟着最大未来发布间隔，然后是最大未来发布日期时间。关键字和两个值由空格分隔。
For example, the ABNF for a continuation line in the EHLO response that contains the FUTURERELEASE keyword is:
例如，对于RELEASE，RELEASE行中的ABNEHF CONTINUTION包含以下关键字：
line = "250-FUTURERELEASE" SP max-future-release-interval SP max-future-release-date-time
line=“250-FUTURERELEASE”SP最大未来发布间隔SP最大未来发布日期时间
4) One required parameter, the hold-param, is added to the MAIL command using either the keyword "HOLDFOR" or the keyword "HOLDUNTIL".
4) 使用关键字“HOLDFOR”或关键字“HOLDUNTIL”将一个必需的参数hold param添加到MAIL命令中。
The HOLDFOR parameter value is a future-release-interval, which is a positive integer indicating the amount of time the message is to be held by the MSA before release.
HOLDFOR参数值是一个未来发布间隔，它是一个正整数，指示MSA在发布前将保留消息的时间量。
The HOLDUNTIL parameter value is a future-release-date-time, which is a timestamp, normalized to UTC, indicating the future date and time until which the message is to be held by the MSA before release.
HOLDUNTIL参数值是未来发布日期时间，它是一个时间戳，标准化为UTC，指示MSA在发布前将消息保存到的未来日期和时间。
Using ABNF [n2], the syntax of this parameter is as follows:
使用ABNF[n2]，此参数的语法如下：
future-release-interval = future-release-integer
future-release-interval = future-release-integer
future-release-date-time = Internet-style-date-time-UTC
future-release-date-time = Internet-style-date-time-UTC
hold-for-param = "HOLDFOR=" future-release-interval
等待param=“HOLDFOR=”未来发布间隔
hold-until-param = "HOLDUNTIL=" future-release-date-time
保留到param=“holdintil=”未来发布日期时间
hold-param = hold-for-param / hold-until-param
hold-param = hold-for-param / hold-until-param
The absence of this parameter on the MAIL command does not imply a default value for this parameter.
MAIL命令中没有此参数并不意味着此参数的默认值。
5) The maximum length of a MAIL command is increased by 34 characters by the possible addition of the hold-param.
5) 通过可能添加hold参数，邮件命令的最大长度增加了34个字符。
6) No additional SMTP verbs are defined by this extension.
6) 此扩展未定义其他SMTP谓词。
7) This service extension is appropriate only for the SMTP submission protocol [n3]. This service extension is not appropriate for standard SMTP [n4].
7) 此服务扩展仅适用于SMTP提交协议[n3]。此服务扩展不适用于标准SMTP[n4]。
It is unfortunate to define two seemingly identical ways to indicate a future message release time. When the client has both accurate time and accurate time zone information, either interval or date-time can be trivially calculated from the other. However, in the current world of clients, there are clients with accurate local time but no indication of their time zone, and clients without a suitably accurate clock. Based on the limited facilities available to these time-challenged clients, it is likely that only one or the other of these mechanisms will be useful.
不幸的是，定义了两种似乎相同的方式来表示未来的消息发布时间。当客户机既有准确的时间信息又有准确的时区信息时，间隔时间或日期时间都可以从另一个简单地计算出来。然而，在当前的客户机世界中，有些客户机具有准确的本地时间，但没有显示其时区，有些客户机没有适当准确的时钟。基于这些时间紧迫的客户可用的设施有限，这些机制中可能只有一种或另一种是有用的。
It is believed that servers will have accurate time, and can trivially convert between these mechanisms. It is also accepted that the protocol and implementation overhead of offering these two mechanisms is low, and that few interoperability challenges are anticipated.
据信，服务器将具有准确的时间，并且可以在这些机制之间进行简单的转换。人们还认为，提供这两种机制的协议和实现开销很低，并且预期互操作性挑战很少。
1) An SMTP client preparing to use Future Message Release MUST first verify that the MSA supports this extension.
1) 准备使用未来邮件版本的SMTP客户端必须首先验证MSA是否支持此扩展。
2) An SMTP client using Future Message Release MUST include one, and only one, hold-param with the MAIL command.
2) 使用将来的邮件版本的SMTP客户端必须包含一个且仅包含一个带有MAIL命令的hold param。
3) An SMTP client using Future Message Release with the "for" option of the hold-param MUST ensure that the future-release-interval is less than or equal to the max-future-release-interval advertised by the MSA.
3) 使用带有hold参数“for”选项的未来邮件发布的SMTP客户端必须确保未来发布间隔小于或等于MSA公布的最大未来发布间隔。
4) An SMTP client using Future Message Release with the "until" option of the hold-param MUST ensure that the future-release-date-time is earlier than or equal to the max-future-release-date-time advertised by the MSA.
4) 使用带有hold参数“直到”选项的未来邮件发布的SMTP客户端必须确保未来发布日期时间早于或等于MSA公布的最大未来发布日期时间。
1) An MSA supporting Future Message Release MUST comply with the SMTP submission protocol as described in [n3].
1) 支持未来邮件发布的MSA必须符合[n3]中所述的SMTP提交协议。
2) An MSA supporting Future Message Release MUST NOT advertise this support (i.e. include the FUTURERELEASE keyword in its EHLO reply) on any port other than the submission port.
2) 支持未来消息发布的MSA不得在提交端口以外的任何端口上公布此支持（即在其EHLO回复中包含FUTURERELEASE关键字）。
3) An MSA supporting Future Message Release MUST include the FUTURERELEASE keyword, and associated max-future-release-interval and max-future-release-date-time parameters, in its reply to the EHLO command.
3) 支持未来消息发布的MSA必须在其对EHLO命令的回复中包含FUTURERELEASE关键字、相关的最大未来发布间隔和最大未来发布日期时间参数。
4) An MSA supporting Future Message Release MUST accept a MAIL command containing a valid hold-param, given that the MAIL command contains no other errors.
4) 支持未来邮件发布的MSA必须接受包含有效hold参数的邮件命令，前提是该邮件命令不包含其他错误。
5) An MSA that accepts a message with a request for Future Message Release indicating the "for" option MUST NOT release the message until the amount of time specified in the future-release-interval elapses.
5) 如果MSA接受带有“for”选项的未来消息发布请求的消息，则在未来发布间隔中指定的时间过后，MSA不得发布该消息。
6) An MSA that accepts a message with a request for Future Message Release indicating the "until" option MUST NOT release the message until the date and time indicated by the future-release-date-time occurs.
6) 接受带有“直到”选项的未来消息发布请求的消息的MSA不得在未来发布日期时间指示的日期和时间出现之前发布消息。
7) An MSA supporting Future Message Release MUST reject a MAIL command containing the "for" option specifying a value that is greater than the advertised max-future-release-interval, or otherwise invalid.
7) 支持未来邮件发布的MSA必须拒绝包含“for”选项的邮件命令，该选项指定的值大于公布的最大未来发布间隔，否则无效。
8) An MSA supporting Future Message Release MUST reject a MAIL command containing the "until" option specifying a value that is later than the advertised max-future-release-date-time, or otherwise invalid.
8) 支持未来邮件发布的MSA必须拒绝包含“直到”选项的邮件命令，该选项指定的值晚于公布的最大未来发布日期时间，否则无效。
9) An MSA supporting Future Message Release MUST reject a MAIL command containing more than one hold-param.
9) 支持未来邮件发布的MSA必须拒绝包含多个hold参数的邮件命令。
10) An MSA supporting Future Message Release, when rejecting a MAIL command per items 7, 8, or 9, above, SHOULD supply the reply code 501 (syntax error in parameters or arguments [n4]) in the reply.
10） 支持未来消息发布的MSA在根据上述第7、8或9项拒绝邮件命令时，应在回复中提供回复代码501（参数或参数[n4]中的语法错误）。
11) An MSA supporting Future Message Release, when rejecting a MAIL command per items 7, 8, or 9, above, SHOULD supply the Enhanced Mail System Status Code 5.5.4 (invalid command arguments [i1]) in the reply.
11） 当根据上述第7、8或9项拒绝邮件命令时，支持未来邮件发布的MSA应在回复中提供增强邮件系统状态代码5.5.4（无效命令参数[i1]）。
The Delivery Status Notification (DSN) service extension is described in [n7], and DSN message format is described in [n8].
[n7]中描述了交付状态通知（DSN）服务扩展，而[n8]中描述了DSN消息格式。
1) An SMTP client MUST NOT request Future Message Release when sending a DSN to the MSA.
1) 向MSA发送DSN时，SMTP客户端不得请求将来的邮件释放。
1) If an MSA generates a DSN for a message that includes a Future Message Release request, the MSA MUST include an Arrival-Date field in the machine-readable body part of the DSN.
1) 如果MSA为包含未来消息发布请求的消息生成DSN，则MSA必须在DSN的机器可读正文部分中包含到达日期字段。
2) If an MSA generates a DSN for a message that includes a Future Message Release request, the MSA MUST include a Future-Release-Request field in the machine-readable body part of the DSN. The value of this field is the value of the HOLD parameter contained in the MAIL command of the original message.
2) 如果MSA为包含未来消息发布请求的消息生成DSN，则MSA必须在DSN的机器可读主体部分中包含未来发布请求字段。此字段的值是原始邮件的MAIL命令中包含的HOLD参数的值。
The Future-Release-Request field is an extension to the set of DSN per-message fields described in [n8]. Using ABNF [n2], the syntax of this new field is as follows:
“未来发布请求”字段是[n8]中描述的DSN每条消息字段集的扩展。使用ABNF[n2]，此新字段的语法如下：
orig-hold-param-value = ("for;" future-release-interval) /
("until;" future-release-date-time)
; this is the value of the HOLD param from
; the MAIL command of the original message
orig-hold-param-value = ("for;" future-release-interval) /
("until;" future-release-date-time)
; this is the value of the HOLD param from
; the MAIL command of the original message
future-release-request-field = "Future-Release-Request:" orig-hold-param-value
未来发布请求字段=“未来发布请求：”原始保留参数值
If an MSA supports the Future Message release and Deliver By service extensions, it is possible for an SMTP client to make simultaneous requests for future message release and deliver-by times when submitting a message. A problem will occur if the future message release time is farther in the future than the deliver-by time. In order to honor the deliver-by request, the future message release request has to be ignored. In order to honor the future message release request, the deliver-by request has to be ignored. This section addresses that problem. The Deliver By extension is described in [n6].
如果MSA支持将来的邮件发布和按服务扩展交付，则SMTP客户端可以在提交邮件时同时请求将来的邮件发布和按时间交付。如果将来的消息发布时间比“按时间交付”的时间更长，则会出现问题。为了遵守deliveby请求，必须忽略将来的消息发布请求。为了满足未来的消息发布请求，必须忽略delivebyrequest。本节讨论这个问题。[n6]中描述了扩展交付。
1) When an SMTP client wishes to use the Future Message Release and Deliver By extensions with the same message, the client MUST ensure that the specified deliver-by time is farther in the future than the specified ("until" option) or implied ("for" option) future message release time.
1) 当SMTP客户端希望对同一邮件使用将来的邮件发布和通过扩展传递时，客户端必须确保指定的按时间传递比指定的（“直到”选项）或暗示的（“for”选项）将来的邮件发布时间更长。
1) If an MSA supports Future Message Release and Deliver By extensions, and receives a message requesting the use of both extensions, the MSA MUST reject the MAIL command if it determines that the future message release time is farther in the future than the deliver-by time.
1) 如果MSA支持将来的消息发布和按扩展传递，并且收到请求使用这两个扩展的消息，则如果MSA确定将来的消息发布时间比按扩展传递时间长，则必须拒绝邮件命令。
2) When an MSA is rejecting a MAIL command per item 1, above, it SHOULD supply the reply code 501 (syntax error in parameters or arguments [n4]) in the reply.
2) 当MSA根据上述第1项拒绝邮件命令时，应在回复中提供回复代码501（参数或参数[n4]中的语法错误）。
3) When an MSA is rejecting a MAIL command per item 1, above, it SHOULD supply the Enhanced Mail System Status Code 5.5.4 (invalid command arguments [i1]) in the reply.
3) 当MSA根据上述第1项拒绝邮件命令时，应在回复中提供增强邮件系统状态代码5.5.4（无效命令参数[i1]）。
The Message Disposition Notification (MDN) function is described in [n9].
[n9]中描述了消息处置通知（MDN）功能。
1) An SMTP client MUST NOT request Future Message Release when sending an MDN to the MSA.
1) 向MSA发送MDN时，SMTP客户端不得请求将来的邮件释放。
The Future Message Release service extension presents a number of security considerations:
Future Message Release service extension提供了许多安全注意事项：
1) Unauthorized future-release messages provide a means to overwhelm the storage of an MSA. The authorization mechanisms required for the base mail submission protocol [n3] are expected to provide appropriate defense against such attacks.
1) 未经授权的未来发布消息提供了一种覆盖MSA存储的方法。基本邮件提交协议[n3]所需的授权机制有望为此类攻击提供适当的防御。
2) Authorized future message release without a per-user quota may also provide a way to overwhelm an MSA's storage. An MSA's future release message storage SHOULD be subject to a per-user quota.
2) 没有每个用户配额的授权的未来消息发布也可以提供一种方法来覆盖MSA的存储。MSA的未来发布消息存储应遵守每个用户的配额。
3) If an MSA is imposing a per-user quota on future-release message storage, and detects that an incoming future-release message will exceed the user's future-release message storage quota, the MSA MUST reject the MAIL command.
3) 如果MSA对未来发布邮件存储施加每个用户配额，并检测到传入的未来发布邮件将超过用户的未来发布邮件存储配额，则MSA必须拒绝邮件命令。
4) When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply the reply code 552 (requested mail action aborted: exceeded storage allocation [n4]) in the reply.
4) MSA根据5.3拒绝邮件命令时，应在回复中提供回复代码552（请求的邮件操作中止：超出存储分配[n4]）。
5) When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply the new Enhanced Mail System Status Code defined for this purpose. This new status code updates [i1].
5) 当MSA根据5.3拒绝邮件命令时，应提供为此目的定义的新增强邮件系统状态代码。此新状态代码更新[i1]。
X.7.16 Future release per-user message quota exceeded
X.7.16 超出了每个用户邮件的未来版本配额
There is insufficient per-user quota to queue the message for future release. This code suggests the client can submit again only after the per-user queue has drained.
每个用户配额不足，无法将邮件排队等待将来发布。这段代码表明客户端只能在每个用户队列耗尽后再次提交。
X.7.17 Future release system message quota exceeded
X.7.17 已超出未来发布系统邮件配额
There is insufficient system quota to queue the message for future release. This code suggests the client can submit again after the system queue has drained.
系统配额不足，无法将消息排队等待将来发布。此代码表示客户端可以在系统队列耗尽后再次提交。
6) Inaccurate time on the MSA may result in premature or delayed release of messages. Both HOLDUNTIL and HOLDFOR request mechanisms are sensitive to inaccurate or changing clocks on the MSA.
6) MSA上的时间不准确可能导致过早或延迟发布消息。HoldTill和HOLDFOR请求机制对MSA上不准确或不断变化的时钟都很敏感。
7) Some element of deception is inherent in the future message release concept. The message release time is intentionally delayed past the time it would otherwise be released; hence, the message delivery time is delayed past the time it would otherwise be delivered. This extension provides no mechanism for hiding this from the message recipient. The RFC 2822 [n5] message header, and specifically the Date field, remain unchanged after submission. While a sending client MAY elect to place the future-message-release-time as the date in the Date field, there is no requirement or expectation that the Received fields and other trace information be modified by the transport system to further this deception.
7) 在未来的消息发布概念中，某些欺骗因素是固有的。消息发布时间被故意延迟，超过了其本应发布的时间；因此，消息传递时间被延迟，超过了以其他方式传递消息的时间。此扩展没有向邮件收件人隐藏此信息的机制。RFC 2822[n5]消息头，特别是日期字段在提交后保持不变。虽然发送客户端可以选择将未来消息发布时间作为日期字段中的日期，但不要求或期望传输系统修改接收的字段和其他跟踪信息以进一步欺骗。
This extension has been added to the list of SMTP Service Extensions on the Mail Parameters Web page.
此扩展名已添加到“邮件参数”网页上的SMTP服务扩展名列表中。
Much of the credit for this document is due to the LEMONADE working group. Through many revisions, the discussion resulted in fundamental new understandings of this protocol and corresponding refinement of the implied requirements and protocol. Special thanks to those who patiently lead the WG to understand that doing both interval and date-time was the pragmatically correct approach to the needs of diverse clients.
这份文件的大部分功劳都归功于柠檬水工作组。通过多次修订，讨论对本协议产生了根本性的新理解，并相应地完善了隐含的要求和协议。特别感谢那些耐心地领导工作组的人，让他们明白，间隔时间和日期时间都是满足不同客户需求的实用正确方法。
[n1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[n1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[n2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[n2] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[n3] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[n3] Gellens，R.和J.Klensin，“邮件邮件提交”，RFC 4409，2006年4月。
[n4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[n4] 《简单邮件传输协议》，RFC 28212001年4月。
[n5] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[n5] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[n6] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[n6] Newman，D.，“通过SMTP服务扩展交付”，RFC 2852，2000年6月。
[n7] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[n7] Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[n8] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[n8] Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[n9] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[n9] Hansen，T.和G.Vaudreuil，“消息处置通知”，RFC 3798，2004年5月。
[n10] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002
[n10]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，2002年7月
[i1] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[i1] Vaudreuil，G.，“增强型邮件系统状态代码”，RFC 3463，2003年1月。
Authors' Addresses
作者地址
Gregory A. White 6519 Camille Ave. Dallas, TX 75252 USA EMail: g.a.white@tx.rr.com
Gregory A.White德克萨斯州达拉斯卡米尔大道6519号，邮编75252美国电子邮件：g.A。white@tx.rr.com
Gregory M. Vaudreuil Alcatel-Lucent 9489 Bartgis Ct Frederick, MD 21702 USA EMail: GregV@ieee.org
Gregory M.Vaudreuil Alcatel-Lucent 9489 Bartgis Ct Frederick，马里兰州21702美国电子邮件：GregV@ieee.org
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。