[要約] RFC 4833は、DHCPでのタイムゾーンオプションに関する仕様を提供しています。このRFCの目的は、DHCPクライアントに対して正確なタイムゾーン情報を提供することです。
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）The IETF Trust（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.
タイムゾーン情報を通信する2つの一般的な方法は、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:
このメモは、ホストに以前に利用可能だったよりも正確なタイムゾーン情報を提供する手段を指定しています。これを行うには、タイムゾーンを構成するために一般的に使用される2つの方法を使用します。
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）への少なくとも1つの移行と、移行が十分に正規である場合は、より多くの移行の精度を提供できます（たとえば、「現地時間02:00の3月2日」）。ただし、日光の節約規則の変更やその他の不規則な変更を伴う長期にわたる精度には、より詳細なメカニズムが必要です。
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.
多くのオペレーティングシステムで使用されているTZデータベース[7]は、1970年以来、ほぼすべての現実世界の場所で逆方向の一貫性と精度を提供します。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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、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 Tzidsのグローバルレジストリがないため（提案されていますが、[8]を参照）、完全な精度では完全なエントリを指定する必要があります。同じ情報を達成するには、300個のオクテットの範囲が上向きで、特に拘束されません。さらに、この執筆時点で、著者はvtimezoneエントリをネイティブに利用するオペレーティングシステムがないことを認識しています。Tzurlのオプションを含めることができるかもしれません。ただし、コールドスタート環境では、デバイスがDHCPサーバーを強調していることは十分に悪いことであり、おそらく他のコンポーネントも同様に苦しむことは賢明ではありません。
The following two options are defined for DHCPv4:
次の2つのオプションは、DHCPV4について定義されています。
PCode Len TZ-POSIX String
+-----+-----+------------------------------+
| 100 | N | IEEE 1003.1 String |
+-----+-----+------------------------------+
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は、各オプションの後続文字列の長さの1オクテット値です。
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とDHCPV6でエンコードされる方法の間の必要な違いを除き、DHCPV4について説明したエンコードとまったく同じです。
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_NEW_POSIX_TIMEZONE(41)
オプションコード：option_new_posix_timezone（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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_NEW_TZDB_TIMEZONE(42)
オプションコード：option_new_tzdb_timezone（42）
option-length: the number of octets of the TZ Database String Index described below.
オプション長：以下で説明する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ヌルによって終了しません。これが例です：
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月2日の現地時間の第2日曜日から11月2日の第1日曜日までに行われます。00現地時間。通常、タイムゾーンは「EST」を略されますが、DST中に「EDT」が省略されます。
Clients and servers implementing other timezone options MUST support this option for basic compatibility.
他のTimeZoneオプションを実装するクライアントとサーバーは、基本的な互換性のためにこのオプションをサポートする必要があります。
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ヌルで終了しません。
An example string is 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 Posix文字列をTZ名からヒューリスティックに導き出して、管理を簡素化する場合があります。
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 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.
DHCPサーバーは、地元の管轄区域（たとえば、インディアナ州の郡など）による管理上の変更に基づいて、TimeZone文字列を更新する必要があります。著者は、これが大多数のケースでリース時間の下限になるとは期待していませんが、特定の政府が通知をほとんど与えないため、変化の予想が慎重さを決定する場合があります。
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オプションをサポートする現在の実装もこのオプションを実装する必要があります。その他の実装は、このオプションを実装する必要があり、Time Offset IPv4オプションを実装しないでください。移行の問題として、既にTimeオフセットオプションを使用しているクライアントは、タイムオフセットオプションとTimeZoneオプションを要求する場合があります。
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 2132、1997年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）の動的ホスト構成プロトコル」、RFC 3315、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。and 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 TimeZone技術委員会：TimeZoneレジストリとサービスの推奨」、2006年4月。
[9] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.
[9] Dawson、F。and Stenerson、D。、「インターネットカレンダーとスケジューリングコアオブジェクト仕様（IcalEndar）」、RFC 2445、1998年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 ---夏時間の貯蓄ルールのカレンダー関数」、<http://cvs.savannah.gnu.org/ viewcvs/*checkout*/emacs/lisp/calendal/cal-dst.el?root=emacs>。
Authors' Addresses
著者のアドレス
Eliot Lear Cisco Systems GmbH Glatt-com Glattzentrum, ZH CH-8301 Switzerland
Eliot Lear Cisco Systems Gmbh Glatt-Com Glattzentrum、Zh CH-8301スイス
Phone: +41 1 878 9200
EMail: lear@cisco.com
Paul Eggert UCLA Computer Science Department 4532J Boelter Hall Los Angeles, CA 90095 USA
Paul Eggert UCLA Computer Science Department 4532J Boelter Hall Los Angeles、CA 90095 USA
Phone: +1 310 825 3886
EMail: eggert@cs.ucla.edu
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。