RFC4833 日本語訳

Network Working Group                                            E. Lear
Request for Comments: 4833                            Cisco Systems GmbH
Updates: 2132                                                  P. Eggert
Category: Standards Track                                           UCLA
                                                              April 2007

コメントを求めるワーキンググループE.リア要求をネットワークでつないでください: 4833のシスコシステムズGmbHアップデート: 2132年のP.エッゲルトカテゴリ: 標準化過程UCLA2007年4月

                       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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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つの一般的な方法が、POSIX1003.1タイムゾーンストリングとタイムゾーンデータベース名です。 このメモはそれぞれのそれらのメソッドのためのDHCPオプションを指定します。 DHCPv4時間オフセットオプションは推奨しないです。

Lear & Eggert               Standards Track                     [Page 1]

RFC 4833               Timezone Options for DHCP              April 2007

リアとエッゲルトStandardsは2007年4月にDHCPのためにRFC4833タイムゾーンオプションを追跡します[1ページ]。

1.  Introduction

1. 序論

   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 Databaseの時間帯のエントリーの名前の参照

   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つの変遷に精度を提供して、変遷が十分定期的であるなら(例えば、「日曜日の現地時間の3月02:00の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 Database[7]は1970年以来のほとんどすべての本当の世界の位置のために一貫性と精度を後方に提供します。 また、TZデータベースは、1つの安定集合の人間の読み込み可能なタイムゾーン識別子を提供するのを試みます。 さらに、多くのシステムが既にTZデータベースを利用するので、使用される名前はデファクトスタンダードです。 TZデータベースが詳しい情報を含んでいるので、ものがPOSIX情報にTZ識別子に発見的に由来できますが(例のための[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].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?

1.1.  Related Work

1.1. 関連仕事

   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.

Dynamic Host Configuration Protocol(DHCP)[3]はホストがIPバージョン4ネットワークの中で彼らの現在の位置に関連する設定情報を受け取る手段を提供します。 [5]はIPバージョン6ネットワークのために同様にそうします。 RFC2132[4]は、クライアントタイムゾーン情報をUTCから秒のオフセットの形に供給するためにオプションを指定します。 クライアントが夏時間にはそれがあって、夏時間の中と、そして、夏時間からいつ変化するかを決心するためにはオプションが不十分であるので、情報は提供されました。 DSTの始めか端まで影響を受けるクライアントの満期を賃貸して、クライアントはDHCPサーバが時間まで開く一貫して正確なファッションで適切に地方の柱時計時間を表してください、その結果、指定された時間に、自己ストレス試験(控えめに言っても)に作用します。

Lear & Eggert               Standards Track                     [Page 2]

RFC 4833               Timezone Options for DHCP              April 2007

リアとエッゲルトStandardsは2007年4月にDHCPのためにRFC4833タイムゾーンオプションを追跡します[2ページ]。

   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".

その結果、さらに、オフセットがクライアントが住んでいる実際のタイムゾーンを決定できないくらいには「米国東部標準時」や「東部夏時間」であることのように人間の読み込み可能な略語を引き出す手段が全くありません。

   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のどんなグローバルな登録もない、(1つが提案されましたが、; [8]) 完全な精度が、完全なエントリーを指定しなければならないのを必要とするのを確実にしてください。 同じ情報を達成するのは300の八重奏から特定のバウンドなしで上向きに変化するでしょう。 その上、この書くこと時点で、作者はネイティブがVTIMEZONEエントリーを利用するのをオペレーティングシステムを全く意識していません。 TZURLのためのオプションを含んでいるのは可能であるかもしれません。 しかしながら、コールドスタート環境で、恐らく、同様に他のコンポーネントを苦しめるのは、デバイスがDHCPサーバを強調しているほど悪くて、賢明でなくなるでしょう。

2.  New Timezone Options for DHCPv4

2. DHCPv4のための新しいタイムゾーンオプション

   The following two options are defined for DHCPv4:

以下の2つのオプションがDHCPv4のために定義されます:

            PCode  Len   TZ-POSIX String
           +-----+-----+------------------------------+
           | 100 |  N  | IEEE 1003.1 String           |
           +-----+-----+------------------------------+

PCodeレンTZ-POSIX String+-----+-----+------------------------------+ | 100 | N| IEEE1003.1ストリング| +-----+-----+------------------------------+

            TCode  Len   TZ-Database String
           +-----+-----+------------------------------+
           | 101 |  N  | Reference to the TZ Database |
           +-----+-----+------------------------------+

TCodeレンTZ-データベースストリング+-----+-----+------------------------------+ | 101 | N| TZデータベースの参照| +-----+-----+------------------------------+

   Per RFC 2939 [6], IANA allocated PCode (100) and TCode (101).

IANAはRFC2939[6]単位でPCode(100)とTCode(101)を割り当てました。

   Len is the one-octet value of the length of the succeeding string for
   each option.

レンは各オプションのための続くストリングの長さの1八重奏の値です。

   The string values that follow Len are described below.  Note that
   they are NOT terminated by an ASCII NULL.

レンに続くストリング値は以下で説明されます。 それらがASCII NULLによって終えられないことに注意してください。

3.  New Timezone Options for DHCPv6

3. DHCPv6のための新しいタイムゾーンオプション

   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.

コード化がDHCPv4のために説明したオプションがDHCPv4でコード化される方法とDHCPv6の必要な違いを除いて、これらのオプションのDHCPv6コード化の意味論と内容はまさに同じです。

Lear & Eggert               Standards Track                     [Page 3]

RFC 4833               Timezone Options for DHCP              April 2007

リアとエッゲルトStandardsは2007年4月にDHCPのためにRFC4833タイムゾーンオプションを追跡します[3ページ]。

   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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションの_の新しい_POSIX_タイムゾーン| オプション長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TZ POSIXストリング| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 String Indexの八重奏の数。

       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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションの_の新しい_TZDB_タイムゾーン| オプション長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TZ名| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   option-code: OPTION_NEW_TZDB_TIMEZONE(42)

オプションコード: オプションの_の新しい_TZDB_タイムゾーン(42)

   option-length: the number of octets of the TZ Database String Index
   described below.

オプション長さ: 以下で説明されたTZ Database String Indexの八重奏の数。

4.  The TZ POSIX String

4. TZ POSIXストリング

   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ストリングは[1]によるセクション8.3の指定されるとしてTZ変数に適したストリングです、ストリングがコロンで始めないかもしれない例外で(「:」、) このストリングはASCII NULLによって終えられません。 ここに、例があります:

   EST5EDT4,M3.2.0/02:00,M11.1.0/02:00

M3.2.0/02: EST5EDT4、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の第2日曜日から最初の日曜日の11月02:00に稼働しますか? 通常、タイムゾーンは簡略化された「米国東部標準時」ですが、DSTの間それは簡略化された「東部夏時間」です。

   Clients and servers implementing other timezone options MUST support
   this option for basic compatibility.

他のタイムゾーンがオプションであると実装するクライアントとサーバは基本的な互換性のためのこのオプションをサポートしなければなりません。

Lear & Eggert               Standards Track                     [Page 4]

RFC 4833               Timezone Options for DHCP              April 2007

リアとエッゲルトStandardsは2007年4月にDHCPのためにRFC4833タイムゾーンオプションを追跡します[4ページ]。

5.  The TZ Name

5. TZ名

   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 Nameは一般的にTZデータベースと呼ばれたZoneデータベースへの登録の名前です。 明確に、データベースの原文のフォームでは、ストリングはゾーン線の名前欄について言及します。 このオプションが役に立つように、クライアントにはデータベースのコピーが既になければなりません。 このストリングは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 Databaseのコピーが既になければなりません。 データベースの構成はこのドキュメントの範囲を超えています。 返されたTZ Nameを認識するならSHOULDが好むこのオプションにPOSIXストリングへのこのオプションをサポートするクライアント。 TZ Nameを認識しないなら、クライアントはこのオプションを無視しなければなりません。

6.  Use of the Timezone String(s) Returned from the Server

6. タイムゾーンストリングの使用はサーバから戻りました。

   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.

(TZ Nameはユーザが構成するのは、より簡単であるはずです)。クライアントの上でどのオプションを実装したらよいかを考える場合、TZ Nameを選ばなければなりません、そして、より長い歴史的な期間、およびTZ POSIXストリングの上に精度を供給します。ストリングはTZ Databaseのコピーの定期的なアップデートを必要としません。 ほとんどの用途、特にタイムゾーン名が長期間の間のデータベースに固執するかもしれないそれらのケースには、TZ Nameは、より良いのですが、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.

また、クライアントが両方のオプションを要求する必要はないように、タイムゾーンオプションがSHOULDであると実装するサーバはもう片方を実装します。 サーバの管理者はこの協会を設立できます。 それらを分析するか、または有効にしないで、基幹サーバはオプション価値をクライアントに伝えることができます。 より高度なサーバが、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

DHCPサーバがタイムゾーンストリングをアップデートするのが定期的に必要でしょう、地方の管内(たとえば、例えば、インディアナのカウンティー)で行われた管理変更に基づいて。 the

Lear & Eggert               Standards Track                     [Page 5]

RFC 4833               Timezone Options for DHCP              April 2007

リアとエッゲルトStandardsは2007年4月にDHCPのためにRFC4833タイムゾーンオプションを追跡します[5ページ]。

   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.

クライアントアプリケーションへの変えられたタイムゾーンの効果はこのメモで指定されませんが、この領域で共有する問題に注意するのは役立っているかもしれません。 クライアントアプリケーションがしばしば、プロセス初期化だけの間タイムゾーン設定に相談するか、または親プロセスから設定を引き継ぐので、クライアントの上の既存のプロセスはサーバから返されたタイムゾーン変化を無視するかもしれません。同じクライアントの上のプロセスには異なったタイムゾーン設定(例えば、リモート・ログイン)があるのが、時々、通常であって予想されているので、クライアント実装は、変化のこれらの分岐が既存のプロセスのタイムゾーン設定であると考えるべきです。

7.  The New Timezone Option and Lease Times

7. 新しいタイムゾーンオプションとリース時間

   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.

リースが期限が切れて、新情報が用意されていないとき、クライアントは、サーバによって返されたタイムゾーン情報を使用し続けるかもしれません。これは少しの驚きの原則に従います。

8.  Deprecation of Time Offset Option

8. 時間の不賛成はオプションを相殺しました。

   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オプションがSHOULDであるとサポートする現在の実装がこのオプションも実装します。 他の実装SHOULDはこのオプションを実装します、そして、SHOULD NOTは時間がオフセットIPv4オプションであると実装します。 変遷の問題として、既に時間オフセットオプションを使用するクライアントは、時間がオプションとタイムゾーンオプションを相殺したよう要求するかもしれません。

9.  Security Considerations

9. セキュリティ問題

   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変遷の間、予定されているなら、ある仕事が、より早期か後で引き起こされるか、繰り返されるか、またはサボられさえするかもしれない、可能です。 そのような場合、クライアントオペレーティングシステムは、人間がいるタイムゾーン変化を確認するために順調であるかもしれません。

Lear & Eggert               Standards Track                     [Page 6]

RFC 4833               Timezone Options for DHCP              April 2007

リアとエッゲルトStandardsは2007年4月にDHCPのためにRFC4833タイムゾーンオプションを追跡します[6ページ]。

   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時間ですが、政府は将来、これをいくらか広げるかもしれません。

10.  IANA Considerations

10. IANA問題

   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)を注釈しました。

11.  Acknowledgments

11. 承認

   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、バーニー・フォルツ、テッドLemon、リサDusseault、ジョンHawkinson、スティVenaas、およびサイモンVaillancourtに行きます。

Lear & Eggert               Standards Track                     [Page 7]

RFC 4833               Timezone Options for DHCP              April 2007

リアとエッゲルトStandardsは2007年4月にDHCPのためにRFC4833タイムゾーンオプションを追跡します[7ページ]。

12.  References

12. 参照

12.1.  Normative References

12.1. 引用規格

   [1]   "Standard for Information Technology - Portable Operating
         System Interface (POSIX) - Base Definitions",
         IEEE Std 1003.1-2004, December 2004.

[1] 「情報技術の規格--携帯用のオペレーティングシステムインタフェース(POSIX)--基地の定義」、IEEE Std1003.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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [3]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         March 1997.

[3]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。

   [4]   Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
         Extensions", RFC 2132, March 1997.

[4] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、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ガイドラインとメッセージはタイプします」、BCP43、RFC2939、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] エッゲルトとP.とA.オルソン、「時間帯とサマータイムのデータのためのソース」、<http://www.twinsun.com/tz/tz-link.htm>。

12.2.  Informational References

12.2. 情報の参照

   [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.、「インターネットCalendaringとスケジューリングはオブジェクト仕様(iCalendar)の芯を取る」RFC2445、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] エッゲルトとP.とE.レインゴールド、「cal-dst.el」--- 「日光貯蓄規則のためのカレンダー機能」、<http://cvs.savannah.gnu.org/ viewcvs/*チェックアウト*/emacs/lisp/calendar/cal-dst.el--=emacs>を根づかせてください。

Lear & Eggert               Standards Track                     [Page 8]

RFC 4833               Timezone Options for DHCP              April 2007

リアとエッゲルトStandardsは2007年4月にDHCPのためにRFC4833タイムゾーンオプションを追跡します[8ページ]。

Authors' Addresses

作者のアドレス

   Eliot Lear
   Cisco Systems GmbH
   Glatt-com
   Glattzentrum, ZH  CH-8301
   Switzerland

エリオットリアシスコシステムズGmbHグラット-com Glattzentrum、ZH CH-8301スイス

   Phone: +41 1 878 9200
   EMail: lear@cisco.com

以下に電話をしてください。 +41 1 878 9200はメールされます: lear@cisco.com

   Paul Eggert
   UCLA
   Computer Science Department
   4532J Boelter Hall
   Los Angeles, CA  90095
   USA

ポール・エッゲルト・UCLAコンピュータサイエンス部の4532J Boelter Hallカリフォルニア90095ロサンゼルス(米国)

   Phone: +1 310 825 3886
   EMail: eggert@cs.ucla.edu

以下に電話をしてください。 +1 3886年の310 825メール: eggert@cs.ucla.edu

Lear & Eggert               Standards Track                     [Page 9]

RFC 4833               Timezone Options for DHCP              April 2007

リアとエッゲルトStandardsは2007年4月にDHCPのためにRFC4833タイムゾーンオプションを追跡します[9ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Lear & Eggert               Standards Track                    [Page 10]

リアとエッゲルト標準化過程[10ページ]