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
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.
タイムゾーン情報を通信する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
TZデータベースのタイムゾーンエントリの名前にOリファレンス
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）のうちの少なくとも一つの遷移のための精度を提供することができます（例えば、「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.
1970年ザ・TZデータベースはまた、ヒトが読み取り可能なタイムゾーン識別子の安定したセットを提供しようとするので、多くのオペレーティングシステムで使用されている[7] TZデータベースは、ほとんどすべての現実世界の場所の後方に一貫性と正確性を提供します。また、多くのシステムは、すでにTZデータベースを利用して、そのため使用されている名前は、デファクトスタンダードです。 TZデータベースはより多くの情報が含まれているため、一つはヒューリスティック（例えば、[10]参照）TZ識別子からPOSIX情報を導出することができるが、逆は真ではありません。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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は、Pコード（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.
レンに続く文字列値は、以下に記載されています。それらは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 NULLで終了していません。次に例を示します。
EST5EDT4,M3.2.0/02:00,M11.1.0/02:00
Astejedt 4、Ma.o 0.0 / 02：00、M 11.1.0 / 2：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時間、および02で11月の第1日曜日02:00現在の時点で3月の第2日曜日から実行DST、時のUTCの後ろの4時間であるタイムゾーンとして解釈されます。 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.
例えば、文字列は、ヨーロッパ/チューリッヒです。
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サーバは、クライアントが1つの明らかなアプローチは、タイムゾーンとサブネットのサブネットまたはグループを関連付け、それに応じてこのオプションを使用して応答するだろうに。あるタイムゾーン特定のいくつかの手段を有している前提としています。
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.
クライアントに実装するオプションを検討する場合、1は、ユーザーが設定している長い歴史にわたって精度を提供するために簡単であるべき、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 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サーバは、タイムゾーンの文字列を更新することが定期的に地元の管轄区域（たとえば、インディアナ州例えば、郡）によって行われた管理上の変更に基づいて、必要であろう。著者らは、これが例大半のリース時間の下限であることを期待していませんが変更を見越しは慎重さを指示する際、特定の政府がどの通知場合は少しを与えるように、時間があるかもしれません。
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オフセット（デフォルトのサマータイムオフセットが使用されている場合はPOSIXの制限、）25時間を超える任意のタイムゾーンの設定を疑ってみる必要があります。この記事の執筆時点で、最大オフセット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上の多くのボランティアは、長年にわたって、このほとんど報われない作業を行っています。おかげでも、この仕事を改善するための努力のためのラルフDroms、バーニーフォルツ、テッド・レモン、リサDusseault、ジョン・ホーキンソン、スティグVenaas、そしてサイモンVaillancourtに行きます。
[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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]アレクサンダー、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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニーを、 "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]、BCP 43、RFC 2939、2000年9月Droms、R.、 "新しいDHCPオプションとメッセージタイプの定義のための手順とIANAガイドライン"。
[7] Eggert, P. and A. Olson, "Sources for Time Zone and Daylight Saving Time Data", <http://www.twinsun.com/tz/tz-link.htm>.
[7]エッゲルト、P.およびA.オルソン、「タイムゾーンと夏時間データのソース」、<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]ドーソン、F.と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>.
Authors' Addresses
著者のアドレス
Eliot Lear Cisco Systems GmbH Glatt-com Glattzentrum, ZH CH-8301 Switzerland
エリオット・リアシスコシステムズ社グラットコムGlattzentrum、ZH CH-8301スイス
Phone: +41 1 878 9200 EMail: lear@cisco.com
電話：+41 1 878 9200 Eメール：lear@cisco.com
Paul Eggert UCLA Computer Science Department 4532J Boelter Hall Los Angeles, CA 90095 USA
ポール・EggertのUCLAコンピュータサイエンス学部4532J Boelterホールロサンゼルス、CA 90095 USA
Phone: +1 310 825 3886 EMail: eggert@cs.ucla.edu
電話：+1 310 825 3886 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。