Network Working Group E. Lear
Request for Comments: 4833 Cisco Systems GmbH
Updates: 2132 P. Eggert
Category: Standards Track UCLA
April 2007
Network Working Group E. Lear
Request for Comments: 4833 Cisco Systems GmbH
Updates: 2132 P. Eggert
Category: Standards Track UCLA
April 2007
Timezone Options for DHCP
DHCP的时区选项
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
摘要
Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names. This memo specifies DHCP options for each of those methods. The DHCPv4 time offset option is deprecated.
传送时区信息的两种常见方式是POSIX 1003.1时区字符串和时区数据库名称。此备忘录为每个方法指定DHCP选项。不推荐使用DHCPv4时间偏移选项。
This memo specifies a means to provide hosts with more accurate timezone information than was previously available. To do this we make use of two commonly used methods to configure timezones:
此备忘录指定了一种向主机提供比以前更准确时区信息的方法。为此，我们使用两种常用方法来配置时区：
o POSIX TZ strings
o POSIX TZ字符串
o Reference to the name of the time zone entry in the TZ Database
o 对TZ数据库中时区条目名称的引用
POSIX [1] provides a standard for how to express timezone information in a character string. Use of such a string can provide accuracy for at least one transition into and out of daylight saving time (DST), and possibly for more transitions if the transitions are regular enough (e.g., "second Sunday in March at 02:00 local time"). However, for accuracy over longer periods that involve daylight-saving rule changes or other irregular changes, a more detailed mechanism is necessary.
POSIX[1]为如何在字符串中表示时区信息提供了标准。使用这样的字符串可以为至少一次进入和退出夏令时（DST）的转换提供准确度，如果转换足够规则（例如，“3月的第二个星期日，当地时间02:00”），还可能为更多转换提供准确度。但是，对于涉及夏时制规则更改或其他不规则更改的较长时间内的准确性，需要更详细的机制。
The TZ Database [7] that is used in many operating systems provides backwards consistency and accuracy for almost all real-world locations since 1970. The TZ database also attempts to provide a stable set of human readable timezone identifiers. In addition, many systems already make use of the TZ database, and so the names used are a de facto standard. Because the TZ database contains more information, one can heuristically derive the POSIX information from a TZ identifier (see [10] for an example), but the converse is not true.
自1970年以来，在许多操作系统中使用的TZ数据库[7]为几乎所有实际位置提供了向后一致性和准确性。TZ数据库还试图提供一组稳定的人类可读时区标识符。此外，许多系统已经使用TZ数据库，因此使用的名称是事实上的标准。由于TZ数据库包含更多信息，因此可以从TZ标识符中试探性地导出POSIX信息（例如，请参见[10]），但反之则不然。
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 RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
Dynamic Host Configuration Protocol (DHCP) [3] provides a means for hosts to receive configuration information relating to their current location within an IP version 4 network. [5] similarly does so for IP version 6 networks. RFC 2132 [4] specifies an option to provide client timezone information in the form of an offset in seconds from UTC. The information provided in that option is insufficient for the client to determine whether it is in daylight saving time, and when to change into and out of daylight saving time. In order for the client to properly represent local wall clock time in a consistent and accurate fashion the DHCP server would have to time lease expirations of affected clients to the beginning or end of DST, thus effecting a self stress test (to say the least) at the appointed hour.
动态主机配置协议（DHCP）[3]为主机提供了一种方法，用于接收与其在IP版本4网络中的当前位置相关的配置信息。[5] IP版本6网络也是如此。RFC 2132[4]指定了一个选项，以UTC的秒偏移量的形式提供客户端时区信息。该选项中提供的信息不足以让客户确定它是否处于夏令时，以及何时更改为夏令时和何时更改为夏令时。为了让客户端以一致和准确的方式正确地表示本地挂钟时间，DHCP服务器必须将受影响客户端的租约到期时间定为DST的开始或结束，从而在指定的时间进行自我压力测试（至少可以说）。
In addition, an offset is not sufficient to determine the actual timezone in which a client resides, and thus there is no means to derive a human readable abbreviation such as "EST" or "EDT".
此外，偏移量不足以确定客户机所在的实际时区，因此无法派生人类可读的缩写词，如“EST”或“EDT”。
VTIMEZONE elements are defined in the iCalendar specification [9]. Fully specified they provide a level of accuracy similar to the TZ database. However, because there is currently no global registry of VTIMEZONE TZIDs (although one has been proposed; see [8]), complete accuracy requires that a full entry must be specified. To achieve the same information would range from 300 octets upwards with no particular bound. Furthermore, at the time of this writing the authors are aware of no operating system that natively takes advantage of VTIMEZONE entries. It might be possible to include an option for a TZURL. However, in a cold start environment, it will be bad enough that devices are stressing the DHCP server, and perhaps unwise to similarly afflict other components.
VTIMEZONE元素在iCalendar规范[9]中定义。完全指定它们提供了与TZ数据库类似的精度级别。但是，由于目前没有VTIMEZONE TZID的全局注册表（尽管已经提出了一个注册表；请参见[8]），因此完全准确要求必须指定完整的条目。要获得相同的信息，其范围从300个八位元以上，没有特定的界限。此外，在撰写本文时，作者意识到没有任何操作系统本机利用VTIMEZONE条目。可能包括TZURL的选项。但是，在冷启动环境中，设备对DHCP服务器施加压力已经够糟糕的了，并且可能不明智地对其他组件施加类似的影响。
The following two options are defined for DHCPv4:
为DHCPv4定义了以下两个选项：
PCode Len TZ-POSIX String
+-----+-----+------------------------------+
| 100 | N | IEEE 1003.1 String |
+-----+-----+------------------------------+
PCode Len TZ-POSIX String
+-----+-----+------------------------------+
| 100 | N | IEEE 1003.1 String |
+-----+-----+------------------------------+
TCode Len TZ-Database String
+-----+-----+------------------------------+
| 101 | N | Reference to the TZ Database |
+-----+-----+------------------------------+
TCode Len TZ-Database String
+-----+-----+------------------------------+
| 101 | N | Reference to the TZ Database |
+-----+-----+------------------------------+
Per RFC 2939 [6], IANA allocated PCode (100) and TCode (101).
根据RFC 2939[6]，IANA分配了PCode（100）和TCode（101）。
Len is the one-octet value of the length of the succeeding string for each option.
Len是每个选项的后续字符串长度的一个八位组值。
The string values that follow Len are described below. Note that they are NOT terminated by an ASCII NULL.
Len后面的字符串值如下所述。请注意，它们不是以ASCII NULL结尾的。
The semantics and content of the DHCPv6 encoding of these options are exactly the same as the encoding described for DHCPv4, other than necessary differences between the way options are encoded in DHCPv4 and DHCPv6.
这些选项的DHCPv6编码的语义和内容与DHCPv4中描述的编码完全相同，不同之处在于DHCPv4和DHCPv6中选项的编码方式存在必要的差异。
Specifically, the DHCPv6 new timezone options are described below:
具体而言，DHCPv6新时区选项描述如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NEW_POSIX_TIMEZONE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TZ POSIX String |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NEW_POSIX_TIMEZONE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TZ POSIX String |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_NEW_POSIX_TIMEZONE(41)
选项代码：选项\新建\ POSIX\时区（41）
option-length: the number of octets of the TZ POSIX String Index described below.
选项长度：下面描述的TZ POSIX字符串索引的八位字节数。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NEW_TZDB_TIMEZONE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TZ Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NEW_TZDB_TIMEZONE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TZ Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_NEW_TZDB_TIMEZONE(42)
选项代码：选项新时区（42）
option-length: the number of octets of the TZ Database String Index described below.
option length：下面描述的TZ数据库字符串索引的八位字节数。
TZ POSIX string is a string suitable for the TZ variable as specified by [1] in Section 8.3, with the exception that a string may not begin with a colon (":"). This string is NOT terminated by an ASCII NULL. Here is an example:
TZ POSIX字符串是适用于第8.3节[1]中指定的TZ变量的字符串，但字符串不能以冒号（“：”）开头。此字符串不以ASCII NULL结尾。以下是一个例子：
EST5EDT4,M3.2.0/02:00,M11.1.0/02:00
EST5EDT4,M3.2.0/02:00,M11.1.0/02:00
In this case, the string is interpreted as a timezone that is normally five hours behind UTC, and four hours behind UTC during DST, which runs from the second Sunday in March at 02:00 local time through the first Sunday in November at 02:00 local time. Normally the timezone is abbreviated "EST" but during DST it is abbreviated "EDT".
在这种情况下，字符串被解释为一个时区，通常比UTC晚5小时，在DST期间比UTC晚4小时，从3月的第二个星期日（当地时间02:00）到11月的第一个星期日（当地时间02:00）。通常时区缩写为“EST”，但在DST期间缩写为“EDT”。
Clients and servers implementing other timezone options MUST support this option for basic compatibility.
实现其他时区选项的客户端和服务器必须支持此选项以实现基本兼容性。
TZ Name is the name of a Zone entry in the database commonly referred to as the TZ database. Specifically, in the database's textual form, the string refers to the name field of a zone line. In order for this option to be useful, the client must already have a copy of the database. This string is NOT terminated with an ASCII NULL.
TZ名称是数据库中区域条目的名称，通常称为TZ数据库。具体地说，在数据库的文本形式中，字符串指区域线的名称字段。为了使此选项有用，客户端必须已经有数据库的副本。此字符串未以ASCII NULL结尾。
An example string is Europe/Zurich.
一个示例字符串是Europe/Zurich。
Clients must already have a copy of the TZ Database for this option to be useful. Configuration of the database is beyond the scope of this document. A client that supports this option SHOULD prefer this option to POSIX string if it recognizes the TZ Name that was returned. If it doesn't recognize the TZ Name, the client MUST ignore this option.
客户端必须已经有TZ数据库的副本，此选项才有用。数据库的配置超出了本文档的范围。如果支持此选项的客户机识别返回的TZ名称，则应首选此选项而不是POSIX字符串。如果无法识别TZ名称，客户端必须忽略此选项。
This specification presumes the DHCP server has some means of identifying which timezone the client is in. One obvious approach would be to associate a subnet or group of subnets with a timezone, and respond with this option accordingly.
此规范假定DHCP服务器具有某种方法来识别客户端所在的时区。一种明显的方法是将子网或子网组与时区关联，并相应地使用此选项进行响应。
When considering which option to implement on a client, one must choose between the TZ Name, which should be easier for users to configure and which provides accuracy over longer historical periods, and the TZ POSIX string, which does not require regular updating of a copy of the TZ Database. The TZ Name is better for most uses, in particular those cases where the timezone name might persist in a database for long periods of time, but the TZ POSIX string may be more suitable for small-footprint applications that are expertly maintained.
在考虑在客户机上实现哪个选项时，必须在TZ名称和TZ POSIX字符串之间进行选择，前者应便于用户配置，并在较长的历史期间提供准确性，后者不需要定期更新TZ数据库的副本。TZ名称更适合大多数用途，尤其是时区名称可能在数据库中保留很长时间的情况，但TZ POSIX字符串可能更适合于经过专业维护的占用空间小的应用程序。
So that clients need not request both options, servers who implement either timezone option SHOULD implement the other one as well. This association can be established by the server's administrator. A basic server can transmit option values to the client without parsing or validating them. A more advanced server might have a copy of the TZ database and validate TZ names against this copy, or derive TZ POSIX strings heuristically from TZ names to simplify administration.
一个客户端和另一个客户端都不需要实现这两个选项。此关联可由服务器管理员建立。基本服务器可以将选项值传输到客户端，而无需解析或验证它们。更高级的服务器可能拥有TZ数据库的副本，并根据该副本验证TZ名称，或者从TZ名称试探性地派生TZ POSIX字符串以简化管理。
As a matter of practicality, the client will use this information at its discretion to configure the current timezone in which it resides.
实际上，客户将自行决定使用此信息来配置其所在的当前时区。
It will periodically be necessary for a DHCP server to update the timezone string, based on administrative changes made by local jurisdictions (say, for instance, counties in Indiana). While the
DHCP服务器需要根据本地管辖区（例如印第安纳州的县）所做的管理更改定期更新时区字符串。而
authors do not expect this to be a lower bound on a lease time in the vast majority of cases, there may be times when anticipation of a change dictates prudence, as certain governments give little if any notification.
作者并不认为这是租赁期的下限。在绝大多数情况下，可能会有一些时候，对变化的预期要求谨慎，因为某些政府很少发出通知。
The effect of a changed timezone on client applications is not specified by this memo, but it may be helpful to note common problems in this area. Often, client applications consult the timezone setting only during process initialization, or inherit the setting from a parent process, so existing processes on a client may ignore a timezone change returned from the server. Sometimes it is normal and expected for processes on the same client to have different timezone settings (e.g., remote logins), and so client implementations should consider these ramifications of changing timezone settings of existing processes.
此备忘录未指定更改的时区对客户端应用程序的影响，但注意此区域的常见问题可能会有所帮助。通常，客户端应用程序仅在进程初始化期间参考时区设置，或从父进程继承该设置，因此客户端上的现有进程可能会忽略从服务器返回的时区更改。有时，同一客户端上的进程具有不同的时区设置（例如，远程登录）是正常的和期望的，因此客户端实现应该考虑改变现有进程的时区设置的这些后果。
When a lease has expired and new information is not forthcoming, the client MAY continue to use timezone information returned by the server. This follows the principle of least astonishment.
当租约到期且没有新信息时，客户端可以继续使用服务器返回的时区信息。这遵循了最小惊讶的原则。
Because this option provides a superset of functionality to the previous IPv4 time offset option (tag 2), and in order to maintain consistency between IPv4 and IPv6 implementation, the older option is deprecated. Current implementations that support the time offset IPv4 option SHOULD implement this option also. Other implementations SHOULD implement this option, and SHOULD NOT implement the time offset IPv4 option. As a matter of transition, clients that already use the time offset option MAY request the time offset option and the timezone option.
由于此选项为以前的IPv4时间偏移选项（标记2）提供了功能超集，并且为了保持IPv4和IPv6实现之间的一致性，不推荐使用旧选项。支持时间偏移IPv4选项的当前实现也应实现此选项。其他实现应实现此选项，而不应实现时间偏移IPv4选项。作为转换事项，已经使用时间偏移选项的客户端可能会请求时间偏移选项和时区选项。
An attacker could provide erroneous information to a client. It is possible that someone might miss a meeting or otherwise show up early, or that heavy machinery or other critical functions might act at the wrong time or fail to act. If clients have job processing tools, such as cron that operate on wall clock time, it is possible that certain jobs could be triggered either earlier or later, or even repeated or skipped entirely if scheduled during a DST transition. In such cases, the client operating system might do well to confirm timezone changes with a human.
攻击者可能向客户端提供错误信息。可能有人会错过会议或提前出现，或者重型机械或其他关键功能可能在错误的时间动作或不动作。如果客户机有作业处理工具，例如在挂钟时间运行的cron，则某些作业可能会在更早或更晚的时间触发，甚至在DST转换期间被安排时被完全重复或跳过。在这种情况下，客户机操作系统可以很好地使用人工确认时区更改。
Clients using the POSIX option should beware of any time zone setting specifying unusual characters (e.g., control characters) in the standard or daylight-saving abbreviations, as this might well trigger security-relevant bugs in applications.
使用POSIX选项的客户端应注意在标准或夏令时缩写中指定不寻常字符（如控制字符）的任何时区设置，因为这很可能会触发应用程序中与安全相关的错误。
Clients using the POSIX option should also be suspicious of any timezone setting whose UTC offset exceeds 25 hours (the POSIX limit, if the default daylight-saving offset is used). As of this writing, the maximum UTC offset is 14 hours in practice, but governments may extend this somewhat in the future.
使用POSIX选项的客户端还应怀疑UTC偏移量超过25小时的任何时区设置（如果使用默认夏时制偏移量，则为POSIX限制）。在撰写本文时，UTC的最大偏移量实际上为14小时，但政府可能会在未来将其延长。
The IANA has allocated DHCPv4 and DHCPv6 option codes for this purpose and references this document.
IANA为此分配了DHCPv4和DHCPv6选项代码，并参考了本文件。
The IANA has annotated the time offset IPv4 option (tag 2) as deprecated, with a reference to this document.
IANA已将时间偏移IPv4选项（标记2）注释为已弃用，并参考了本文档。
This document specifies a means to exchange timezone information. The hard part is actually collecting changes to the various databases from scattered sources around the world. The many volunteers on the mailing list tz@elsie.nci.nih.gov have done this nearly thankless task for many years. Thanks also go to Ralph Droms, Bernie Volz, Ted Lemon, Lisa Dusseault, John Hawkinson, Stig Venaas, and Simon Vaillancourt for their efforts to improve this work.
本文件规定了交换时区信息的方法。困难的部分实际上是从世界各地分散的来源收集对各种数据库的更改。邮寄名单上有许多志愿者tz@elsie.nci.nih.gov多年来，我一直在做这个几乎吃力不讨好的工作。还要感谢拉尔夫·德罗姆斯、伯尼·沃尔兹、特德·莱蒙、丽莎·杜肖奥、约翰·霍金森、斯蒂格·维纳斯和西蒙·维兰科特为改进这项工作所做的努力。
[1] "Standard for Information Technology - Portable Operating System Interface (POSIX) - Base Definitions", IEEE Std 1003.1-2004, December 2004.
[1] “信息技术标准.便携式操作系统接口（POSIX）.基本定义”，IEEE Std 1003.1-2004，2004年12月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[3] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[4] Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[5] Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[6] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
[6] Droms，R.，“新DHCP选项和消息类型定义的程序和IANA指南”，BCP 43，RFC 2939，2000年9月。
[7] Eggert, P. and A. Olson, "Sources for Time Zone and Daylight Saving Time Data", <http://www.twinsun.com/tz/tz-link.htm>.
[7] Eggert，P.和A.Olson，“时区和夏令时数据源”<http://www.twinsun.com/tz/tz-link.htm>.
[8] Vaillancourt, S., "Calconnect.org TC Timezone Technical Committee: Timezone Registry and Service Recommendations", April 2006.
[8] Vaillancourt，S.，“Calconnect.org TC时区技术委员会：时区注册和服务建议”，2006年4月。
[9] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.
[9] Dawson，F.和Stenerson，D.，“互联网日历和调度核心对象规范（iCalendar）”，RFC 24451998年11月。
[10] Eggert, P. and E. Reingold, "cal-dst.el --- calendar functions
for daylight savings rules", <http://cvs.savannah.gnu.org/
viewcvs/*checkout*/emacs/lisp/calendar/cal-dst.el?root=emacs>.
[10] Eggert, P. and E. Reingold, "cal-dst.el --- calendar functions
for daylight savings rules", <http://cvs.savannah.gnu.org/
viewcvs/*checkout*/emacs/lisp/calendar/cal-dst.el?root=emacs>.
Authors' Addresses
作者地址
Eliot Lear Cisco Systems GmbH Glatt-com Glattzentrum, ZH CH-8301 Switzerland
Eliot Lear Cisco系统有限公司瑞士中弘格拉茨岑特鲁姆Glatt com CH-8301
Phone: +41 1 878 9200
EMail: lear@cisco.com
Phone: +41 1 878 9200
EMail: lear@cisco.com
Paul Eggert UCLA Computer Science Department 4532J Boelter Hall Los Angeles, CA 90095 USA
加州大学洛杉矶分校计算机科学系4532J Boelter Hall洛杉矶，加利福尼亚90095
Phone: +1 310 825 3886
EMail: eggert@cs.ucla.edu
Phone: +1 310 825 3886
EMail: eggert@cs.ucla.edu
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编辑功能的资金目前由互联网协会提供。