[要約] RFC 7808は、タイムゾーンデータの配布サービスに関する仕様書であり、タイムゾーンデータの効率的な配布と更新を目的としています。
Internet Engineering Task Force (IETF) M. Douglass
Request for Comments: 7808 Spherical Cow Group
Category: Standards Track C. Daboo
ISSN: 2070-1721 Apple
March 2016
Time Zone Data Distribution Service
タイムゾーンデータ配信サービス
Abstract
概要
This document defines a time zone data distribution service that allows reliable, secure, and fast delivery of time zone data and leap-second rules to client systems such as calendaring and scheduling applications or operating systems.
このドキュメントは、タイムゾーンデータとうるう秒ルールを信頼性が高く、安全で、高速に配信できるタイムゾーンデータ配信サービスを定義し、カレンダーやスケジューリングアプリケーションやオペレーティングシステムなどのクライアントシステムに提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7808.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7808で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 5
3. General Considerations . . . . . . . . . . . . . . . . . . . 7
3.1. Time Zone . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Time Zone Data . . . . . . . . . . . . . . . . . . . . . 7
3.3. Time Zone Metadata . . . . . . . . . . . . . . . . . . . 7
3.4. Time Zone Data Server . . . . . . . . . . . . . . . . . . 7
3.5. Observance . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Time Zone Identifiers . . . . . . . . . . . . . . . . . . 7
3.7. Time Zone Aliases . . . . . . . . . . . . . . . . . . . . 8
3.8. Time Zone Localized Names . . . . . . . . . . . . . . . . 8
3.9. Truncating Time Zones . . . . . . . . . . . . . . . . . . 9
3.10. Time Zone Versions . . . . . . . . . . . . . . . . . . . 10
4. Time Zone Data Distribution Service Protocol . . . . . . . . 10
4.1. Server Protocol . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Time Zone Queries . . . . . . . . . . . . . . . . . . 11
4.1.2. Time Zone Formats . . . . . . . . . . . . . . . . . . 11
4.1.3. Time Zone Localization . . . . . . . . . . . . . . . 12
4.1.4. Conditional Time Zone Requests . . . . . . . . . . . 12
4.1.5. Expanded Time Zone Data . . . . . . . . . . . . . . . 14
4.1.6. Server Requirements . . . . . . . . . . . . . . . . . 14
4.1.7. Error Responses . . . . . . . . . . . . . . . . . . . 14
4.1.8. Extensions . . . . . . . . . . . . . . . . . . . . . 14
4.2. Client Guidelines . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1.1. SRV Service Labels for the Time Zone Data
Distribution Service . . . . . . . . . . . . . . 15
4.2.1.2. TXT Records for a Time Zone Data Distribution
Service . . . . . . . . . . . . . . . . . . . . . 15
4.2.1.3. Well-Known URI for a Time Zone Data Distribution
Service . . . . . . . . . . . . . . . . . . . . . 16
4.2.1.3.1. Example: Well-Known URI Redirects to Actual
Context Path . . . . . . . . . . . . . . . . 17
4.2.2. Synchronization of Time Zones . . . . . . . . . . . . 17
4.2.2.1. Initial Synchronization of All Time Zones . . . . 17
4.2.2.2. Subsequent Synchronization of All Time Zones . . 17
4.2.2.3. Synchronization with Preexisting Time Zone Data . 18
5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. "capabilities" Action . . . . . . . . . . . . . . . . . . 18
5.1.1. Example: get capabilities . . . . . . . . . . . . . . 19
5.2. "list" Action . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. Example: List Time Zone Identifiers . . . . . . . . . 22
5.3. "get" Action . . . . . . . . . . . . . . . . . . . . . . 23
5.3.1. Example: Get Time Zone Data . . . . . . . . . . . . . 24
5.3.2. Example: Conditional Get Time Zone Data . . . . . . . 25
5.3.3. Example: Get Time Zone Data Using a Time Zone Alias . 25
5.3.4. Example: Get Truncated Time Zone Data . . . . . . . . 26
5.3.5. Example: Request for a Nonexistent Time Zone . . . . 27
5.4. "expand" Action . . . . . . . . . . . . . . . . . . . . . 27
5.4.1. Example: Expanded JSON Data Format . . . . . . . . . 29
5.5. "find" Action . . . . . . . . . . . . . . . . . . . . . . 30
5.5.1. Example: find action . . . . . . . . . . . . . . . . 31
5.6. "leapseconds" Action . . . . . . . . . . . . . . . . . . 32
5.6.1. Example: Get Leap-Second Information . . . . . . . . 33
6. JSON Definitions . . . . . . . . . . . . . . . . . . . . . . 34
6.1. capabilities Action Response . . . . . . . . . . . . . . 34
6.2. list/find Action Response . . . . . . . . . . . . . . . . 37
6.3. expand Action Response . . . . . . . . . . . . . . . . . 38
6.4. leapseconds Action Response . . . . . . . . . . . . . . . 39
7. New iCalendar Properties . . . . . . . . . . . . . . . . . . 40
7.1. Time Zone Upper Bound . . . . . . . . . . . . . . . . . . 40
7.2. Time Zone Identifier Alias Property . . . . . . . . . . . 41
8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
10.1. Service Actions Registration . . . . . . . . . . . . . . 45
10.1.1. Service Actions Registration Procedure . . . . . . . 45
10.1.2. Registration Template for Actions . . . . . . . . . 46
10.1.3. Actions Registry . . . . . . . . . . . . . . . . . . 47
10.2. timezone Well-Known URI Registration . . . . . . . . . . 47
10.3. Service Name Registrations . . . . . . . . . . . . . . . 47
10.3.1. timezone Service Name Registration . . . . . . . . . 47
10.3.2. timezones Service Name Registration . . . . . . . . 48
10.4. TZDIST Identifiers Registry . . . . . . . . . . . . . . 48
10.4.1. Registration of invalid-action Error URN . . . . . . 49
10.4.2. Registration of invalid-changedsince Error URN . . . 49
10.4.3. Registration of tzid-not-found Error URN . . . . . . 50
10.4.4. Registration of invalid-format Error URN . . . . . . 50
10.4.5. Registration of invalid-start Error URN . . . . . . 50
10.4.6. Registration of invalid-end Error URN . . . . . . . 51
10.4.7. Registration of invalid-pattern Error URN . . . . . 51
10.5. iCalendar Property Registrations . . . . . . . . . . . . 52
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.1. Normative References . . . . . . . . . . . . . . . . . . 52
11.2. Informative References . . . . . . . . . . . . . . . . . 55
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
Time zone data typically combines a coordinated universal time (UTC) offset with daylight saving time (DST) rules. Time zones are typically tied to specific geographic and geopolitical regions. Whilst the UTC offset for particular regions changes infrequently, DST rules can change frequently and sometimes with very little notice (maybe hours before a change comes into effect).
タイムゾーンデータは通常、協定世界時（UTC）オフセットと夏時間（DST）ルールを組み合わせたものです。タイムゾーンは通常、特定の地理的および地政学的な地域に関連付けられています。特定の地域のUTCオフセットはめったに変更されませんが、DSTルールは頻繁に変更される場合があり、ごくわずかな通知で変更されることがあります（変更が有効になるまでに数時間かかる場合があります）。
Calendaring and scheduling systems, such as those that use iCalendar [RFC5545], as well as operating systems, critically rely on time zone data to determine the correct local time. As such, they need to be kept up to date with changes to time zone data. To date, there has been no fast and easy way to do that. Time zone data is often supplied in the form of a set of data files that have to be "compiled" into a suitable database format for use by the client application or operating system. In the case of operating systems, often those changes only get propagated to client machines when there is an operating system update, which can be infrequent, resulting in inaccurate time zone data being present for significant amounts of time. In some cases, old versions of operating systems stop being supported, but are still in use and thus require users to manually "patch" their system to keep up to date with time zone changes.
iCalendar [RFC5545]を使用するシステムやオペレーティングシステムなどのカレンダーシステムとスケジュールシステムは、タイムゾーンデータに大きく依存して正しい現地時間を決定します。そのため、タイムゾーンデータを変更して、最新の状態に保つ必要があります。今日まで、これを行うための迅速で簡単な方法はありませんでした。タイムゾーンデータは、多くの場合、クライアントアプリケーションまたはオペレーティングシステムで使用するために適切なデータベース形式に「コンパイル」する必要がある一連のデータファイルの形式で提供されます。オペレーティングシステムの場合、これらの変更は、オペレーティングシステムの更新がある場合にのみクライアントマシンに反映されることが多く、まれに、かなりの時間、不正確なタイムゾーンデータが存在します。場合によっては、古いバージョンのオペレーティングシステムはサポートされなくなりますが、まだ使用中であるため、ユーザーは手動でシステムに「パッチを適用」してタイムゾーンの変更を最新に保つ必要があります。
Along with time zone data, it is also important to track the use of leap seconds to allow a mapping between International Atomic Time (TAI) and UTC. Leap seconds can be added (or possibly removed) at various times of year in an irregular pattern typically determined by precise astronomical observations. The insertion of leap seconds into UTC is currently the responsibility of the International Earth Rotation Service.
タイムゾーンデータと共に、うるう秒の使用を追跡して、国際原子時（TAI）とUTC間のマッピングを可能にすることも重要です。うるう秒は、正確な天文観測によって通常決定される不規則なパターンで、1年のさまざまな時間に追加（または削除される可能性があります）できます。うるう秒をUTCに挿入することは、現在、国際地球回転サービスの責任です。
This specification defines a time zone data distribution service protocol that allows for fast, reliable, and accurate delivery of time zone data and leap-second information to client systems. This protocol is based on HTTP [RFC7230] using a simple JSON-based API [RFC7159].
この仕様は、タイムゾーンデータとうるう秒情報をクライアントシステムに高速で信頼性の高い正確な配信を可能にするタイムゾーンデータ配信サービスプロトコルを定義します。このプロトコルは、シンプルなJSONベースのAPI [RFC7159]を使用したHTTP [RFC7230]に基づいています。
This specification does not define the source of the time zone data or leap-second information. It is assumed that a reliable and accurate source is available. One such source is the IANA-hosted time zone database [RFC6557].
この仕様は、タイムゾーンデータまたはうるう秒情報のソースを定義していません。信頼できる正確なソースが利用可能であると想定されています。そのようなソースの1つは、IANAがホストするタイムゾーンデータベース[RFC6557]です。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Unless otherwise indicated, UTC date-time values as specified in [RFC3339] use a "Z" suffix, and not fixed numeric offsets.
特に明記されていない限り、[RFC3339]で指定されているUTC日時値は「Z」サフィックスを使用し、固定の数値オフセットではありません。
This specification contains examples of HTTP requests and responses. In some cases, additional line breaks have been introduced into the request or response data to match maximum line-length limits of this document.
この仕様には、HTTP要求と応答の例が含まれています。場合によっては、このドキュメントの最大行長の制限に合わせるために、要求または応答データに追加の改行が導入されています。
The overall process for the delivery of time zone data can be visualized via the diagram below.
タイムゾーンデータの配信プロセス全体は、次の図で視覚化できます。
==================== ====================
(a) | Contributors | | Contributors |
==================== ====================
| |
==================== ====================
(b) | Publisher A | | Publisher B |
==================== ====================
\ /
====================
(c) | Root Provider |
====================
/ | \
/ | \
====================== | ======================
(d) | Secondary Provider | | | Secondary Provider |
====================== | ======================
| | | |
| | | |
========== ========== ========== ==========
(e) | Client | | Client | | Client | | Client |
========== ========== ========== ==========
Figure 1: Time Zone Data Distribution Service Architecture
図1：タイムゾーンデータ配布サービスのアーキテクチャ
The overall service is made up of several layers:
全体的なサービスは、いくつかの層で構成されています。
(a) Contributors: Individuals, governments, or organizations that provide information about time zones to the publishing process. There can be many contributors. Note this specification does not address how contributions are made.
（a）貢献者：公開プロセスにタイムゾーンに関する情報を提供する個人、政府、または組織。多くの貢献者がいる可能性があります。この仕様は、貢献がどのように行われるかを扱っていないことに注意してください。
(b) Publishers: Publishers aggregate information from contributors, determine the reliability of the information and, based on that, generate time zone data. There can be many publishers, each getting information from many different contributors. In some cases, a publisher may choose to "republish" data from another publisher.
（b）パブリッシャー：パブリッシャーは、コントリビューターからの情報を集約し、情報の信頼性を判断し、それに基づいてタイムゾーンデータを生成します。多くのパブリッシャーが存在し、それぞれが多くの異なるコントリビューターから情報を取得する場合があります。場合によっては、発行者が別の発行者からのデータを「再発行」することを選択することがあります。
(c) Root Providers: Servers that obtain and then provide the time zone data from publishers and make that available to other servers or clients. There can be many root providers. Root providers can choose to supply time zone data from one or more publishers.
（c）ルートプロバイダー：パブリッシャーからタイムゾーンデータを取得して提供し、他のサーバーまたはクライアントで利用できるようにするサーバー。多くのルートプロバイダーが存在する可能性があります。ルートプロバイダーは、1つ以上のパブリッシャーからタイムゾーンデータを提供することを選択できます。
(d) Secondary Providers: Servers that handle the bulk of the requests and reduce the load on root servers. These will typically be simple, caches of the root server, located closer to clients. For example a large Internet Service Provider (ISP) may choose to set up their own secondary provider to allow clients within their network to make requests of that server rather than make requests of servers outside their network. Secondary servers will cache and periodically refresh data from the root servers.
（d）セカンダリプロバイダー：要求の大部分を処理し、ルートサーバーの負荷を軽減するサーバー。これらは通常、ルートサーバーの単純なキャッシュであり、クライアントの近くに配置されます。たとえば、大規模なインターネットサービスプロバイダー（ISP）は、ネットワーク内のクライアントがネットワーク外のサーバーの要求を作成するのではなく、ネットワーク内のクライアントがそのサーバーの要求を作成できるように独自のセカンダリプロバイダーをセットアップすることを選択できます。セカンダリサーバーは、ルートサーバーからのデータをキャッシュし、定期的に更新します。
(e) Clients: Applications, operating systems, etc., that make use of time zone data and retrieve that from either root or secondary providers.
（e）クライアント：タイムゾーンデータを利用し、ルートまたはセカンダリプロバイダーから取得するアプリケーション、オペレーティングシステムなど。
Some of those layers may be coalesced by implementors. For example, a vendor may choose to implement the entire service as a single monolithic virtual server with the address embedded in distributed systems. Others may choose to provide a service consisting of multiple layers of providers, many secondary servers, and a small number of root servers.
それらの層のいくつかは、実装者によって合体される場合があります。たとえば、ベンダーは、サービス全体を、分散システムに埋め込まれたアドレスを持つ単一のモノリシック仮想サーバーとして実装することを選択できます。また、プロバイダーの複数のレイヤー、多くのセカンダリサーバー、および少数のルートサーバーで構成されるサービスを提供することもできます。
This specification is concerned only with the protocol used to exchange data between providers and from provider to client. This specification does not define how contributors pass their information to publishers, nor how those publishers vet that information to obtain trustworthy data, nor the format of the data produced by the publishers.
この仕様は、プロバイダー間およびプロバイダーからクライアントへのデータ交換に使用されるプロトコルにのみ関係します。この仕様では、貢献者が情報をパブリッシャーに渡す方法や、それらのパブリッシャーが信頼できるデータを取得するために情報を精査する方法や、パブリッシャーが作成するデータの形式を定義していません。
This section defines several terms and explains some key concepts used in this specification.
このセクションでは、いくつかの用語を定義し、この仕様で使用されるいくつかの重要な概念について説明します。
A time zone is a description of the past and predicted future timekeeping practices of a collection of clocks that are intended to agree.
タイムゾーンは、同意することを目的とした時計のコレクションの過去および予測される将来の計時手法の説明です。
Note that the term "time zone" does not have the common meaning of a region of the world at a specific UTC offset, possibly modified by daylight saving time. For example, the "Central European Time" zone can correspond to several time zones "Europe/Berlin", "Europe/Paris", etc., because subregions have kept time differently in the past.
「タイムゾーン」という用語は、特定のUTCオフセットでの世界の地域の一般的な意味を持たないことに注意してください。夏時間によって変更される可能性があります。たとえば、「中央ヨーロッパ時間」ゾーンは、「ヨーロッパ/ベルリン」、「ヨーロッパ/パリ」などのいくつかのタイムゾーンに対応できます。これは、サブリージョンの過去の時間が異なるためです。
Time zone data is data that defines a single time zone, including an identifier, UTC offset values, DST rules, and other information such as time zone abbreviations.
タイムゾーンデータは、識別子、UTCオフセット値、DSTルール、およびタイムゾーンの省略形などの他の情報を含む、単一のタイムゾーンを定義するデータです。
Time zone metadata is data that describes additional properties of a time zone that is not itself included in the time zone data. This can include such things as the publisher name, version identifier, aliases, and localized names (see below).
タイムゾーンメタデータは、それ自体がタイムゾーンデータに含まれていないタイムゾーンの追加プロパティを説明するデータです。これには、発行者名、バージョン識別子、エイリアス、ローカライズされた名前などを含めることができます（以下を参照）。
A time zone data server is a server implementing the Time Zone Data Distribution Service Protocol defined by this specification.
タイムゾーンデータサーバーは、この仕様で定義されているタイムゾーンデータ配布サービスプロトコルを実装するサーバーです。
A time zone with varying rules for the UTC offset will have adjacent periods of time that use different UTC offsets. Each period of time with a constant UTC offset is called an observance.
UTCオフセットのルールが異なるタイムゾーンには、異なるUTCオフセットを使用する隣接する期間があります。一定のUTCオフセットを持つ各期間は、遵守と呼ばれます。
Time zone identifiers are unique names associated with each time zone, as defined by publishers. The iCalendar [RFC5545] specification has a "TZID" property and parameter whose value is set to the corresponding time zone identifier and used to identify time zone data and relate time zones to start and end dates in events, etc. This specification does not define what format of time zone identifiers should be used. It is possible that time zone identifiers from different publishers overlap, and there might be a need for a provider to distinguish those with some form of "namespace" prefix identifying the publisher. However, development of a standard (global) naming scheme for time zone identifiers is out of scope for this specification.
タイムゾーン識別子は、発行元によって定義されているように、各タイムゾーンに関連付けられた一意の名前です。 iCalendar [RFC5545]仕様には「TZID」プロパティとパラメーターがあり、その値は対応するタイムゾーン識別子に設定され、タイムゾーンデータを識別し、タイムゾーンをイベントの開始日や終了日などに関連付けるために使用されます。この仕様では定義されていません使用するタイムゾーン識別子の形式。異なる発行元からのタイムゾーン識別子が重複している可能性があり、プロバイダーが発行元を識別する何らかの「名前空間」接頭辞を持つものを区別する必要がある場合があります。ただし、タイムゾーン識別子の標準（グローバル）命名スキームの開発は、この仕様の範囲外です。
Time zone aliases map a name onto a time zone identifier. For example, "US/Eastern" is usually mapped on to "America/New_York". Time zone aliases are typically used interchangeably with time zone identifiers when presenting information to users.
タイムゾーンエイリアスは、名前をタイムゾーン識別子にマップします。たとえば、「US / Eastern」は通常「America / New_York」にマップされます。タイムゾーンエイリアスは、通常、ユーザーに情報を提示するときにタイムゾーン識別子と同じ意味で使用されます。
A time zone data distribution service needs to maintain time zone alias mapping information and expose that data to clients as well as allow clients to query for time zone data using aliases. When returning time zone data to a client, the server returns the data with an identifier matching the query, but it can include one or more additional identifiers in the data to provide a hint to the client that alternative identifiers are available. For example, a query for "US/Eastern" could include additional identifiers for "America/ New_York" or "America/Montreal".
タイムゾーンデータ配布サービスは、タイムゾーンエイリアスマッピング情報を維持し、そのデータをクライアントに公開するだけでなく、クライアントがエイリアスを使用してタイムゾーンデータを照会できるようにする必要があります。タイムゾーンデータをクライアントに返す場合、サーバーはクエリに一致する識別子を使用してデータを返しますが、データに1つ以上の追加の識別子を含めて、代替の識別子が利用可能であるというヒントをクライアントに提供できます。たとえば、「US / Eastern」のクエリには、「America / New_York」または「America / Montreal」の追加の識別子を含めることができます。
The set of aliases may vary depending on whether time zone data is truncated (see Section 3.9). For example, a client located in the US state of Michigan may see "US/Eastern" as an alias for "America/ Detroit", whereas a client in the US state of New Jersey may see it as an alias for "America/New_York", and all three names may be aliases if time zones are truncated to post-2013 data.
エイリアスのセットは、タイムゾーンデータが切り捨てられているかどうかによって異なる場合があります（セクション3.9を参照）。たとえば、米国ミシガン州にいるクライアントは「US / Eastern」を「America / Detroit」のエイリアスとして表示することがありますが、米国ニュージャージー州のクライアントは「America / New_York」のエイリアスとして表示する場合があります。 "そして、タイムゾーンが2013年以降のデータに切り捨てられている場合、3つすべての名前がエイリアスである可能性があります。
Localized names are names for time zones that can be presented to a user in their own language. Each time zone may have one or more localized names associated with it. Names would typically be unique in their own locale as they might be presented to the user in a list. Localized names are distinct from abbreviations commonly used for UTC offsets within a time zone. For example, the time zone "America/ New_York" may have the localized name "Nueva York" in a Spanish locale, as distinct from the abbreviations "EST" and "EDT", which may or may not have their own localizations.
ローカライズされた名前は、ユーザーの母国語で提示できるタイムゾーンの名前です。各タイムゾーンには、1つ以上のローカライズされた名前が関連付けられている場合があります。名前は通常、リストでユーザーに提示される可能性があるため、独自のロケールで一意になります。ローカライズされた名前は、タイムゾーン内のUTCオフセットに一般的に使用される略語とは異なります。たとえば、タイムゾーン "America / New_York"は、スペイン語のロケールでローカライズされた名前 "Nueva York"を持つ場合があります。これは、独自のローカライズがある場合とない場合がある略語 "EST"と "EDT"とは異なります。
A time zone data distribution service might need to maintain localized name information, for one or more chosen languages, as well as allow clients to query for time zone data using localized names.
タイムゾーンデータ配布サービスでは、選択した1つ以上の言語のローカライズされた名前情報を維持し、クライアントがローカライズされた名前を使用してタイムゾーンデータを照会できるようにする必要があります。
Time zone data can contain information about past and future UTC offsets that may not be relevant for a particular server's intended clients. For example, calendaring and scheduling clients are likely most concerned with time zone data that covers a period for one or two years in the past on into the future, as users typically create new events only for the present and future. Similarly, time zone data might contain a large amount of "future" information about transitions occurring many decades into the future. Again, clients might be concerned only with a smaller range into the future, and data past that point might be unnecessary.
タイムゾーンデータには、特定のサーバーの対象クライアントに関連しない可能性がある過去および将来のUTCオフセットに関する情報を含めることができます。たとえば、ユーザーは通常、現在と未来のためにのみ新しいイベントを作成するため、カレンダーとスケジュールのクライアントは、過去1年から2年の期間をカバーするタイムゾーンデータに最も関係している可能性があります。同様に、タイムゾーンデータには、何十年も先に発生する遷移に関する大量の「将来の」情報が含まれる場合があります。繰り返しになりますが、クライアントは将来の狭い範囲のみに関心を持ち、その時点を過ぎたデータは不要になる場合があります。
To avoid having to send unnecessary data, servers can choose to truncate time zone data to a range determined by start- and end-point date-time values, and to provide only offsets and rules between those points. If such truncation is done, the server MUST include the ranges it is using in the "capabilities" action response (see Section 6.1), so that clients can take appropriate action if they need time zone data for times outside of those ranges.
不要なデータを送信しなくても済むように、サーバーはタイムゾーンデータを開始点と終了点の日時値によって決定される範囲に切り捨て、それらのポイント間のオフセットとルールのみを提供することを選択できます。そのような切り捨てが行われる場合、サーバーは、「機能」アクション応答（セクション6.1を参照）にサーバーが使用している範囲を含める必要があります。これにより、クライアントは、これらの範囲外の時間のタイムゾーンデータが必要な場合に適切なアクションを実行できます。
The truncation points at the start and end of a range are always a UTC date-time value, with the start point being "inclusive" to the overall range, and the end point being "exclusive" to the overall range (i.e., the end value is just past the end of the last valid value in the range). A server will advertise a truncation range for the truncated data it can supply or will provide an indicator that it can truncate at any start or end point to produce arbitrary ranges. In addition, the server can advertise that it supplies untruncated data -- that is, data that covers the full range of times available from the source publisher. In the absence of any indication of truncated data available on the server, the server will supply only untruncated data.
範囲の開始と終了の切り捨てポイントは常にUTC日時値であり、開始ポイントは範囲全体に対して「包括的」であり、終了ポイントは範囲全体に対して「排他的」です（つまり、終了値が、範囲内の最後の有効な値の終わりを過ぎています。サーバーは、提供できる切り捨てられたデータの切り捨て範囲をアドバタイズするか、任意の開始点または終了点で切り捨てて任意の範囲を生成できることを示すインジケーターを提供します。さらに、サーバーは、切り捨てられていないデータ、つまりソースパブリッシャーから利用可能なすべての時間をカバーするデータを提供することをアドバタイズできます。サーバーで使用可能な切り捨てられたデータの兆候がない場合、サーバーは切り捨てられていないデータのみを提供します。
When truncating the start of a "VTIMEZONE" component, the server MUST include exactly one "STANDARD" or "DAYLIGHT" subcomponent with a "DTSTART" property value that matches the start point of the truncation range, and appropriate "TZOFFSETFROM" and "TZOFFSETTO" properties to indicate the correct offset in effect right before and after the start point of the truncation range. This subcomponent, which is the first observance defined by the time zone data, represents the earliest valid date-time covered by the time zone data in the truncated "VTIMEZONE" component.
「VTIMEZONE」コンポーネントの先頭を切り捨てる場合、サーバーは、切り捨て範囲の開始点と一致する「DTSTART」プロパティ値、および適切な「TZOFFSETFROM」と「TZOFFSETTO」を持つ「STANDARD」または「DAYLIGHT」サブコンポーネントを1つだけ含める必要があります。 "プロパティは、切り捨て範囲の開始点の直前と直後の有効なオフセットを示します。このサブコンポーネントは、タイムゾーンデータによって定義される最初の遵守であり、切り捨てられた「VTIMEZONE」コンポーネントのタイムゾーンデータによってカバーされる最も早い有効な日時を表します。
When truncating the end of a "VTIMEZONE" component, the server MUST include a "TZUNTIL" iCalendar property (Section 7.1) in the "VTIMEZONE" component to indicate the end point of the truncation range.
「VTIMEZONE」コンポーネントの末尾を切り捨てる場合、サーバーは「VTIMEZONE」コンポーネントに「TZUNTIL」iCalendarプロパティ（セクション7.1）を含めて、切り捨て範囲の終了点を示す必要があります。
Time zone data changes over time, and it is important for consumers of that data to stay up to date with the latest versions. As a result, it is useful to identify individual time zones with a specific version number or version identifier as supplied by the time zone data publisher. There are two common models that time zone data publishers might use to publish updates to time zone data:
タイムゾーンデータは時間の経過とともに変化するため、そのデータの利用者は最新バージョンを最新の状態に保つことが重要です。そのため、タイムゾーンデータの発行元から提供された特定のバージョン番号またはバージョン識別子を使用して、個々のタイムゾーンを識別すると便利です。タイムゾーンデータの発行者がタイムゾーンデータの更新を公開するために使用する可能性がある2つの一般的なモデルがあります。
a. with the "monolithic" model, the data for all time zones is published in one go, with a single version number or identifier applied to the entire data set. For example, a publisher producing data several times a year might use version identifiers "2015a", "2015b", etc.
a. 「モノリシック」モデルでは、すべてのタイムゾーンのデータが一度に公開され、単一のバージョン番号または識別子がデータセット全体に適用されます。たとえば、年に数回データを生成する発行者は、バージョン識別子「2015a」、「2015b」などを使用する場合があります。
b. with the "incremental" model, each time zone has its own version identifier, so that each time zone can be independently updated without impacting any others. For example, if the initial data has version "A.1" for time zone "A", and "B.1" for time zone "B", and then time zone "B" changes; when the data is next published, time zone "A" will still have version "A.1", but time zone "B" will now have "B.2".
b. 「インクリメンタル」モデルでは、各タイムゾーンに独自のバージョン識別子があるため、他のタイムゾーンに影響を与えることなく、各タイムゾーンを個別に更新できます。たとえば、初期データのタイムゾーン「A」がバージョン「A.1」、タイムゾーン「B」が「B.1」の場合、タイムゾーン「B」が変更されます。データが次に公開されたとき、タイムゾーン "A"のバージョンは "A.1"のままですが、タイムゾーン "B"のバージョンは "B.2"になります。
A time zone data distribution service needs to ensure that the version identifiers used by the time zone data publisher are available to any client, along with the actual publisher name on a per-time-zone basis. This allows clients to compare publisher/ version details on any server, with existing locally cached client data, and only fetch those time zones that have actually changed (see Section 4.2.2 for more details on how clients synchronize data from the server).
タイムゾーンデータ配布サービスは、タイムゾーンデータパブリッシャーが使用するバージョン識別子を、タイムゾーンごとの実際のパブリッシャー名と共に、すべてのクライアントが利用できるようにする必要があります。これにより、クライアントは、サーバー上のパブリッシャー/バージョンの詳細を既存のローカルにキャッシュされたクライアントデータと比較し、実際に変更されたタイムゾーンのみをフェッチできます（クライアントがサーバーからデータを同期する方法の詳細については、セクション4.2.2を参照してください）。
The time zone data distribution service protocol uses HTTP [RFC7230] for query and delivery of time zone data, metadata, and leap-second information. The interactions with the HTTP server can be broken down into a set of "actions" that define the overall function being requested (see Section 5). Each action targets a specific HTTP resource using the GET method, with various request-URI parameters altering the behavior as needed.
タイムゾーンデータ配布サービスプロトコルは、タイムゾーンデータ、メタデータ、およびうるう秒情報のクエリと配信にHTTP [RFC7230]を使用します。 HTTPサーバーとの対話は、要求される機能全体を定義する一連の「アクション」に分解できます（セクション5を参照）。各アクションは、GETメソッドを使用して特定のHTTPリソースをターゲットにし、さまざまなリクエストURIパラメータを使用して、必要に応じて動作を変更します。
The HTTP resources used for requests will be identified via URI templates [RFC6570]. The overall time zone data distribution service has a "context path" request-URI template defined as "{/service-prefix}". This "root" prefix is discovered by the client as per
リクエストに使用されるHTTPリソースは、URIテンプレート[RFC6570]によって識別されます。全体的なタイムゾーンデータ配布サービスには、「{/ service-prefix}」として定義された「コンテキストパス」リクエストURIテンプレートがあります。この「ルート」プレフィックスは、クライアントによって次のように発見されます
Section 4.2.1. Request-URIs that target time zone data directly use the prefix template "{/service-prefix,data-prefix}". The second component of the prefix template can be used to introduce additional path segments in the request-URI to allow for alternative ways to "partition" the time zone data. For example, time zone data might be partitioned by publisher release dates or version identifiers. This specification does not define any partitions; that is left for future extensions. When the "data-prefix" variable is empty, the server is expected to return the current version of time zone data it has for all publishers it supports.
セクション4.2.1。タイムゾーンデータをターゲットとするリクエストURIは、プレフィックステンプレート「{/ service-prefix、data-prefix}」を直接使用します。プレフィックステンプレートの2番目のコンポーネントを使用して、リクエストURIに追加のパスセグメントを導入し、タイムゾーンデータを「パーティション化」する別の方法を許可できます。たとえば、タイムゾーンデータは、発行者のリリース日またはバージョン識別子によって分割される場合があります。この仕様では、パーティションは定義されていません。それは将来の拡張のために残されています。 「data-prefix」変数が空の場合、サーバーは、サポートするすべてのパブリッシャー用に保持しているタイムゾーンデータの現在のバージョンを返すことが期待されています。
All URI template variable values, and URI request parameters that contain text values, MUST be encoded using the UTF-8 [RFC3629] character set. All responses MUST return data using the UTF-8 [RFC3629] character set. It is important to note that any "/" characters, which are frequently found in time zone identifiers, are percent-encoded when used in the value of a path segment expansion variable in a URI template (as per Section 3.2.6 of [RFC6570]). Thus, the time zone identifier "America/New_York" would appear as "America%2FNew_York" when used as the value for the "{/tzid}" URI template variable defined later in this specification.
すべてのURIテンプレート変数値、およびテキスト値を含むURI要求パラメーターは、UTF-8 [RFC3629]文字セットを使用してエンコードする必要があります。すべての応答は、UTF-8 [RFC3629]文字セットを使用してデータを返す必要があります。タイムゾーン識別子に頻繁に見られる「/」文字は、URIテンプレートのパスセグメント拡張変数の値に使用するとパーセントエンコードされることに注意することが重要です（[RFC6570のセクション3.2.6に従って]）。したがって、タイムゾーン識別子「America / New_York」は、この仕様で後で定義される「{/ tzid}」URIテンプレート変数の値として使用される場合、「America％2FNew_York」として表示されます。
The server provides time zone metadata in the form of a JSON [RFC7159] object. Clients can directly request the time zone metadata or issue queries for subsets of metadata that match specific criteria.
サーバーは、JSON [RFC7159]オブジェクトの形式でタイムゾーンメタデータを提供します。クライアントは、タイムゾーンメタデータを直接要求するか、特定の基準に一致するメタデータのサブセットに対してクエリを発行できます。
Security and privacy considerations for this protocol are discussed in detail in Sections 8 and 9, respectively.
このプロトコルのセキュリティとプライバシーの考慮事項については、それぞれセクション8とセクション9で詳しく説明します。
Time zone identifiers, aliases, or localized names can be used to query for time zone data or metadata. This will be more explicitly defined below for each action. In general, however, if a "tzid" URI template variable is used, then the value may be an identifier or an alias. When the "pattern" URI query parameter is used, it may be an identifier, an alias, or a localized name.
タイムゾーン識別子、エイリアス、またはローカライズされた名前を使用して、タイムゾーンデータまたはメタデータを照会できます。これは、各アクションに対して以下でより明確に定義されます。ただし、一般に、「tzid」URIテンプレート変数が使用される場合、値は識別子またはエイリアスになる可能性があります。 「パターン」URIクエリパラメータを使用する場合、識別子、エイリアス、またはローカライズされた名前を使用できます。
The default media type [RFC2046] format for returning time zone data is the iCalendar [RFC5545] data format. In addition, the iCalendar-in-XML [RFC6321] and iCalendar-in-JSON [RFC7265] representations are available. Clients use the HTTP Accept header field (see Section 5.3.2 of [RFC7231]) to indicate their preference for the returned data format. Servers indicate the available formats that they support via the "capabilities" action response (Section 5.1).
タイムゾーンデータを返すためのデフォルトのメディアタイプ[RFC2046]形式は、iCalendar [RFC5545]データ形式です。さらに、iCalendar-in-XML [RFC6321]およびiCalendar-in-JSON [RFC7265]表現も使用できます。クライアントは、HTTP Acceptヘッダーフィールド（[RFC7231]のセクション5.3.2を参照）を使用して、返されるデータ形式の設定を示します。サーバーは、「機能」アクション応答を介して、サポートする利用可能な形式を示します（セクション5.1）。
As per Section 3.8, time zone data can support localized names. Clients use the HTTP Accept-Language header field (see Section 5.3.5 of [RFC7231]) to indicate their preference for the language used for localized names in the response data.
セクション3.8のとおり、タイムゾーンデータはローカライズされた名前をサポートできます。クライアントは、HTTP Accept-Languageヘッダーフィールド（[RFC7231]のセクション5.3.5を参照）を使用して、応答データでローカライズされた名前に使用される言語の優先順位を示します。
When time zone data or metadata changes, it needs to be distributed in a timely manner because changes to local time offsets might occur within a few days of the publication of the time zone data changes. Typically, the number of time zones that change is small, whilst the overall number of time zones can be large. Thus, when a client is using more than a few time zones, it is more efficient for the client to be able to download only those time zones that have changed (an incremental update).
タイムゾーンデータまたはメタデータが変更された場合、タイムゾーンデータ変更の公開から数日以内にローカルタイムオフセットの変更が発生する可能性があるため、タイムゾーンデータまたはメタデータをタイムリーに配布する必要があります。通常、変化するタイムゾーンの数は少なく、タイムゾーンの総数は多くなる可能性があります。したがって、クライアントがいくつかのタイムゾーンより多くを使用している場合、クライアントが変更されたタイムゾーンのみをダウンロードできるようにする方が効率的です（増分更新）。
Clients initially request a full list of time zones from the server using a "list" action request (see Section 5.2). The response to that request includes two items the client caches for use with subsequent "conditional" (incremental update) requests:
クライアントは最初に、「リスト」アクション要求を使用してサーバーにタイムゾーンの完全なリストを要求します（セクション5.2を参照）。その要求への応答には、後続の「条件付き」（増分更新）要求で使用するためにクライアントがキャッシュする2つの項目が含まれます。
1. An opaque synchronization token in the "synctoken" JSON member. This token changes whenever there is a change to any metadata associated with one or more time zones (where the metadata is the information reported in the "list" action response for each time zone).
1. 「synctoken」JSONメンバーの不透明な同期トークン。このトークンは、1つ以上のタイムゾーンに関連付けられているメタデータが変更されるたびに変更されます（メタデータは、各タイムゾーンの「リスト」アクションレスポンスで報告される情報です）。
2. The HTTP ETag header field value for each time zone returned in the response. The ETag header field value is returned in the "etag" JSON member, and it corresponds to the ETag header field value that would be returned when executing a "get" action request (see Section 5.3) against the corresponding time zone data resource.
2. 応答で返された各タイムゾーンのHTTP ETagヘッダーフィールド値。 ETagヘッダーフィールド値は「etag」JSONメンバーで返され、対応するタイムゾーンデータリソースに対して「get」アクションリクエスト（セクション5.3を参照）を実行したときに返されるETagヘッダーフィールド値に対応します。
For subsequent updates to cached data, clients can use the following procedure:
キャッシュされたデータに対するその後の更新では、クライアントは次の手順を使用できます。
a. Send a "list" action request with a "changedsince" URI query parameter with its value set to the last opaque synchronization token returned by the server. The server will return time zone metadata for only those time zones that have changed since the last request.
a. サーバーから返された最後の不透明な同期トークンに値が設定された「changedsince」URIクエリパラメーターを使用して、「リスト」アクションリクエストを送信します。サーバーは、最後の要求以降に変更されたタイムゾーンのみのタイムゾーンメタデータを返します。
b. The client will cache the new opaque synchronization token returned in the response for the next incremental update, along with the returned time zone metadata information.
b. クライアントは、次の増分更新の応答で返された新しい不透明な同期トークンを、返されたタイムゾーンのメタデータ情報とともにキャッシュします。
c. The client will check each time zone metadata to see if the "etag" value is different from that of any cached time zone data it has.
c. クライアントは、各タイムゾーンメタデータをチェックして、「etag」の値が、キャッシュされているタイムゾーンデータの値と異なるかどうかを確認します。
d. The client will use a "get" action request to update any cached time zone data for those time zones whose ETag header field value has changed.
d. クライアントは「取得」アクション要求を使用して、ETagヘッダーフィールド値が変更されたタイムゾーンのキャッシュされたタイムゾーンデータを更新します。
Note that time zone metadata will always change when the corresponding time zone data changes. However, the converse is not true: it is possible for some piece of the time zone metadata to change without the corresponding time zone data changing. e.g., for the case of a "monolithic" publisher (see Section 3.10), the version identifier in every time zone metadata element will change with each new published revision; however, only a small subset of time zone data will actually change.
タイムゾーンのメタデータは、対応するタイムゾーンのデータが変更されると常に変更されることに注意してください。ただし、その逆は当てはまりません。対応するタイムゾーンデータが変更されずに、タイムゾーンメタデータの一部が変更される可能性があります。たとえば、「モノリシック」パブリッシャーの場合（セクション3.10を参照）、すべてのタイムゾーンメタデータ要素のバージョンIDは、新しく発行されるリビジョンごとに変わります。ただし、実際に変更されるのは、タイムゾーンデータの小さなサブセットのみです。
If a client needs data for only one or a small set of time zones (e.g., a clock in a fixed location), then it can use a conditional HTTP request to determine if the time zone data has changed and retrieve the new data. The full details of HTTP conditional requests are described in [RFC7232]; what follows is a brief summary of what a client typically does.
クライアントが必要とするタイムゾーンが1つまたは少数のセット（たとえば、固定された場所にある時計）の場合、条件付きHTTPリクエストを使用して、タイムゾーンデータが変更されたかどうかを判断し、新しいデータを取得できます。 HTTP条件付きリクエストの詳細については、[RFC7232]で説明されています。以下は、クライアントが通常行うことの簡単な要約です。
a. When the client retrieves the time zone data from the server using a "get" action (see Section 5.3), the server will include an HTTP ETag header field in the response.
a. クライアントが「取得」アクション（セクション5.3を参照）を使用してサーバーからタイムゾーンデータを取得すると、サーバーは応答にHTTP ETagヘッダーフィールドを含めます。
b. The client will store the value of that header field along with the request-URI used for the request.
b. クライアントは、そのヘッダーフィールドの値と、リクエストに使用されるリクエストURIを格納します。
c. When the client wants to check for an update, it issues another "get" action HTTP request on the original request-URI, but this time it includes an If-None-Match HTTP request header field, with a value set to the ETag header field value from the previous response. If the data for the time zone has not changed, the server will return a 304 (Not Modified) HTTP response. If the data has changed, the server will return a normal HTTP success response that will include the changed data, as well as a new value for the ETag header field.
c. クライアントが更新を確認する場合、元のリクエストURIで別の「取得」アクションHTTPリクエストを発行しますが、今回は、値がETagヘッダーに設定されたIf-None-Match HTTPリクエストヘッダーフィールドが含まれています前の応答のフィールド値。タイムゾーンのデータが変更されていない場合、サーバーは304（変更されていない）HTTP応答を返します。データが変更されている場合、サーバーは、変更されたデータとETagヘッダーフィールドの新しい値を含む通常のHTTP成功応答を返します。
Clients SHOULD poll for changes, using an appropriate conditional request, at least once a day. A server acting as a secondary provider, caching time zone data from another server, SHOULD poll for changes once per hour. See Section 8 on expected client and server behavior regarding high request rates.
クライアントは、適切な条件付き要求を使用して、少なくとも1日に1回、変更をポーリングする必要があります（SHOULD）。セカンダリプロバイダーとして機能し、別のサーバーからのタイムゾーンデータをキャッシュするサーバーは、変更を1時間に1回ポーリングする必要があります（SHOULD）。高いリクエストレートに関するクライアントとサーバーの予想される動作については、セクション8を参照してください。
Determining time zone offsets at a particular point in time is often a complicated process, as the rules for daylight saving time can be complex. To help with this, the time zone data distribution service provides an action that allows clients to request the server to expand a time zone into a set of "observances" over a fixed period of time (see Section 5.4). Each of these observances describes a UTC onset time and UTC offsets for the prior time and the observance time. Together, these provide a quick way for "thin" clients to determine an appropriate UTC offset for an arbitrary date without having to do full time zone expansion themselves.
夏時間のルールは複雑になる可能性があるため、特定の時点でのタイムゾーンオフセットの決定は、多くの場合複雑なプロセスです。これを支援するために、タイムゾーンデータ配布サービスは、クライアントがサーバーにタイムゾーンを一定期間の一連の「遵守」に拡張するように要求できるアクションを提供します（セクション5.4を参照）。これらの順守のそれぞれは、前の時間と順守時間のUTC開始時間とUTCオフセットを記述します。これらを組み合わせることで、「シン」クライアントが任意の日付の適切なUTCオフセットを決定するための迅速な方法が提供されます。
To enable a simple client implementation, servers SHOULD ensure that they provide or cache data for all commonly used time zones, from various publishers. That allows client implementations to configure a single server to get all time zone data. In turn, any server can refresh any of the data from any other server -- though the root servers may provide the most up-to-date copy of the data.
シンプルなクライアント実装を可能にするために、サーバーは、さまざまなパブリッシャーからのすべての一般的に使用されるタイムゾーンのデータを提供またはキャッシュすることを保証する必要があります。これにより、クライアントの実装で単一のサーバーを構成して、すべてのタイムゾーンデータを取得できます。次に、どのサーバーでも他のサーバーのデータを更新できます。ただし、ルートサーバーがデータの最新のコピーを提供する場合があります。
When an HTTP error response is returned to the client, the server SHOULD return a JSON "problem details" object in the response body, as per [RFC7807]. Every JSON "problem details" object MUST include a "type" member with a URI value matching the applicable error code (defined for each action in Section 5).
HTTPエラー応答がクライアントに返されると、サーバーは[RFC7807]に従って、JSONの「問題の詳細」オブジェクトを応答の本文で返す必要があります（SHOULD）。すべてのJSON "問題の詳細"オブジェクトには、該当するエラーコード（セクション5の各アクションに対して定義されている）に一致するURI値を持つ "タイプ"メンバーを含める必要があります。
This protocol is designed to be extensible through a standards-based registration mechanism (see Section 10). It is anticipated that other useful time zone actions will be added in the future (e.g., mapping a geographical location to time zone identifiers, getting change history for time zones), and so, servers MUST return a description of their capabilities. This will allow clients to determine if new features have been installed and, if not, fall back on earlier features or disable some client capabilities.
このプロトコルは、標準ベースの登録メカニズムを介して拡張できるように設計されています（セクション10を参照）。他の有用なタイムゾーンアクションが将来追加されることが予想されます（たとえば、地理的な場所をタイムゾーン識別子にマッピングし、タイムゾーンの変更履歴を取得する）。したがって、サーバーはその機能の説明を返す必要があります。これにより、クライアントは新しい機能がインストールされているかどうかを判断でき、インストールされていない場合は、以前の機能にフォールバックするか、一部のクライアント機能を無効にします。
Client implementations need to either know where the time zone data distribution service is located or discover it through some mechanism. To use a time zone data distribution service, a client needs a Fully Qualified Domain Name (FQDN), port, and HTTP request-URI path. The request-URI path found via discovery is the "context path" for the service itself. The "context path" is used as the value of the "service-prefix" URI template variable when executing actions (see Section 5).
クライアントの実装では、タイムゾーンデータ配布サービスがどこにあるかを知るか、何らかのメカニズムを通じてそれを発見する必要があります。タイムゾーンデータ配布サービスを使用するには、クライアントに完全修飾ドメイン名（FQDN）、ポート、およびHTTP要求URIパスが必要です。検出によって検出されたリクエストURIパスは、サービス自体の「コンテキストパス」です。 「コンテキストパス」は、アクションの実行時に「service-prefix」URIテンプレート変数の値として使用されます（セクション5を参照）。
The following subsections describe two methods of service discovery using DNS SRV records [RFC2782] and an HTTP "well-known" [RFC5785] resource. However, alternative mechanisms could also be used (e.g., a DHCP server option [RFC2131]).
以下のサブセクションでは、DNS SRVレコード[RFC2782]とHTTP "既知の" [RFC5785]リソースを使用した2つのサービス検出方法について説明します。ただし、別のメカニズムを使用することもできます（DHCPサーバーオプション[RFC2131]など）。
[RFC2782] defines a DNS-based service discovery protocol that has been widely adopted as a means of locating particular services within a local area network and beyond, using SRV RR records. This can be used to discover a service's FQDN and port.
[RFC2782]は、SRV RRレコードを使用して、ローカルエリアネットワーク内およびそれ以降の特定のサービスを検索する手段として広く採用されているDNSベースのサービス検出プロトコルを定義しています。これは、サービスのFQDNとポートを検出するために使用できます。
This specification adds two service types for use with SRV records:
この仕様は、SRVレコードで使用する2つのサービスタイプを追加します。
timezone: Identifies a time zone data distribution server that uses HTTP without Transport Layer Security ([RFC2818]).
timezone：Transport Layer Security（[RFC2818]）なしでHTTPを使用するタイムゾーンデータ配布サーバーを識別します。
timezones: Identifies a time zone data distribution server that uses HTTP with Transport Layer Security ([RFC2818]).
timezones：HTTPとトランスポート層セキュリティ（[RFC2818]）を使用するタイムゾーンデータ配布サーバーを識別します。
Clients MUST honor "TTL", "Priority", and "Weight" values in the SRV records, as described by [RFC2782].
[RFC2782]で説明されているように、クライアントはSRVレコードの「TTL」、「優先度」、および「重み」の値を尊重する必要があります。
Example: service record for server without Transport Layer Security.
例：Transport Layer Securityのないサーバーのサービスレコード。
_timezone._tcp SRV 0 1 80 tz.example.com.
_timezone._tcp SRV 0 1 80 tz.example.com。
Example: service record for server with transport layer security.
例：トランスポート層セキュリティを備えたサーバーのサービスレコード。
_timezones._tcp SRV 0 1 443 tz.example.com.
_timezones._tcp SRV 0 1 443 tz.example.com。
When SRV RRs are used to advertise a time zone data distribution service, it is also convenient to be able to specify a "context path" in the DNS to be retrieved at the same time. To enable that, this specification uses a TXT RR that follows the syntax defined in Section 6 of [RFC6763] and defines a "path" key for use in that record. The value of the key MUST be the actual "context path" to the corresponding service on the server.
SRV RRを使用してタイムゾーンデータ配布サービスをアドバタイズする場合、同時に取得するDNSの「コンテキストパス」を指定できると便利です。これを可能にするために、この仕様では[RFC6763]のセクション6で定義された構文に従い、そのレコードで使用する「パス」キーを定義するTXT RRを使用します。キーの値は、サーバー上の対応するサービスへの実際の「コンテキストパス」でなければなりません。
A site might provide TXT records in addition to SRV records for each service. When present, clients MUST use the "path" value as the "context path" for the service in HTTP requests. When not present, clients use the ".well-known" URI approach described in Section 4.2.1.3.
サイトは、各サービスのSRVレコードに加えてTXTレコードを提供する場合があります。存在する場合、クライアントはHTTPリクエストでサービスの「コンテキストパス」として「パス」値を使用する必要があります。存在しない場合、クライアントはセクション4.2.1.3で説明されている「.well-known」URIアプローチを使用します。
As per Section 8, the server MAY require authentication when a client tries to access the path URI specified by the TXT RR (i.e., the server would return a 401 status response to the unauthenticated request from the client, then return a redirect response after a successful authentication by the client).
セクション8のとおり、クライアントがTXT RRで指定されたパスURIにアクセスしようとすると、サーバーは認証を要求する場合があります（つまり、サーバーはクライアントからの非認証リクエストに対して401ステータス応答を返し、その後、リダイレクト応答を返します。クライアントによる認証の成功）。
Example: text record for service with Transport Layer Security.
例：Transport Layer Securityを使用したサービスのテキストレコード。
_timezones._tcp TXT path=/timezones
_timezones._tcp TXT path = / timezones
A "well-known" URI [RFC5785] is registered by this specification for the Time Zone Data Distribution service, "timezone" (see Section 10). This URI points to a resource that the client can use as the initial "context path" for the service they are trying to connect to. The server MUST redirect HTTP requests for that resource to the actual "context path" using one of the available mechanisms provided by HTTP (e.g., using an appropriate 3xx status response). Clients MUST handle HTTP redirects on the ".well-known" URI, taking into account security restrictions on redirects described in Section 8. Servers MUST NOT locate the actual time zone data distribution service endpoint at the ".well-known" URI as per Section 1.1 of [RFC5785]. The "well-known" URI MUST be present on the server, even when a TXT RR (Section 4.2.1.2) is used in the DNS to specify a "context path".
「よく知られている」URI [RFC5785]は、タイムゾーンデータ配布サービス「timezone」のこの仕様で登録されています（セクション10を参照）。このURIは、クライアントが接続しようとしているサービスの初期「コンテキストパス」としてクライアントが使用できるリソースを指します。サーバーは、HTTPによって提供される利用可能なメカニズムの1つを使用して（たとえば、適切な3xxステータス応答を使用して）、そのリソースのHTTPリクエストを実際の「コンテキストパス」にリダイレクトする必要があります。クライアントは、セクション8で説明されているリダイレクトのセキュリティ制限を考慮して、「。well-known」URIでHTTPリダイレクトを処理する必要があります。サーバーは、「。well-known」URIで実際のタイムゾーンデータ配信サービスエンドポイントを見つけてはなりません（MUST NOT） [RFC5785]のセクション1.1。 DNSで「コンテキストパス」を指定するためにTXT RR（セクション4.2.1.2）が使用されている場合でも、「既知の」URIはサーバー上に存在している必要があります。
Servers SHOULD set an appropriate Cache-Control header field value (as per Section 5.2 of [RFC7234]) in the redirect response to ensure caching occurs as needed, or as required by the type of response generated. For example, if it is anticipated that the location of the redirect might change over time, then an appropriate "max-age" value would be used.
サーバーは、リダイレクト応答に適切なCache-Controlヘッダーフィールド値（[RFC7234]のセクション5.2に従って）を設定して、必要に応じて、または生成された応答のタイプで必要に応じてキャッシュが行われるようにする必要があります（SHOULD）。たとえば、リダイレクトの場所が時間とともに変化することが予想される場合は、適切な「max-age」値が使用されます。
As per Section 8, the server MAY require authentication when a client tries to access the ".well-known" URI (i.e., the server would return a 401 status response to the unauthenticated request from the client, then return the redirect response after a successful authentication by the client).
セクション8のとおり、クライアントが「.well-known」URIにアクセスしようとすると、サーバーは認証を要求する場合があります（つまり、サーバーはクライアントからの非認証リクエストに対して401ステータス応答を返し、その後、リダイレクト応答を返します。クライアントによる認証の成功）。
A time zone data distribution server has a "context path" that is "/servlet/timezone". The client will use "/.well-known/timezone" as the path for the service after it has first found the FQDN and port number via an SRV lookup or via manual entry of information by the user. When the client makes its initial HTTP request against "/.well-known/timezone", the server would issue an HTTP 301 redirect response with a Location response header field using the path "/servlet/timezone". The client would then "follow" this redirect to the new resource and continue making HTTP requests there. The client would also cache the redirect information, subject to any Cache-Control directive, for use in subsequent requests.
タイムゾーンデータ配布サーバーには、「/ servlet / timezone」という「コンテキストパス」があります。クライアントは、SRVルックアップまたはユーザーによる情報の手動入力によってFQDNおよびポート番号を最初に見つけた後、サービスのパスとして「/.well-known/timezone」を使用します。クライアントが "/.well-known/timezone"に対して最初のHTTP要求を行うと、サーバーはパス "/ servlet / timezone"を使用して、場所応答ヘッダーフィールドを含むHTTP 301リダイレクト応答を発行します。次に、クライアントはこのリダイレクトを新しいリソースに「フォロー」し、そこでHTTPリクエストを続けます。クライアントは、後続のリクエストで使用するために、任意のCache-Controlディレクティブに従って、リダイレクト情報をキャッシュします。
This section discusses possible client synchronization strategies using the various protocol elements provided by the server for that purpose.
このセクションでは、その目的のためにサーバーが提供するさまざまなプロトコル要素を使用した、可能なクライアント同期戦略について説明します。
When a secondary service or a client wishing to cache all time zone data first starts, or wishes to do a full refresh, it synchronizes with another server by issuing a "list" action to retrieve all the time zone metadata. The client preserves the returned opaque token for subsequent use (see "synctoken" in Section 5.2.1). The client stores the metadata for each time zone returned in the response. Time zone data for each corresponding time zone can then be fetched and stored locally. In addition, a mapping of aliases to time zones can be built from the metadata. A typical "list" action response size is about 50-100 KB of "pretty printed" JSON data, for a service using the IANA time zone database [RFC6557], as of the time of publication of this specification.
すべてのタイムゾーンデータをキャッシュしたいセカンダリサービスまたはクライアントが最初に起動するか、フルリフレッシュを実行する場合、「リスト」アクションを発行して別のサーバーと同期し、すべてのタイムゾーンメタデータを取得します。クライアントは、後で使用するために返された不透明トークンを保持します（5.2.1項の「synctoken」を参照）。クライアントは、応答で返された各タイムゾーンのメタデータを保存します。次に、対応する各タイムゾーンのタイムゾーンデータをフェッチしてローカルに保存できます。さらに、メタデータからエイリアスのタイムゾーンへのマッピングを作成できます。この仕様の公開時点では、IANAタイムゾーンデータベース[RFC6557]を使用するサービスの典型的な「リスト」アクションレスポンスサイズは、「かなり印刷された」JSONデータの約50〜100 KBです。
A secondary service or a client caching all time zones needs to periodically synchronize with a server. To do so, it issues a "list" action with the "changedsince" URI query parameter set to the value of the opaque token returned by the last synchronization. The client again preserves the returned opaque token for subsequent use. The client updates its stored time zone metadata using the new values returned in the response, which contains just the time zone metadata for those time zones changed since the last synchronization. In addition, it compares the "etag" value in each time zone metadata to the ETag header field value for the corresponding time zone data resource it has previously cached; if they are different, it fetches the new time zone data. Note that if the client presents the server with a "changedsince" value that the server does not support, all time zone data is returned, as it would for the case where the request did not include a "changedsince" value.
すべてのタイムゾーンをキャッシュするセカンダリサービスまたはクライアントは、定期的にサーバーと同期する必要があります。これを行うには、最後の同期で返された不透明トークンの値に設定された「changedsince」URIクエリパラメータを使用して「リスト」アクションを発行します。クライアントは、返された不透明トークンをその後の使用のために再び保持します。クライアントは、応答で返された新しい値を使用して、保存されているタイムゾーンメタデータを更新します。これには、最後の同期以降に変更されたタイムゾーンのタイムゾーンメタデータのみが含まれます。さらに、各タイムゾーンメタデータの「etag」値を、以前にキャッシュした対応するタイムゾーンデータリソースのETagヘッダーフィールド値と比較します。異なる場合は、新しいタイムゾーンデータをフェッチします。クライアントがサーバーにサポートしていない "changedsince"値をサーバーに提示すると、要求に "changedsince"値が含まれていない場合と同様に、すべてのタイムゾーンデータが返されることに注意してください。
Publishers should take into account the fact that the "outright" deletion of time zone names will cause problems to simple clients, and so aliasing a deleted time zone identifier to a suitable alternate one is preferable.
パブリッシャーは、タイムゾーン名の「完全な」削除が単純なクライアントに問題を引き起こすという事実を考慮に入れる必要があるため、削除されたタイムゾーン識別子に適切な代替のエイリアスを付けることをお勧めします。
A client might be pre-provisioned with time zone data from a source other than the time zone data distribution service it is configured to use. In such cases, the client might want to minimize the amount of time zone data it synchronizes by doing an initial "list" action to retrieve all the time zone metadata, but then only fetch time zone data for those time zones that do not match the publisher and version details for the pre-provisioned data.
クライアントには、使用するように構成されているタイムゾーンデータ配布サービス以外のソースからのタイムゾーンデータが事前にプロビジョニングされている場合があります。このような場合、クライアントは、最初の「リスト」アクションを実行してすべてのタイムゾーンメタデータを取得し、次に一致しないタイムゾーンのタイムゾーンデータのみをフェッチすることで、同期するタイムゾーンデータの量を最小限に抑えたい場合があります。事前にプロビジョニングされたデータの発行元とバージョンの詳細。
Servers MUST support the following actions. The information below shows details about each action: the request-URI the client targets (in the form of a URI template [RFC6570]), a description, the set of allowed query parameters, the nature of the response, and a set of possible error codes for the response (see Section 4.1.7).
サーバーは、次のアクションをサポートする必要があります。以下の情報は、各アクションの詳細を示しています：クライアントがターゲットとするリクエストURI（URIテンプレート[RFC6570]の形式）、説明、許可されたクエリパラメーターのセット、応答の性質、および可能なセット応答のエラーコード（セクション4.1.7を参照）。
For any error not covered by the specific error codes defined below, the "urn:ietf:params:tzdist:error:invalid-action" error code is returned to the client in the JSON "problem details" object.
以下に定義されている特定のエラーコードでカバーされていないエラーの場合、「urn：ietf：params：tzdist：error：invalid-action」エラーコードがJSON「問題の詳細」オブジェクトでクライアントに返されます。
The examples in the following subsections presume that the timezone context path has been discovered to be "/servlet/timezone" (as in the example in Section 4.2.1.3.1).
以下のサブセクションの例では、タイムゾーンコンテキストパスが「/ servlet / timezone」であることが検出されていることを前提としています（セクション4.2.1.3.1の例と同様）。
Name: capabilities
名前：機能
Request-URI Template:
{/service-prefix}/capabilities
Description: This action returns the capabilities of the server, allowing clients to determine if a specific feature has been deployed and/or enabled.
説明：このアクションはサーバーの機能を返し、クライアントは特定の機能が展開または有効化されているかどうかを判別できます。
Parameters: None Response: A JSON object containing a "version" member, an "info" member, and an "actions" member; see Section 6.1.
パラメーター：なし応答：「バージョン」メンバー、「情報」メンバー、および「アクション」メンバーを含むJSONオブジェクト。セクション6.1を参照してください。
Possible Error Codes: No specific code.
考えられるエラーコード：特定のコードはありません。
>> Request <<
GET /servlet/timezone/capabilities HTTP/1.1
Host: tz.example.com
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
{ "version": 1,
{"バージョン"：1、
"info": {
"primary-source": "Olson:2011m",
"formats": [
"text/calendar",
"application/calendar+xml",
"application/calendar+json"
],
"truncated" : {
"any": false,
"ranges": [
{
"start": "1970-01-01T00:00:00Z",
"end": "*"
},
{
"start":"2010-01-01T00:00:00Z",
"end":"2020-01-01T00:00:00Z"
}
],
"untruncated": true
},
"provider-details": "http://tz.example.com/about.html",
"contacts": ["mailto:tzs@example.org"]
},
"actions": [
{
"name": "capabilities",
"uri-template": "/servlet/timezone/capabilities",
"parameters": []
},
{
"name": "list",
"uri-template": "/servlet/timezone/zones{?changedsince}",
"parameters": [
{
"name": "changedsince",
"required": false,
"multi": false
}
]
},
{
"name": "get",
"uri-template": "/servlet/timezone/zones{/tzid}{?start,end}",
"parameters": [
{
"name": "start",
"required": false,
"multi": false
},
{
"name": "end",
"required": false,
"multi": false
}
]
},
{
"name": "expand",
"uri-template":
"/servlet/timezone/zones{/tzid}/observances{?start,end}",
"parameters": [
{
"name": "start",
"required": true,
"multi": false
},
{
"name": "end",
"required": true,
"multi": false
}
]
},
{
"name": "find",
"uri-template": "/servlet/timezone/zones{?pattern}",
"parameters": [
{
"name": "pattern",
"required": true,
"multi": false
}
]
},
{
"name": "leapseconds",
"uri-template": "/servlet/timezone/leapseconds",
"parameters": []
}
]
}
Name: list
名前：リスト
Request-URI Template:
{/service-prefix,data-prefix}/zones{?changedsince}
Description: This action lists all time zone identifiers in summary format, with publisher, version, aliases, and optional localized data. In addition, it returns an opaque synchronization token for the entire response. If the "changedsince" URI query parameter is present, its value MUST correspond to a previously returned synchronization token value. When "changedsince" is used, the server MUST return only those time zones that have changed since the specified synchronization token. If the "changedsince" value is not supported by the server, the server MUST return all time zones, treating the request as if it had no "changedsince".
説明：このアクションは、すべてのタイムゾーン識別子を、発行者、バージョン、エイリアス、およびオプションのローカライズされたデータとともに、要約形式でリストします。さらに、応答全体に対して不透明な同期トークンを返します。 「changedsince」URIクエリパラメータが存在する場合、その値は以前に返された同期トークン値に対応している必要があります。 「changedsince」を使用する場合、サーバーは、指定された同期トークン以降に変更されたタイムゾーンのみを返す必要があります。 「changedsince」値がサーバーでサポートされていない場合、サーバーはすべてのタイムゾーンを返さなければならず、「changedsince」がないかのようにリクエストを処理します。
Parameters:
パラメーター：
changedsince OPTIONAL, and MUST NOT occur more than once.
OPTIONAL以降変更され、2回以上発生してはならない（MUST NOT）。
Response: A JSON object containing a "synctoken" member and a "timezones" member; see Section 6.2.
応答：「synctoken」メンバーと「timezones」メンバーを含むJSONオブジェクト。セクション6.2を参照してください。
Possible Error Codes:
考えられるエラーコード：
urn:ietf:params:tzdist:error:invalid-changedsince
The "changedsince" URI query parameter appears more than once.
「changedsince」URIクエリパラメータが複数回表示されます。
In this example the client requests the full set of time zone identifiers.
この例では、クライアントはタイムゾーン識別子の完全なセットを要求します。
>> Request <<
GET /servlet/timezone/zones HTTP/1.1
Host: tz.example.com
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
{
"synctoken": "2009-10-11T09:32:11Z",
"timezones": [
{
"tzid": "America/New_York",
"etag": "123456789-000-111",
"last-modified": "2009-09-17T01:39:34Z",
"publisher": "Example.com",
"version": "2015a",
"aliases":["US/Eastern"],
"local-names": [
{
"name": "America/New_York",
"lang": "en_US"
}
]
},
...other time zones...
]
}
Name: get
名前：get
Request-URI Template:
{/service-prefix,data-prefix}/zones{/tzid}{?start,end}
The "tzid" variable value is REQUIRED in order to distinguish this action from the "list" action.
このアクションを「リスト」アクションと区別するために、「tzid」変数値が必要です。
Description: This action returns a time zone. The response MUST contain an ETag response header field indicating the current value of the strong entity tag of the time zone resource.
説明：このアクションはタイムゾーンを返します。応答には、タイムゾーンリソースの強力なエンティティタグの現在の値を示すETag応答ヘッダーフィールドを含める必要があります。
In the absence of any Accept HTTP request header field, the server MUST return time zone data with the "text/calendar" media type.
Accept HTTPリクエストヘッダーフィールドがない場合、サーバーは「text / calendar」メディアタイプのタイムゾーンデータを返す必要があります。
If the "tzid" variable value is actually a time zone alias, the server will return the matching time zone data with the alias as the identifier in the time zone data. The server MAY include one or more "TZID-ALIAS-OF" properties (see Section 7.2) in the time zone data to indicate additional identifiers that have the matching time zone identifier as an alias.
"tzid"変数の値が実際にはタイムゾーンエイリアスである場合、サーバーは、タイムゾーンデータ内の識別子としてエイリアスを持つ一致するタイムゾーンデータを返します。サーバーは、タイムゾーンデータに1つ以上の「TZID-ALIAS-OF」プロパティ（セクション7.2を参照）を含めて、一致するタイムゾーン識別子をエイリアスとして持つ追加の識別子を示すことができます（MAY）。
Parameters:
パラメーター：
start=<date-time> OPTIONAL, and MUST NOT occur more than once. Specifies the inclusive UTC date-time value at which the returned time zone data is truncated at its start.
start = <date-time>オプションであり、2回以上発生してはなりません。返されるタイムゾーンデータが開始時に切り捨てられる包括的なUTC日時値を指定します。
end=<date-time> OPTIONAL, and MUST NOT occur more than once. Specifies the exclusive UTC date-time value at which the returned time zone data is truncated at its end.
end = <date-time>オプションであり、2回以上発生してはなりません。返されるタイムゾーンデータの末尾が切り捨てられる、排他的なUTC日時値を指定します。
Response: A document containing all the requested time zone data in the format specified.
応答：要求されたすべてのタイムゾーンデータを指定された形式で含むドキュメント。
Possible Error Codes:
考えられるエラーコード：
urn:ietf:params:tzdist:error:tzid-not-found No time zone associated with the specified "tzid" path segment value was found.
urn：ietf：params：tzdist：error：tzid-not-found指定された「tzid」パスセグメント値に関連付けられたタイムゾーンが見つかりませんでした。
urn:ietf:params:tzdist:error:invalid-format The Accept request header field supplied by the client did not contain a media type for time zone data supported by the server.
urn：ietf：params：tzdist：error：invalid-formatクライアントから提供されたAcceptリクエストヘッダーフィールドに、サーバーでサポートされているタイムゾーンデータのメディアタイプが含まれていませんでした。
urn:ietf:params:tzdist:error:invalid-start The "start" URI query parameter has an incorrect value, or appears more than once, or does not match one of the fixed truncation range start values advertised in the "capabilities" action response.
urn：ietf：params：tzdist：error：invalid-start「start」URIクエリパラメータの値が正しくないか、2回以上表示されるか、「capabilities」アクションでアドバタイズされた固定切り捨て範囲の開始値のいずれとも一致しません応答。
urn:ietf:params:tzdist:error:invalid-end The "end" URI query parameter has an incorrect value, or appears more than once, or has a value less than or equal to the "start" URI query parameter, or does not match one of the fixed truncation range end values advertised in the "capabilities" action response.
urn：ietf：params：tzdist：error：invalid-end「end」URIクエリパラメータの値が正しくないか、複数回表示されているか、「start」URIクエリパラメータ以下の値であるか、 「機能」アクション応答でアドバタイズされた固定の切り捨て範囲の終了値のいずれとも一致しません。
In this example, the client requests that the time zone with a specific time zone identifier be returned.
この例では、クライアントは特定のタイムゾーン識別子を持つタイムゾーンを返すように要求します。
>> Request <<
GET /servlet/timezone/zones/America%2FNew_York HTTP/1.1
Host: tz.example.com
Accept:text/calendar
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
ETag: "123456789-000-111"
BEGIN:VCALENDAR ... BEGIN:VTIMEZONE TZID:America/New_York ... END:VTIMEZONE END:VCALENDAR
BEGIN：VCALENDAR ... BEGIN：VTIMEZONE TZID：America / New_York ... END：VTIMEZONE END：VCALENDAR
In this example the client requests that the time zone with a specific time zone identifier be returned, but uses an If-None-Match header field in the request, set to the value of a previously returned ETag header field, or the value of the "etag" member in a JSON "timezone" object returned from a "list" action response. In this example, the data on the server has not changed, so a 304 response is returned.
この例では、クライアントは特定のタイムゾーン識別子を持つタイムゾーンが返されるように要求しますが、リクエストでIf-None-Matchヘッダーフィールドを使用し、以前に返されたETagヘッダーフィールドの値、または"list"アクション応答から返されたJSON "timezone"オブジェクトの "etag"メンバー。この例では、サーバー上のデータは変更されていないため、304応答が返されます。
>> Request <<
GET /servlet/timezone/zones/America%2FNew_York HTTP/1.1
Host: tz.example.com
Accept:text/calendar
If-None-Match: "123456789-000-111"
>> Response <<
HTTP/1.1 304 Not Modified
Date: Wed, 4 Jun 2008 09:32:12 GMT
In this example, the client requests that the time zone with an aliased time zone identifier be returned, and the server returns the time zone data with that identifier and two aliases.
この例では、クライアントはエイリアスされたタイムゾーン識別子を持つタイムゾーンを返すように要求し、サーバーはその識別子と2つのエイリアスを持つタイムゾーンデータを返します。
>> Request <<
GET /servlet/timezone/zones/US%2FEastern HTTP/1.1
Host: tz.example.com
Accept:text/calendar
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
ETag: "123456789-000-111"
BEGIN:VCALENDAR
...
BEGIN:VTIMEZONE
TZID:US/Eastern
TZID-ALIAS-OF:America/New_York
TZID-ALIAS-OF:America/Montreal
... END:VTIMEZONE END:VCALENDAR
... END：VTIMEZONE END：VCALENDAR
Assume the server advertises a "truncated" object in its "capabilities" response that appears as:
サーバーが「機能」応答で「切り捨てられた」オブジェクトを次のようにアドバタイズするとします。
"truncated": {
"any": false,
"ranges": [
{"start": "1970-01-01T00:00:00Z", "end": "*"},
{"start":"2010-01-01T00:00:00Z", "end":"2020-01-01T00:00:00Z"}
],
"untruncated": false
}
In this example, the client requests that the time zone with a specific time zone identifier truncated at one of the ranges specified by the server be returned. Note the presence of a "STANDARD" component that matches the start point of the truncation range (converted to the local time for the UTC offset in effect at the matching UTC time). Also, note the presence of the "TZUNTIL" (Section 7.1) iCalendar property in the "VTIMEZONE" component, indicating the upper bound on the validity period of the time zone data.
この例では、クライアントは、サーバーによって指定された範囲の1つで切り捨てられた特定のタイムゾーン識別子を持つタイムゾーンを返すように要求します。切り捨て範囲の開始点と一致する「STANDARD」コンポーネントの存在に注意してください（一致するUTC時間で有効なUTCオフセットの現地時間に変換されます）。また、「VTIMEZONE」コンポーネントに「TZUNTIL」（7.1節）iCalendarプロパティが存在することに注意してください。これは、タイムゾーンデータの有効期間の上限を示します。
>> Request <<
GET /servlet/timezone/zones/America%2FNew_York
?start=2010-01-01T00:00:00Z&end=2020-01-01T00:00:00Z HTTP/1.1
Host: tz.example.com
Accept:text/calendar
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
ETag: "123456789-000-111"
BEGIN:VCALENDAR ... BEGIN:VTIMEZONE TZID:America/New_York TZUNTIL:20200101T000000Z BEGIN:STANDARD DTSTART:20101231T190000 TZNAME:EST TZOFFSETFROM:-0500 TZOFFSETTO:-0500 END:STANDARD ... END:VTIMEZONE END:VCALENDAR
BEGIN：VCALENDAR ... BEGIN：VTIMEZONE TZID：America / New_York TZUNTIL：20200101T000000Z BEGIN：STANDARD DTSTART：20101231T190000 TZNAME：EST TZOFFSETFROM：-0500 TZOFFSETTO：-0500 END：STANDARD ... END：VTIMEZAR END：VCALEND
In this example, the client requests that the time zone with a specific time zone identifier be returned. As it turns out, no time zone exists with that identifier.
この例では、クライアントは特定のタイムゾーン識別子を持つタイムゾーンを返すように要求します。結局のところ、その識別子を持つタイムゾーンは存在しません。
>> Request <<
GET /servlet/timezone/zones/America%2FPittsburgh HTTP/1.1
Host: tz.example.com
Accept:application/calendar+json
>> Response <<
HTTP/1.1 404 Not Found
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/problem+json; charset="utf-8"
Content-Language: en
Content-Length: xxxx
{
"type": "urn:ietf:params:tzdist:error:tzid-not-found",
"title": "Time zone identifier was not found on this server",
"status": 404
}
Name: expand
名前：展開
Request-URI Template:
{/service-prefix,data-prefix}/zones{/tzid}/observances{?start,end}
The "tzid" variable value is REQUIRED.
「tzid」変数値は必須です。
Description: This action expands the specified time zone into a list of onset start date/time values (in UTC) and UTC offsets. The response MUST contain an ETag response header field indicating the current value of the strong entity tag of the time zone being expanded.
説明：このアクションは、指定されたタイムゾーンを、開始開始日時の値（UTC）およびUTCオフセットのリストに拡張します。応答には、拡張されるタイムゾーンの強力なエンティティタグの現在の値を示すETag応答ヘッダーフィールドを含める必要があります。
Parameters:
パラメーター：
start=<date-time>: REQUIRED, and MUST occur only once. Specifies the inclusive UTC date-time value for the start of the period of interest.
start = <date-time>：必須であり、1回だけ発生する必要があります。対象期間の開始の包括的なUTC日時値を指定します。
end=<date-time>: REQUIRED, and MUST occur only once. Specifies the exclusive UTC date-time value for the end of the period of interest. Note that this is the exclusive end value, i.e., it represents the date just after the range of interest. For if a client wants the expanded date just for the year 2014, it would use a start value of "2014-01-01T00:00:00Z" and an end value of "2015-01-01T00:00:00Z". An error occurs if the end value is less than or equal to the start value.
end = <date-time>：必須であり、1回だけ発生する必要があります。対象となる期間の終了の排他的なUTC日時値を指定します。これは排他的な終了値であることに注意してください。つまり、対象範囲の直後の日付を表します。クライアントが2014年のみの拡張日付を必要とする場合、開始値「2014-01-01T00：00：00Z」と終了値「2015-01-01T00：00：00Z」を使用します。終了値が開始値以下の場合、エラーが発生します。
Response: A JSON object containing a "tzid" member and an "observances" member; see Section 6.3. If the time zone being expanded is not fully defined over the requested time range (e.g., because of truncation), then the server MUST include "start" and/ or "end" members in the JSON response to indicate the actual start and end points for the observances being returned. The server MUST include an expanded observance representing the time zone information in effect at the start of the returned observance period.
応答：「tzid」メンバーと「observances」メンバーを含むJSONオブジェクト。セクション6.3を参照してください。展開されるタイムゾーンが要求された時間範囲で完全に定義されていない場合（切り捨てなどのため）、サーバーは実際の開始点と終了点を示すためにJSON応答に「開始」および/または「終了」メンバーを含める必要があります返還された儀式のため。サーバーは、返された遵守期間の開始時に有効なタイムゾーン情報を表す拡張された遵守を含まなければなりません（MUST）。
Possible Error Codes
考えられるエラーコード
urn:ietf:params:tzdist:error:tzid-not-found No time zone associated with the specified "tzid" path segment value was found.
urn：ietf：params：tzdist：error：tzid-not-found指定された「tzid」パスセグメント値に関連付けられたタイムゾーンが見つかりませんでした。
urn:ietf:params:tzdist:error:invalid-start The "start" URI query parameter has an incorrect value, or appears more than once, or is missing, or has a value outside any fixed truncation ranges advertised in the "capabilities" action response.
urn：ietf：params：tzdist：error：invalid-start「start」URIクエリパラメータの値が正しくないか、複数回表示されているか、見つからないか、「capabilities」でアドバタイズされた固定切り捨て範囲外の値を持っていますアクション応答。
urn:ietf:params:tzdist:error:invalid-end The "end" URI query parameter has an incorrect value, or appears more than once, or has a value less than or equal to the "start" URI query parameter, or has a value outside any fixed truncation ranges advertised in the "capabilities" action response.
urn：ietf：params：tzdist：error：invalid-end「end」URIクエリパラメータの値が正しくないか、複数回表示されているか、「start」URIクエリパラメータ以下の値であるか、 「機能」アクションレスポンスでアドバタイズされる固定の切り捨て範囲外の値。
In this example, the client requests a time zone in the expanded form.
この例では、クライアントは展開された形式でタイムゾーンを要求します。
>> Request <<
GET /servlet/timezone/zones/America%2FNew_York/observances
?start=2008-01-01T00:00:00Z&end=2009-01-01T00:00:00Z HTTP/1.1
Host: tz.example.com
>> Response <<
HTTP/1.1 200 OK
Date: Mon, 11 Oct 2009 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
ETag: "123456789-000-111"
{
"tzid": "America/New_York",
"observances": [
{
"name": "Standard",
"onset": "2008-01-01T00:00:00Z",
"utc-offset-from": -18000,
"utc-offset-to": -18000
},
{
"name": "Daylight",
"onset": "2008-03-09T07:00:00Z",
"utc-offset-from": -18000,
"utc-offset-to": -14400
},
{
"name": "Standard",
"onset": "2008-11-02T06:00:00Z",
"utc-offset-from": -14400,
"utc-offset-to": -18000
},
]
}
Name: find
名前：検索
Request-URI Template:
{/service-prefix,data-prefix}/zones{?pattern}
Description: This action allows a client to query the time zone data distribution service for a matching identifier, alias, or localized name, using a simple "glob" style patter match against the names known to the server (with an asterisk (*) as the wildcard character). Pattern-match strings (which have to be percent-encoded and then decoded when used in the URI query parameter) have the following options:
説明：このアクションにより、クライアントは、サーバーに既知の名前（アスタリスク（*）ワイルドカード文字）。パターン一致文字列（パーセントエンコードしてからURIクエリパラメーターで使用する場合はデコードする必要があります）には、次のオプションがあります。
* not present: An exact text match is done, e.g., "xyz"
* 存在しない：完全に一致するテキストが実行されます（例： "xyz"）
* first character only: An ends-with text match is done, e.g., "*xyz"
* 最初の文字のみ：「* xyz」などのテキストの末尾での一致が行われます
* last character only: A starts-with text match is done, e.g., "xyz*"
* 最後の文字のみ：「xyz *」など、テキストの先頭が一致している
* first and last characters only: A substring text match is done, e.g., "*xyz*"
* 最初と最後の文字のみ：部分文字列のテキスト一致が行われます（例： "* xyz *"）
Escaping \ and *: To match 0x2A ("*") and 0x5C ("\") characters in a time zone identifier, those characters have to be "escaped" in the pattern by prepending a single 0x5C ("\") character. For example, a pattern "\*Test\\Time\*Zone\*" is used for an exact match against the time zone identifier "*Test\Time*Zone*". An unescaped "*" character MUST NOT appear in the middle of the string and MUST result in an error. An unescaped "\" character MUST NOT appear anywhere in the string and MUST result in an error.
\と*のエスケープ：タイムゾーン識別子の0x2A（ "*"）および0x5C（ "\"）文字に一致させるには、これらの文字を1つの0x5C（ "\"）文字を先頭に追加して、パターンで "エスケープ"する必要があります。たとえば、パターン「\ * Test \\ Time \ * Zone \ *」は、タイムゾーン識別子「* Test \ Time * Zone *」との完全一致に使用されます。エスケープされていない「*」文字は、文字列の途中に表示してはならず、エラーになる必要があります。エスケープされていない「\」文字は、文字列のどこにも出現してはならず、エラーになる必要があります。
In addition, when matching:
さらに、一致する場合：
Underscores: Underscore characters (0x5F) in time zone identifiers MUST be mapped to a single space character (0x20) prior to string comparison in both the pattern and time zone identifiers being matched. This allows time zone identifiers such as "America/New_York" to match a query for "*New York*".
アンダースコア：タイムゾーン識別子のアンダースコア文字（0x5F）は、パターンとタイムゾーン識別子の両方で文字列を比較する前に、単一のスペース文字（0x20）にマップする必要があります。これにより、「America / New_York」などのタイムゾーン識別子が「* New York *」のクエリと一致するようになります。
Case mapping: ASCII characters in the range 0x41 ("A") through 0x5A ("Z") MUST be mapped to their lowercase equivalents in both the pattern and time zone identifiers being matched.
大文字と小文字のマッピング：0x41（ "A"）から0x5A（ "Z"）の範囲のASCII文字は、一致するパターンとタイムゾーン識別子の両方の対応する小文字にマッピングする必要があります。
Parameters:
パラメーター：
pattern=<text> REQUIRED, and MUST occur only once.
pattern = <text>必須であり、1回だけ発生する必要があります。
Response: The response has the same format as the "list" action, with one result object per successful match; see Section 6.2.
応答：応答は「リスト」アクションと同じ形式で、一致が成功するたびに1つの結果オブジェクトが返されます。セクション6.2を参照してください。
Possible Error Codes
考えられるエラーコード
urn:ietf:params:tzdist:error:invalid-pattern The "pattern" URI query parameter has an incorrect value or appears more than once.
urn：ietf：params：tzdist：error：invalid-pattern「パターン」URIクエリパラメータの値が正しくないか、複数回表示されています。
In this example, the client asks for data about the time zone "US/Eastern".
この例では、クライアントはタイムゾーン「US / Eastern」に関するデータを要求します。
>> Request <<
GET /servlet/timezone/zones?pattern=US/Eastern HTTP/1.1
Host: tz.example.com
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
{
"synctoken": "2009-10-11T09:32:11Z",
"timezones": [
{
"tzid": "America/New_York",
"etag": "123456789-000-111",
"last-modified": "2009-09-17T01:39:34Z",
"publisher": "Example.com",
"version": "2015a",
"aliases":["US/Eastern"],
"local-names": [
{
"name": "America/New_York",
"lang": "en_US"
}
]
},
{
"tzid": "America/Detroit",
"etag": "123456789-999-222",
"last-modified": "2009-09-17T01:39:34Z",
"publisher": "Example.com",
"version": "2015a",
"aliases":["US/Eastern"],
"local-names": [
{
"name": "America/Detroit",
"lang": "en_US"
}
]
},
...
]
}
Name: leapseconds
名前：うるう秒
Request-URI Template:
{/service-prefix,data-prefix}/leapseconds
Description: This action allows a client to query the time zone data distribution service to retrieve the current leap-second information available on the server.
説明：このアクションにより、クライアントはタイムゾーンデータ配布サービスにクエリを実行し、サーバーで利用可能な現在のうるう秒情報を取得できます。
Parameters: None
パラメータ：なし
Response: A JSON object containing an "expires" member, a "publisher" member, a "version" member, and a "leapseconds" member; see Section 6.4. The "expires" member in the JSON response indicates the latest date covered by leap-second information. For example (as in Section 5.6.1), if the "expires" value is set to "2014-06-28" and the latest leap-second change indicated was at "2012-07-01", then the data indicates that there are no leap seconds added (or removed) between those two dates, and information for leap seconds beyond the "expires" date is not yet available.
応答：「expires」メンバー、「publisher」メンバー、「version」メンバー、および「leapseconds」メンバーを含むJSONオブジェクト。セクション6.4を参照してください。 JSON応答の「expires」メンバーは、うるう秒情報でカバーされる最新の日付を示します。たとえば（5.6.1項のように）、「expires」の値が「2014-06-28」に設定され、示されている最新のうるう秒の変更が「2012-07-01」であった場合、データは次のことを示します。これら2つの日付の間に追加（または削除）されたうるう秒はなく、「有効期限」日を超えるうるう秒の情報はまだ利用できません。
The "leapseconds" member contains a list of JSON objects each of which contains a "utc-offset" and "onset" member. The "onset" member specifies the date (with the implied time of 00:00:00 UTC) at which the corresponding UTC offset from TAI takes effect. In other words, a leap second is added or removed just prior to time 00:00:00 UTC of the specified onset date. When a leap second is added, the "utc-offset" value will be incremented by one; when a leap second is removed, the "utc-offset" value will be decremented by one.
「leapseconds」メンバーには、それぞれ「utc-offset」および「onset」メンバーを含むJSONオブジェクトのリストが含まれています。 「開始」メンバーは、TAIからの対応するUTCオフセットが有効になる日付（暗黙の時間00:00:00 UTC）を指定します。つまり、うるう秒は、指定された開始日の00:00:00 UTCの直前に追加または削除されます。うるう秒が追加されると、「utc-offset」の値が1つ増えます。うるう秒が削除されると、「utc-offset」の値が1つ減ります。
Possible Error Codes No specific code.
考えられるエラーコード特定のコードはありません。
In this example, the client requests the current leap-second information from the server.
この例では、クライアントはサーバーに現在のうるう秒情報を要求します。
>> Request <<
GET /servlet/timezone/leapseconds HTTP/1.1
Host: tz.example.com
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
{
"expires": "2015-12-28",
"publisher": "Example.com",
"version": "2015d",
"leapseconds": [
{
"utc-offset": 10,
"onset": "1972-01-01",
},
{
"utc-offset": 11,
"onset": "1972-07-01",
},
...
{
"utc-offset": 35,
"onset": "2012-07-01",
},
{
"utc-offset": 36,
"onset": "2015-07-01",
}
]
}
[RFC7159] defines the structure of JSON objects using a set of primitive elements. The structure of JSON objects used by this specification is described by the following set of rules:
[RFC7159]は、一連のプリミティブ要素を使用してJSONオブジェクトの構造を定義します。この仕様で使用されるJSONオブジェクトの構造は、次の一連のルールによって記述されます。
OBJECT represents a JSON object, defined in Section 4 of [RFC7159]. "OBJECT" is followed by a parenthesized list of "MEMBER" rule names. If a member rule name is preceded by a "?" (0x3F) character, that member is optional; otherwise, all members are required. If two or more member rule names are present, each separated from the other by a "|" (0x7C) character, then only one of those members MUST be present in the JSON object. JSON object members are unordered, and thus the order used in the rules is not significant.
OBJECTは、[RFC7159]のセクション4で定義されたJSONオブジェクトを表します。 「OBJECT」の後には、括弧で囲まれた「MEMBER」ルール名のリストが続きます。メンバールール名の前に「？」が付いている場合（0x3F）文字、そのメンバーはオプションです。それ以外の場合は、すべてのメンバーが必要です。 2つ以上のメンバールール名が存在する場合、それぞれが「|」で互いに分離されている（0x7C）文字の場合、これらのメンバーの1つだけがJSONオブジェクトに存在する必要があります。 JSONオブジェクトのメンバーは順序付けされていないため、ルールで使用される順序は重要ではありません。
MEMBER represents a member of a JSON object, defined in Section 4 of [RFC7159]. "MEMBER" is followed by a rule name, the name of the member, a ":", and then the value. A value can be one of "OBJECT", "ARRAY", "NUMBER", "STRING", or "BOOLEAN" rules.
MEMBERは、[RFC7159]のセクション4で定義されているJSONオブジェクトのメンバーを表します。 「MEMBER」の後には、ルール名、メンバーの名前、「：」、そして値が続きます。値は、「OBJECT」、「ARRAY」、「NUMBER」、「STRING」、または「BOOLEAN」ルールのいずれかです。
ARRAY represents a JSON array, defined in Section 5 of [RFC7159]. "ARRAY" is followed by a value (one of "OBJECT", "ARRAY", "NUMBER", "STRING", or "BOOLEAN"), indicating the type of items used in the array.
ARRAYは、[RFC7159]のセクション5で定義されているJSON配列を表します。 「ARRAY」の後には、値（「OBJECT」、「ARRAY」、「NUMBER」、「STRING」、または「BOOLEAN」のいずれか）が続き、配列で使用されるアイテムのタイプを示します。
NUMBER represents a JSON number, defined in Section 6 of [RFC7159].
NUMBERは、[RFC7159]のセクション6で定義されているJSON番号を表します。
STRING represents a JSON string, defined in Section 7 of [RFC7159].
STRINGは、[RFC7159]のセクション7で定義されているJSON文字列を表します。
BOOLEAN represents either of the JSON values "true" or "false", defined in Section 3 of [RFC7159].
BOOLEANは、[RFC7159]のセクション3で定義されているJSON値「true」または「false」のいずれかを表します。
; a line starting with a ";" (0x3B) character is a comment.
; 「;」で始まる行（0x3B）文字はコメントです。
Note, clients MUST ignore any unexpected JSON members in responses from the server.
クライアントは、サーバーからの応答で予期しないJSONメンバーを無視する必要があることに注意してください。
Below are the rules for the JSON document returned for a "capabilities" action request.
以下は、「機能」アクション要求に対して返されるJSONドキュメントのルールです。
; root object OBJECT (version, info, actions)
;ルートオブジェクトOBJECT（バージョン、情報、アクション）
; The version number of the protocol supported - MUST be 1 MEMBER version "version" : NUMBER
;サポートされるプロトコルのバージョン番号-1 MEMBERバージョン "version"でなければなりません：NUMBER
; object containing service information ; Only one of primary_source or secondary_source MUST be present MEMBER info "info" : OBJECT ( primary_source | secondary_source, formats, ?truncated, ?provider_details, ?contacts )
;サービス情報を含むオブジェクト。 primary_sourceまたはsecondary_sourceのいずれか1つだけが存在している必要がありますMEMBER info "info"：OBJECT（primary_source | secondary_source、formats、？truncated、？provider_details、？contacts）
; The source of the time zone data provided by a "primary" server MEMBER primary_source "primary-source" : STRING
; 「プライマリ」サーバーによって提供されるタイムゾーンデータのソースMEMBER primary_source "primary-source"：STRING
; The time zone data server from which data is provided by a ; "secondary" server MEMBER secondary_source "secondary-source" : STRING
;によってデータが提供されるタイムゾーンデータサーバー。 「セカンダリ」サーバーMEMBER secondary_source「secondary-source」：STRING
; Array of one or more media types for the time zone data formats ; that the server can return MEMBER formats "formats" : ARRAY STRING
;タイムゾーンデータ形式の1つ以上のメディアタイプの配列。サーバーがMEMBER形式 "formats"を返すことができること：ARRAY STRING
; Present if the server is providing truncated time zone data. The
; value is an object providing details of the supported truncation
; modes.
MEMBER truncated "truncated" : OBJECT: (
any,
?ranges,
?untruncated
)
; Indicates whether the server can truncate time zone data at any
; start or end point. When set to "true", any start or end point is
; a valid value for use with the "start" and "end" URI query
; parameters in a "get" action request.
MEMBER any "any" : BOOLEAN
; Indicates which ranges of time the server has truncated data for.
; A value from this list may be used with the "start" and "end" URI
; query parameters in a "get" action request. Not present if "any"
; is set to "true".
MEMBER ranges "ranges" : ARRAY OBJECT (range-start, range-end)
; UTC date-time value (per [RFC3339]) for inclusive start of the
; range, or the single character "*" to indicate a value
; corresponding to the lower bound supplied by the publisher of the
; time zone data
MEMBER range-start "start" : STRING
; UTC date-time value (per [RFC3339]) for exclusive end of the range,
; or the single character "*" to indicate a value corresponding to
; the upper bound supplied by the publisher of the time zone data
MEMBER range-end "end" : STRING
; Indicates whether the server can supply untruncated data. When
; set to "true", indicates that, in addition to truncated data being
; available, the server can return untruncated data if a "get"
; action request is executed without a "start" or "end" URI query
; parameter.
MEMBER untruncated "untruncated" : BOOLEAN
; A URI where human-readable details about the time zone service ; is available MEMBER provider_details "provider-details" : STRING
;タイムゾーンサービスに関する人間が読める詳細が含まれるURI。利用可能MEMBER provider_details "provider-details"：STRING
; Array of URIs providing contact details for the server ; administrator MEMBER contacts "contacts" : ARRAY STRING
;サーバーの連絡先の詳細を提供するURIの配列。管理者MEMBERの連絡先「contacts」：配列文字列
; Array of actions supported by the server MEMBER actions "actions" : ARRAY OBJECT ( action_name, action_params )
;サーバーがサポートするアクションの配列MEMBERアクション「アクション」：ARRAY OBJECT（action_name、action_params）
; Name of the action MEMBER action_name: "name" : STRING
;アクションの名前MEMBER action_name： "name"：STRING
; Array of request-URI query parameters supported by the action MEMBER action_params: "parameters" ARRAY OBJECT ( param_name, ?param_required, ?param_multi, ?param_values )
;アクションMEMBER action_paramsでサポートされているリクエストURIクエリパラメーターの配列： "parameters" ARRAY OBJECT（param_name、？param_required、？param_multi、？param_values）
; Name of the parameter MEMBER param_name "name" : STRING
;パラメータの名前MEMBER param_name "name"：STRING
; If true, the parameter has to be present in the request-URI ; default is false MEMBER param_required "required" : BOOLEAN
; trueの場合、パラメーターはrequest-URIに存在する必要があります。デフォルトはfalseです。MEMBER param_required "required"：BOOLEAN
; If true, the parameter can occur more than once in the request-URI ; default is false MEMBER param_multi "multi" : BOOLEAN,
; trueの場合、パラメーターはrequest-URIで複数回出現する可能性があります。デフォルトはfalseです。MEMBER param_multi "multi"：BOOLEAN、
; An array that defines the allowed set of values for the parameter ; In the absence of this member, any string value is acceptable MEMBER param_values "values" ARRAY STRING
;パラメータに許可された値のセットを定義する配列。このメンバーが存在しない場合、任意の文字列値が受け入れ可能ですMEMBER param_values "values" ARRAY STRING
Below are the rules for the JSON document returned for a "list" or "find" action request.
以下は、「リスト」または「検索」アクション要求に対して返されるJSONドキュメントのルールです。
; root object OBJECT (synctoken, timezones)
;ルートオブジェクトOBJECT（synctoken、タイムゾーン）
; Server-generated opaque token used for synchronizing changes MEMBER synctoken "synctoken" : STRING
;変更の同期に使用されるサーバー生成の不透明トークンMEMBER synctoken "synctoken"：STRING
; Array of time zone objects MEMBER timezones "timezones" : ARRAY OBJECT ( tzid, etag, last_modified, publisher, version, ?aliases, ?local_names, )
;タイムゾーンオブジェクトの配列MEMBER timezones "timezones"：ARRAY OBJECT（tzid、etag、last_modified、publisher、version、？aliases、？local_names、）
; Time zone identifier MEMBER tzid "tzid" : STRING
;タイムゾーン識別子MEMBER tzid "tzid"：STRING
; Current ETag for the corresponding time zone data resource MEMBER etag "etag" : STRING
;対応するタイムゾーンデータリソースの現在のETag MEMBER etag "etag"：STRING
; Date/time when the time zone data was last modified ; UTC date-time value as specified in [RFC3339] MEMBER last_modified "last-modified" : STRING
;タイムゾーンデータが最後に変更された日時。 [RFC3339] MEMBER last_modified "last-modified"で指定されているUTC日時値：STRING
; Time zone data publisher MEMBER publisher "publisher" : STRING
;タイムゾーンデータパブリッシャーMEMBERパブリッシャー "publisher"：STRING
; Current version of the time zone data as defined by the ; publisher MEMBER version "version" : STRING
;で定義されているタイムゾーンデータの現在のバージョン。パブリッシャーMEMBERバージョン「バージョン」：STRING
; An array that lists the set of time zone aliases available ; for the corresponding time zone MEMBER aliases "aliases" : ARRAY STRING
;利用可能なタイムゾーンエイリアスのセットをリストする配列。対応するタイムゾーンのMEMBERエイリアス「aliases」：ARRAY STRING
; An array that lists the set of localized names available ; for the corresponding time zone MEMBER local_names "local-names" : ARRAY OBJECT ( lname, lang, ?pref )
;利用可能なローカライズされた名前のセットをリストする配列。対応するタイムゾーンMEMBER local_names "local-names"：ARRAY OBJECT（lname、lang、？pref）
; Language tag for the language of the associated name MEMBER: lang "lang" : STRING
;関連する名前の言語の言語タグMEMBER：lang "lang"：STRING
; Localized name MEMBER lname "name" : STRING
;ローカライズされた名前MEMBER lname "name"：STRING
; Indicates whether this is the preferred name for the associated ; language default: false MEMBER pref "pref" : BOOLEAN
;これが関連するの優先名かどうかを示します。言語のデフォルト：false MEMBER pref "pref"：BOOLEAN
Below are the rules for the JSON document returned for a "expand" action request.
以下は、「展開」アクションリクエストに対して返されるJSONドキュメントのルールです。
; root object OBJECT ( tzid, ?start, ?end, observances )
;ルートオブジェクトOBJECT（tzid、？start、？end、observances）
; Time zone identifier MEMBER tzid "tzid" : STRING
;タイムゾーン識別子MEMBER tzid "tzid"：STRING
; The actual inclusive start point for the returned observances ; if different from the value of the "start" URI query parameter MEMBER start "start" : STRING
;返された遵守の実際の包括的な開始点。 「start」URIクエリパラメータMEMBER start「start」の値と異なる場合：STRING
; The actual exclusive end point for the returned observances ; if different from the value of the "end" URI query parameter MEMBER end "end" : STRING
;返された遵守の実際の排他的なエンドポイント。 「end」URIクエリパラメータMEMBER end「end」の値と異なる場合：STRING
; Array of time zone objects MEMBER observances "observances" : ARRAY OBJECT ( oname, ?olocal_names, onset, utc_offset_from, utc_offset_to )
;タイムゾーンオブジェクトの配列MEMBER obanceances "observances"：ARRAY OBJECT（name、？olocal_names、onset、utc_offset from、utc_offset to）
; Observance name MEMBER oname "name" : STRING
;礼拝名MEMBER oname "name"：STRING
; Array of localized observance names MEMBER olocal_names "local-names" : ARRAY STRING
;ローカライズされた遵守名の配列MEMBER olocal_names "local-names"：ARRAY STRING
; UTC date-time value (per [RFC3339]) at which the observance takes ; effect MEMBER onset "onset" : STRING
;遵守が行われるUTC日時値（[RFC3339]ごと）。効果MEMBER onset "onset"：STRING
; The UTC offset in seconds before the start of this observance MEMBER utc_offset_from "utc-offset-from" : NUMBER
;この遵守の開始前の秒単位のUTCオフセットMEMBER utc_offset_from "utc-offset-from"：NUMBER
; The UTC offset in seconds at and after the start of this observance MEMBER utc_offset_to "utc-offset-to" : NUMBER
;この遵守の開始以降のUTCオフセット（秒）MEMBER utc_offset_to "utc-offset-to"：NUMBER
Below are the rules for the JSON document returned for a "leapseconds" action request.
以下は、「うるう秒」アクション要求に対して返されるJSONドキュメントのルールです。
; root object OBJECT ( expires, publisher, version, leapseconds )
;ルートオブジェクトOBJECT（expires、publisher、version、leapseconds）
; Last valid date covered by the data in this response ; full-date value as specified in [RFC3339] MEMBER expires "expires" : STRING
;この応答のデータがカバーする最後の有効日。 [RFC3339] MEMBERで指定された完全な日付の値が「expires」で期限切れになる：STRING
; Leap-second information publisher MEMBER publisher "publisher" : STRING
;うるう秒情報発行者MEMBER発行者「publisher」：STRING
; Current version of the leap-second information as defined by the ; publisher MEMBER version "version" : STRING
; Current version of the leap-second information as defined by the ; publisher MEMBER version "version" : STRING
; Array of leap-second objects MEMBER leapseconds "leapseconds" : ARRAY OBJECT ( utc_offset, onset )
;うるう秒オブジェクトの配列MEMBERうるう秒「leapseconds」：ARRAY OBJECT（utc_offset、onset）
; The UTC offset from TAI in seconds in effect at and after the ; specified date MEMBER utc_offset "utc-offset" : NUMBER
;で有効な、秒以降のTAIからのUTCオフセット。指定された日付のメンバーutc_offset "utc-offset"：NUMBER
; full-date value (per [RFC3339]) at which the new UTC offset takes
; effect, at T00:00:00Z
MEMBER onset "onset" : STRING
Property Name: TZUNTIL
プロパティ名：TZUNTIL
Purpose: This property specifies an upper bound for the validity period of data within a "VTIMEZONE" component.
目的：このプロパティは、「VTIMEZONE」コンポーネント内のデータの有効期間の上限を指定します。
Value Type: DATE-TIME
値のタイプ：DATE-TIME
Property Parameters: IANA and non-standard property parameters can be specified on this property.
プロパティパラメータ：IANAおよび非標準のプロパティパラメータをこのプロパティで指定できます。
Conformance: This property can be specified zero times or one time within "VTIMEZONE" calendar components.
適合性：このプロパティは、「VTIMEZONE」カレンダーコンポーネント内で0回または1回指定できます。
Description: The value MUST be specified in the UTC time format.
説明：値はUTC時間形式で指定する必要があります。
Time zone data in a "VTIMEZONE" component might cover only a fixed period of time. The start of such a period is clearly indicated by the earliest observance defined by the "STANDARD" and "DAYLIGHT" subcomponents. However, an upper bound on the validity period of the time zone data cannot be simply derived from the observance with the latest onset time, and [RFC5545] does not define a way to get such an upper bound. This specification introduces the "TZUNTIL" property for that purpose. It specifies an "exclusive" UTC date-time value that indicates the last time at which the time zone data is to be considered valid.
「VTIMEZONE」コンポーネントのタイムゾーンデータは、一定期間のみを対象とする場合があります。このような期間の開始は、「STANDARD」および「DAYLIGHT」サブコンポーネントによって定義された最も早い順守によって明確に示されます。しかしながら、タイムゾーンデータの有効期間の上限は、最新の開始時間の遵守から単純に導き出すことはできず、[RFC5545]はそのような上限を取得する方法を定義していません。この仕様では、その目的で「TZUNTIL」プロパティを導入しています。これは、タイムゾーンデータが有効と見なされる最後の時刻を示す「排他的な」UTC日時値を指定します。
This property is also used by time zone data distribution servers to indicate the truncation range end point of time zone data (as described in Section 3.9).
このプロパティは、タイムゾーンデータ配信サーバーでも使用され、タイムゾーンデータの切り捨て範囲のエンドポイントを示します（セクション3.9を参照）。
Format Definition: This property is defined by the following notation in ABNF [RFC5234]:
フォーマット定義：このプロパティは、ABNF [RFC5234]で次の表記法によって定義されます。
tzuntil = "TZUNTIL" tzuntilparam ":" date-time CRLF
tzuntil = "TZUNTIL" tzuntilparam "："日時CRLF
tzuntilparam = *(";" other-param)
Example: Suppose a time zone based on astronomical observations has well-defined onset times through the year 2025, but the first onset in 2026 is currently known only approximately. In that case, the "TZUNTIL" property could be specified as follows:
例：天文観測に基づくタイムゾーンで2025年までの開始時間が明確に定義されているが、2026年の最初の開始は現在のところおよそしかわかっていないとします。その場合、 "TZUNTIL"プロパティは次のように指定できます。
TZUNTIL:20260101T000000Z
TZUNTIL：20260101T000000Z
Property Name: TZID-ALIAS-OF
プロパティ名：TZID-ALIAS-OF
Purpose: This property specifies a time zone identifier for which the main time zone identifier is an alias.
目的：このプロパティは、メインのタイムゾーン識別子がエイリアスであるタイムゾーン識別子を指定します。
Value Type: TEXT
値のタイプ：TEXT
Property Parameters: IANA and non-standard property parameters can be specified on this property.
プロパティパラメータ：IANAおよび非標準のプロパティパラメータをこのプロパティで指定できます。
Conformance: This property can be specified zero or more times within "VTIMEZONE" calendar components.
適合性：このプロパティは、「VTIMEZONE」カレンダーコンポーネント内で0回以上指定できます。
Description: When the "VTIMEZONE" component uses a time zone identifier alias for the "TZID" property value, the "TZID-ALIAS-OF" property is used to indicate the time zone identifier of the other time zone (see Section 3.7).
Description: When the "VTIMEZONE" component uses a time zone identifier alias for the "TZID" property value, the "TZID-ALIAS-OF" property is used to indicate the time zone identifier of the other time zone (see Section 3.7).
Format Definition: This property is defined by the following notation in ABNF [RFC5234]:
Format Definition: This property is defined by the following notation in ABNF [RFC5234]:
tzid-alias-of = "TZID-ALIAS-OF" tzidaliasofparam ":" [tzidprefix] text CRLF
tzid-alias-of = "TZID-ALIAS-OF" tzidaliasofparam "：" [tzidprefix] text CRLF
tzidaliasofparam = *(";" other-param)
;tzidprefix defined in [RFC5545].
; [RFC5545]で定義されているtzidprefix。
Example: The following is an example of this property:
例：以下はこのプロパティの例です。
TZID-ALIAS-OF:America/New_York
TZID-ALIAS-OF：America / New_York
Time zone data is critical in determining local or UTC time for devices and in calendaring and scheduling operations. As such, it is vital that a reliable source of time zone data is used. Servers providing a time zone data distribution service MUST support HTTP over Transport Layer Security (TLS) (as defined by [RFC2818] and [RFC5246], with best practices described in [RFC7525]). Servers MAY support a time zone data distribution service over HTTP without TLS. However, secondary servers MUST use TLS to fetch data from a primary server.
タイムゾーンデータは、デバイスのローカル時間またはUTC時間の決定、およびカレンダー操作とスケジュール操作で重要です。そのため、タイムゾーンデータの信頼できるソースを使用することが重要です。タイムゾーンデータ配信サービスを提供するサーバーは、HTTP over Transport Layer Security（TLS）をサポートする必要があります（[RFC2818]および[RFC5246]で定義され、[RFC7525]で説明されているベストプラクティスを使用）。サーバーは、TLSなしのHTTPを介したタイムゾーンデータ配信サービスをサポートする場合があります。ただし、セカンダリサーバーはTLSを使用してプライマリサーバーからデータをフェッチする必要があります。
Clients SHOULD use Transport Layer Security as defined by [RFC2818], unless they are specifically configured otherwise. Clients that have been configured to use the TLS-based service MUST NOT fall back to using the non-TLS service if the TLS-based service is not available. In addition, clients MUST NOT follow HTTP redirect requests from a TLS service to a non-TLS service. When using TLS, clients MUST verify the identity of the server, using a standard, secure mechanism such as the certificate verification process specified in [RFC6125] or DANE [RFC6698].
クライアントは、特に構成されていない限り、[RFC2818]で定義されているトランスポート層セキュリティを使用する必要があります（SHOULD）。 TLSベースのサービスが使用できない場合、TLSベースのサービスを使用するように構成されたクライアントは、非TLSサービスの使用にフォールバックしてはなりません（MUST NOT）。さらに、クライアントはTLSサービスから非TLSサービスへのHTTPリダイレクト要求に従う必要があります。 TLSを使用する場合、クライアントは、[RFC6125]またはDANE [RFC6698]で指定されている証明書検証プロセスなどの標準の安全なメカニズムを使用して、サーバーのIDを検証する必要があります。
A malicious attacker with access to the DNS server data, or able to get spoofed answers cached in a recursive resolver, can potentially cause clients to connect to any server chosen by the attacker. In the absence of a secure DNS option, clients SHOULD check that the target FQDN returned in the SRV record is the same as the original service domain that was queried, or is a sub-domain of the original service domain. In many cases, the client configuration is likely to be handled automatically without any user input; as such, any mismatch between the original service domain and the target FQDN is treated as a failure and the client MUST NOT attempt to connect to the target server. In addition, when Transport Layer Security is being used, the Transport Layer Security certificate SHOULD include an SRV-ID field as per [RFC4985] matching the expected DNS SRV queries clients will use for service discovery. If an SRV-ID field is present in a certificate, clients MUST match the SRV-ID value with the service type and domain that matches the DNS SRV request made by the client to discover the service.
DNSサーバーデータにアクセスできる悪意のある攻撃者、または再帰リゾルバーにキャッシュされたなりすましの回答を取得できる悪意のある攻撃者は、攻撃者が選択したサーバーにクライアントを接続させる可能性があります。安全なDNSオプションがない場合、クライアントは、SRVレコードで返されたターゲットFQDNが、照会された元のサービスドメインと同じか、または元のサービスドメインのサブドメインであることを確認する必要があります（SHOULD）。多くの場合、クライアント構成はユーザー入力なしで自動的に処理されます。そのため、元のサービスドメインとターゲットFQDNの間の不一致は失敗として扱われ、クライアントはターゲットサーバーへの接続を試みてはなりません（MUST NOT）。さらに、トランスポート層セキュリティが使用されている場合、トランスポート層セキュリティ証明書には、クライアントがサービスディスカバリに使用する予定のDNS SRVクエリに一致する[RFC4985]のようにSRV-IDフィールドを含める必要があります（SHOULD）。証明書にSRV-IDフィールドが存在する場合、クライアントはSRV-ID値を、サービスを検出するためにクライアントが行ったDNS SRV要求と一致するサービスタイプおよびドメインと一致させる必要があります。
Time zone data servers SHOULD protect themselves against poorly implemented or malicious clients by throttling high request rates or frequent requests for large amounts of data. Clients can avoid being throttled by using the polling capabilities outlined in Section 4.1.4. Servers MAY require some form of authentication or authorization of clients (including secondary servers), as per [RFC7235], to restrict which clients are allowed to access their service or provide better identification of problematic clients.
タイムゾーンデータサーバーは、大量のデータに対する高い要求率または頻繁な要求を抑制することにより、適切に実装されていないクライアントまたは悪意のあるクライアントから自分自身を保護する必要があります（SHOULD）。クライアントは、4.1.4項に概説されているポーリング機能を使用することで、スロットルの回避を回避できます。 [RFC7235]に従い、サーバーはクライアント（セカンダリサーバーを含む）の何らかの認証または承認を要求して、サービスにアクセスできるクライアントを制限したり、問題のあるクライアントをより適切に識別したりできます。
The type and pattern of requests that a client makes can be used to "fingerprint" specific clients or devices and thus potentially used to track information about what the users of the clients might be doing. In particular, a client that only downloads time zone data on an as-needed basis, will leak the fact that a user's device has moved from one time zone to another or that the user is receiving scheduling messages from another user in a different time zone.
クライアントが行う要求のタイプとパターンは、特定のクライアントまたはデバイスを「フィンガープリント」するために使用できるため、クライアントのユーザーが何をしているかに関する情報を追跡するために使用される可能性があります。特に、必要に応じてタイムゾーンデータのみをダウンロードするクライアントは、ユーザーのデバイスがあるタイムゾーンから別のタイムゾーンに移動したか、ユーザーが別のタイムゾーンの別のユーザーからスケジュールメッセージを受信しているという事実を漏らします。
Clients need to be aware of the potential ways in which an untrusted server or a network observer might be able to track them and take precautions such as the following:
クライアントは、信頼されていないサーバーまたはネットワークオブザーバーがそれらを追跡し、次のような予防策を講じる可能性のある潜在的な方法を認識する必要があります。
1. Always use TLS to connect to the server.
1. サーバーへの接続には常にTLSを使用します。
2. Avoid use of TLS session resumption.
2. TLSセッション再開の使用を避けます。
3. Always fetch and synchronize the entire set of time zone data to avoid leaking information about which time zones are actually in use by the client.
3. 常にタイムゾーンデータのセット全体をフェッチして同期し、クライアントが実際に使用しているタイムゾーンに関する情報の漏洩を回避します。
4. Randomize the order in which individual time zones are fetched using the "get" action, when retrieving a set of time zones based on a "list" action response.
4. 「リスト」アクションレスポンスに基づいて一連のタイムゾーンを取得する場合、「取得」アクションを使用して個々のタイムゾーンがフェッチされる順序をランダム化します。
5. Avoid use of conditional HTTP requests [RFC7232] with the "get" action to prevent tracking of clients by servers generating client-specific ETag header field values.
5. クライアント固有のETagヘッダーフィールド値を生成するサーバーによるクライアントの追跡を防ぐために、「取得」アクションで条件付きHTTPリクエスト[RFC7232]を使用しないでください。
6. Avoid use of cookies in HTTP requests [RFC6265].
6. Avoid use of cookies in HTTP requests [RFC6265].
7. Avoid use of authenticated HTTP requests.
7. 認証されたHTTP要求の使用を避けます。
8. When doing periodic polling to check for updates, apply a random (positive or negative) offset to the next poll time to avoid servers being able to identify the client by the specific periodicity of its polling behavior.
8. 定期的なポーリングを実行して更新を確認する場合、次のポーリング時間にランダム（正または負）のオフセットを適用して、サーバーがそのポーリング動作の特定の周期によってクライアントを識別できないようにします。
9. A server trying to "fingerprint" clients might insert a "fake" time zone into the time zone data, using a unique identifier for each client making a request. The server can then watch for client requests that refer to that "fake" time zone and thus track the activity of each client. It is hard for clients to identify a "fake" time zone given that new time zones are added occasionally. One option to mitigate this would be for the client to make use of two time zone data distribution servers from two independent providers that provide time zone data from the same publisher. The client can then compare the list of time zones from each server (assuming they both have the same version of time zone data from the common publisher) and detect ones that appear to be added on one server and not the other. Alternatively, the client can check the publisher data directly to verify that time zones match the set the publisher has.
9.クライアントを「フィンガープリント」しようとするサーバーは、要求を行う各クライアントの一意の識別子を使用して、タイムゾーンデータに「偽の」タイムゾーンを挿入する場合があります。サーバーは、その「偽の」タイムゾーンを参照するクライアント要求を監視し、各クライアントのアクティビティを追跡できます。新しいタイムゾーンが時々追加される場合、クライアントが「偽の」タイムゾーンを識別するのは困難です。これを軽減する1つのオプションは、クライアントが、同じパブリッシャーからタイムゾーンデータを提供する2つの独立したプロバイダーからの2つのタイムゾーンデータ配信サーバーを利用することです。次に、クライアントは各サーバーからのタイムゾーンのリストを比較し（両方に共通の発行元からの同じバージョンのタイムゾーンデータが含まれていると想定）、一方のサーバーでは追加されているように見え、もう一方では追加されていないように見えます。または、クライアントはパブリッシャーのデータを直接チェックして、タイムゾーンがパブリッシャーの設定と一致することを確認できます。
Note that some of the above recommendations will result in less efficient use of the protocol due to fetching data that might not be relevant to the client.
上記の推奨事項の一部は、クライアントに関係のないデータをフェッチするため、プロトコルの使用効率が低下することに注意してください。
An organization can set up a secondary server within their own domain and configure their clients to use that server to protect the organization's users from the possibility of being tracked by an untrusted time zone data distribution server. Clients can then use more-efficient protocol interactions, free from the concerns above, on the basis that their organization's server is trusted. When doing this, the secondary server would follow the recommendations for clients (listed in the previous paragraph) so that the untrusted server is not able to gain information about the organization as a whole. Note, however, that client requests to the secondary server are subject to tracking by a network observer, so clients ought to apply some of the randomization techniques from the list above.
組織は、自分のドメイン内にセカンダリサーバーをセットアップし、そのサーバーを使用して、信頼されていないタイムゾーンデータ配布サーバーによって追跡される可能性から組織のユーザーを保護するようにクライアントを構成できます。クライアントは、組織のサーバーが信頼されていることに基づいて、上記の懸念事項から解放され、より効率的なプロトコル相互作用を使用できます。これを行うと、セカンダリサーバーはクライアントの推奨事項（前の段落に記載）に従って、信頼されていないサーバーが組織全体に関する情報を取得できないようにします。ただし、セカンダリサーバーへのクライアント要求はネットワークオブザーバーによる追跡の対象となるため、クライアントは上記のリストからランダム化手法のいくつかを適用する必要があります。
Servers that want to avoid accidentally storing information that could be used to identify clients can take the following precautions:
クライアントの識別に使用される可能性のある情報を誤って保存しないようにするサーバーは、次の予防策を講じることができます。
1. Avoid logging client request activity, or anonymize information in any logs (e.g., client IP address, client user-agent details, authentication credentials, etc.).
1. クライアントのリクエストアクティビティをログに記録しないようにするか、ログの情報を匿名化します（クライアントのIPアドレス、クライアントのユーザーエージェントの詳細、認証資格情報など）。
2. Add an unused HTTP response header to each response with a random amount of data in it (e.g., to pad the overall request size to the nearest power-of-2 or 128-byte boundary) to avoid exposing which time zones are being fetched when TLS is being used, via network traffic analysis.
2. ランダムな量のデータが含まれる各応答に未使用のHTTP応答ヘッダーを追加し（たとえば、全体の要求サイズを最も近い2の累乗または128バイトの境界に埋め込むため）、いつフェッチされるタイムゾーンを公開しないようにしますTLSは、ネットワークトラフィック分析を介して使用されています。
This specification defines a new registry of "actions" for the time zone data distribution service protocol, defines a "well-known" URI using the registration procedure and template from Section 5.1 of [RFC5785], creates two new SRV service label aliases, and defines one new iCalendar property parameter as per the registration procedure in [RFC5545]. It also adds a new "TZDIST Identifiers Registry" to the IETF parameters URN sub-namespace as per [RFC3553] for use with protocol related error codes.
この仕様は、タイムゾーンデータ配布サービスプロトコルの「アクション」の新しいレジストリを定義し、[RFC5785]のセクション5.1の登録手順とテンプレートを使用して「既知の」URIを定義し、2つの新しいSRVサービスラベルエイリアスを作成します。 [RFC5545]の登録手順に従って、1つの新しいiCalendarプロパティパラメータを定義します。また、プロトコル関連のエラーコードで使用するために、[RFC3553]に従って、新しい「TZDIST Identifiers Registry」をIETFパラメータのURNサブネームスペースに追加します。
IANA has created a new top-level category called "Time Zone Data Distribution Service (TZDIST) Parameters" and has put all the registries created herein into that category.
IANAは、「タイムゾーンデータ配布サービス（TZDIST）パラメータ」と呼ばれる新しい最上位カテゴリを作成し、ここで作成されたすべてのレジストリをそのカテゴリに入れました。
IANA has created a new registry called "TZDIST Service Actions", as defined below.
IANAは、以下に定義する「TZDISTサービスアクション」と呼ばれる新しいレジストリを作成しました。
This registry uses the "Specification Required" policy defined in [RFC5226], which makes use of a designated expert to review potential registrations.
このレジストリは、[RFC5226]で定義されている "Specification Required"ポリシーを使用します。このポリシーは、指定された専門家を利用して潜在的な登録を確認します。
The IETF has created a mailing list, tzdist-service@ietf.org, which is used for public discussion of time zone data distribution service actions proposals prior to registration. The IESG has appointed a designated expert who will monitor the tzdist-service@ietf.org mailing list and review registrations.
IETFは、メーリングリストtzdist-service@ietf.orgを作成しました。これは、登録前のタイムゾーンデータ配信サービスアクションの提案の公開ディスカッションに使用されます。 IESGは、tzdist-service @ ietf.orgメーリングリストを監視し、登録を確認する指定された専門家を任命しました。
A Standards Track RFC is REQUIRED for changes to actions previously documented in a Standards Track RFC; otherwise, any public specification that satisfies the requirements of [RFC5226] is acceptable.
Standards Track RFCは、Standards Track RFCで以前に文書化されたアクションへの変更に必要です。それ以外の場合は、[RFC5226]の要件を満たす任意の公開仕様が受け入れられます。
The registration procedure begins when a completed registration template, as defined below, is sent to tzdist-service@ietf.org and iana@iana.org. The designated expert is expected to tell IANA and the submitter of the registration whether the registration is approved, approved with minor changes, or rejected with cause, within two weeks. When a registration is rejected with cause, it can be resubmitted if the concerns listed in the cause are addressed. Decisions made by the designated expert can be appealed as per Section 7 of [RFC5226].
登録手順は、以下で定義されている完成した登録テンプレートがtzdist-service@ietf.orgおよびiana@iana.orgに送信されると開始されます。指定された専門家は、2週間以内にIANAと登録の提出者に、登録が承認されたか、軽微な変更で承認されたか、または理由により拒否されたかを通知することが期待されます。登録が原因で拒否された場合、原因にリストされている懸念に対処すれば、再送信できます。指定された専門家による決定は、[RFC5226]のセクション7に従って上訴することができます。
The designated expert MUST take the following requirements into account when reviewing the registration:
指定された専門家は、登録をレビューする際に以下の要件を考慮に入れなければなりません：
1. A valid registration template MUST be provided by the submitter, with a clear description of what the action does.
1. アクションが何をするかの明確な説明とともに、有効な登録テンプレートが提出者によって提供されなければなりません。
2. A proposed new action name MUST NOT conflict with any existing registered action name. A conflict includes a name that duplicates an existing one or that appears to be very similar to an existing one and could be a potential source of confusion.
2. 提案された新しいアクション名は、既存の登録済みアクション名と競合してはなりません。競合には、既存の名前と重複する名前、または既存の名前と非常に似ていると思われる名前が含まれ、混乱の原因となる可能性があります。
3. A proposed new action MUST NOT exactly duplicate the functionality of any existing actions. In cases where the new action functionality is very close to an existing action, the designated expert SHOULD clarify whether the submitter is aware of the existing action, and has an adequate reason for creating a new action with slight differences from an existing one.
3. 提案された新しいアクションは、既存のアクションの機能を正確に複製してはなりません。新しいアクションの機能が既存のアクションに非常に近い場合、指定されたエキスパートは、提出者が既存のアクションを認識しているかどうかを明確にする必要があり、既存のアクションとわずかに異なる新しいアクションを作成する十分な理由があります。
4. If a proposed action is an extension to an existing action, the changes MUST NOT conflict with the intent of the existing action, or in a way that could cause interoperability problems for existing deployments of the protocol.
4. 提案されたアクションが既存のアクションの拡張である場合、変更は既存のアクションの意図と矛盾してはならず、またはプロトコルの既存のデプロイメントに相互運用性の問題を引き起こす可能性があります。
The IANA registry contains the name of the action ("Action Name") and a reference to the section of the specification where the action registration template is defined ("Reference").
IANAレジストリには、アクションの名前（「アクション名」）と、アクション登録テンプレートが定義されている仕様のセクションへの参照（「リファレンス」）が含まれています。
An action is defined by completing the following template.
アクションは、次のテンプレートを完了することによって定義されます。
Name: The name of the action.
名前：アクションの名前。
Request-URI Template: The URI template used in HTTP requests for the action.
リクエストURIテンプレート：アクションのHTTPリクエストで使用されるURIテンプレート。
Description: A general description of the action, its purpose, etc.
説明：アクション、その目的などの一般的な説明。
Parameters: A list of allowed request URI query parameters, indicating whether they are "REQUIRED" or "OPTIONAL" and whether they can occur only once or multiple times, together with the expected format of the parameter values.
パラメータ：許可されたリクエストURIクエリパラメータのリスト。それらが「必須」か「オプション」か、およびパラメータ値の予期される形式とともに、1回のみまたは複数回発生できるかを示します。
Response: The nature of the response to the HTTP request, e.g., what format the response data is in.
応答：HTTP要求への応答の性質（応答データの形式など）。
Possible Error Codes: Possible error codes reported in a JSON "problem details" object if an HTTP request fails.
考えられるエラーコード：HTTPリクエストが失敗した場合にJSON「問題の詳細」オブジェクトで報告される考えられるエラーコード。
The following table provides the initial content of the actions registry.
次の表に、アクションレジストリの初期コンテンツを示します。
+---------------+------------------------+
| Action Name | Reference |
+---------------+------------------------+
| capabilities | RFC 7808, Section 5.1 |
| list | RFC 7808, Section 5.2 |
| get | RFC 7808, Section 5.3 |
| expand | RFC 7808, Section 5.4 |
| find | RFC 7808, Section 5.5 |
| leapseconds | RFC 7808, Section 5.6 |
+---------------+------------------------+
IANA has added the following to the "Well-Known URIs" [RFC5785] registry:
IANAは、「既知のURI」[RFC5785]レジストリに以下を追加しました。
URI suffix: timezone
URIサフィックス：タイムゾーン
Change controller: IESG.
コントローラーの変更：IESG。
Specification document(s): RFC 7808
仕様書：RFC 7808
Related information: None.
関連情報：なし。
IANA has added two new service names to the "Service Name and Transport Protocol Port Number Registry" [RFC6335], as defined below.
IANAは、「サービス名とトランスポートプロトコルのポート番号レジストリ」[RFC6335]に、以下に定義するように、2つの新しいサービス名を追加しました。
Service Name: timezone
サービス名：タイムゾーン
Transport Protocol(s): TCP
トランスポートプロトコル：TCP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Time Zone Data Distribution Service - non-TLS
説明：タイムゾーンデータ配布サービス-非TLS
Reference: RFC 7808 Assignment Note: This is an extension of the http service. Defined TXT keys: path=<context path> (as per Section 6 of [RFC6763]).
参照：RFC 7808割り当て注：これは、httpサービスの拡張です。定義されたTXTキー：path = <context path>（[RFC6763]のセクション6による）。
Service Name: timezones
サービス名：タイムゾーン
Transport Protocol(s): TCP
トランスポートプロトコル：TCP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Time Zone Data Distribution Service - over TLS
説明：タイムゾーンデータ配布サービス-TLS経由
Reference: RFC 7808
リファレンス：RFC 7808
Assignment Note: This is an extension of the https service. Defined TXT keys: path=<context path> (as per Section 6 of [RFC6763]).
割り当てメモ：これは、httpsサービスの拡張です。定義されたTXTキー：path = <context path>（[RFC6763]のセクション6による）。
IANA has registered a new URN sub-namespace within the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers defined in [RFC3553].
IANAは、[RFC3553]で定義されている登録済みプロトコルパラメータ識別子のIETF URNサブ名前空間内に新しいURNサブ名前空間を登録しました。
Registrations in this registry follow the "IETF Review" [RFC5226] policy.
このレジストリへの登録は、「IETFレビュー」[RFC5226]ポリシーに従います。
Registry name: TZDIST Identifiers
レジストリ名：TZDIST識別子
URN prefix: urn:ietf:params:tzdist
Specification: RFC 7808
仕様：RFC 7808
Repository: http://www.iana.org/assignments/tzdist-identifiers
Index value: Values in this registry are URNs or URN prefixes that start with the prefix "urn:ietf:params:tzdist:". Each is registered independently. The prefix "urn:ietf:params:tzdist:error:" is used to represent specific error codes within the protocol as defined in the list of actions in Section 5 and used in problem reports (Section 4.1.7).
インデックス値：このレジストリの値は、プレフィックス「urn：ietf：params：tzdist：」で始まるURNまたはURNプレフィックスです。それぞれが個別に登録されます。接頭辞「urn：ietf：params：tzdist：error：」は、セクション5のアクションのリストで定義され、問題レポート（セクション4.1.7）で使用されるプロトコル内の特定のエラーコードを表すために使用されます。
Each registration in the "TZDIST Identifiers" registry requires the following information:
"TZDIST Identifiers"レジストリの各登録には、次の情報が必要です。
URN: The complete URN that is used or the prefix for that URN.
URN：使用される完全なURNまたはそのURNのプレフィックス。
Description: A summary description for the URN or URN prefix.
説明：URNまたはURNプレフィックスの概要説明。
Specification: A reference to a specification describing the URN or URN prefix.
仕様：URNまたはURN接頭辞を記述する仕様への参照。
Contact: Email for the person or groups making the registration.
連絡先：登録を行う人またはグループのメール。
Index Value: As described in [RFC3553], URN prefixes that are registered include a description of how the URN is constructed. This is not applicable for specific URNs.
インデックス値：[RFC3553]で説明されているように、登録されているURNプレフィックスには、URNの構成方法の説明が含まれています。これは特定のURNには適用されません。
The "TZDIST Identifiers" registry has the initial registrations included in the following sections.
「TZDIST Identifiers」レジストリには、以下のセクションに含まれる初期登録があります。
The following URN has been registered in the "tzdist Identifiers" registry.
次のURNは「tzdist Identifiers」レジストリに登録されています。
URN: urn:ietf:params:tzdist:error:invalid-action
Description: Generic error code for any invalid action.
説明：無効なアクションの一般的なエラーコード。
Specification: RFC 7808, Section 5
仕様：RFC 7808、セクション5
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Index value: N/A.
インデックス値：N / A。
The following URN has been registered in the "tzdist Identifiers" registry.
次のURNは「tzdist Identifiers」レジストリに登録されています。
URN: urn:ietf:params:tzdist:error:invalid-changedsince
Description: Error code for incorrect use of the "changedsince" URI query parameter.
説明：「changedsince」URIクエリパラメータの誤った使用に関するエラーコード。
Specification: RFC 7808, Section 5.2
仕様：RFC 7808、セクション5.2
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Index value: N/A.
インデックス値：N / A。
The following URN has been registered in the "tzdist Identifiers" registry.
次のURNは「tzdist Identifiers」レジストリに登録されています。
URN: urn:ietf:params:tzdist:error:tzid-not-found
Description: Error code for missing time zone identifier.
説明：タイムゾーン識別子がないためのエラーコード。
Specification: RFC 7808, Sections 5.3 and 5.4
仕様：RFC 7808、セクション5.3および5.4
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Index value: N/A.
インデックス値：N / A。
The following URN has been registered in the "tzdist Identifiers" registry.
次のURNは「tzdist Identifiers」レジストリに登録されています。
URN: urn:ietf:params:tzdist:error:invalid-format
Description: Error code for unsupported HTTP Accept request header field value.
説明：サポートされていないHTTP Acceptリクエストヘッダーフィールド値のエラーコード。
Specification: RFC 7808, Section 5.3
仕様：RFC 7808、セクション5.3
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Index value: N/A.
インデックス値：N / A。
The following URN has been registered in the "tzdist Identifiers" registry.
次のURNは「tzdist Identifiers」レジストリに登録されています。
URN: urn:ietf:params:tzdist:error:invalid-start
Description: Error code for incorrect use of the "start" URI query parameter.
説明：「開始」URIクエリパラメータの不適切な使用に関するエラーコード。
Specification: RFC 7808, Sections 5.3 and 5.4
仕様：RFC 7808、セクション5.3および5.4
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Index value: N/A.
インデックス値：N / A。
The following URN has been registered in the "tzdist Identifiers" registry.
次のURNは「tzdist Identifiers」レジストリに登録されています。
URN: urn:ietf:params:tzdist:error:invalid-end
Description: Error code for incorrect use of the "end" URI query parameter.
説明：「end」URIクエリパラメータの誤った使用に関するエラーコード。
Specification: RFC 7808, Sections 5.3 and 5.4
仕様：RFC 7808、セクション5.3および5.4
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Index value: N/A.
インデックス値：N / A。
The following URN has been registered in the "tzdist Identifiers" registry.
次のURNは「tzdist Identifiers」レジストリに登録されています。
URN: urn:ietf:params:tzdist:error:invalid-pattern
Description: Error code for incorrect use of the "pattern" URI query parameter.
説明：「パターン」URIクエリパラメータの誤った使用に関するエラーコード。
Specification: RFC 7808, Section 5.5
仕様：RFC 7808、セクション5.5
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Index value: N/A.
インデックス値：N / A。
This document defines the following new iCalendar properties, which have been added to the "Properties" registry under "iCalendar Element Registries" [RFC5545]:
このドキュメントでは、次の新しいiCalendarプロパティを定義します。これらのプロパティは、「iCalendar Element Registries」[RFC5545]の「Properties」レジストリに追加されています。
+----------------+----------+------------------------+
| Property | Status | Reference |
+----------------+----------+------------------------+
| TZUNTIL | Current | RFC 7808, Section 7.1 |
| TZID-ALIAS-OF | Current | RFC 7808, Section 7.2 |
+----------------+----------+------------------------+
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>.
[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、DOI 10.17487 / RFC2046、1996年11月、<http://www.rfc-editor.org / info / rfc2046>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<http：// www.rfc-editor.org/info/rfc2782>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC3339] Klyne、G。およびC. Newman、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<http://www.rfc-editor.org/info/rfc3339 >。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <http://www.rfc-editor.org/info/rfc3553>.
[RFC3553] Mealling、M.、Masinter、L.、Hardie、T。、およびG. Klyne、「An Registered Protocol Parameters for IETF URN Sub-namespace for Registered Protocol Parameters」、BCP 73、RFC 3553、DOI 10.17487 / RFC3553、2003年6月、 <http://www.rfc-editor.org/info/rfc3553>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。
[RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, DOI 10.17487/RFC4985, August 2007, <http://www.rfc-editor.org/info/rfc4985>.
[RFC4985] Santesson、S。、「Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name」、RFC 4985、DOI 10.17487 / RFC4985、2007年8月、<http://www.rfc-editor.org/ info / rfc4985>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, September 2009, <http://www.rfc-editor.org/info/rfc5545>.
[RFC5545] Desruisseaux、B。、編、「Internet Calendaring and Scheduling Core Object Specification（iCalendar）」、RFC 5545、DOI 10.17487 / RFC5545、2009年9月、<http://www.rfc-editor.org/info/ rfc5545>。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <http://www.rfc-editor.org/info/rfc5785>.
[RFC5785]ノッティンガム、M。およびE.ハマーラハブ、「Defining Well-Known Uniform Resource Identifiers（URIs）」、RFC 5785、DOI 10.17487 / RFC5785、2010年4月、<http://www.rfc-editor.org / info / rfc5785>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<http://www.rfc-editor.org/info/rfc6125>。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[RFC6265] Barth、A。、「HTTP State Management Mechanism」、RFC 6265、DOI 10.17487 / RFC6265、2011年4月、<http://www.rfc-editor.org/info/rfc6265>。
[RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML Format for iCalendar", RFC 6321, DOI 10.17487/RFC6321, August 2011, <http://www.rfc-editor.org/info/rfc6321>.
[RFC6321] Daboo、C.、Douglass、M。、およびS. Lees、「xCal：The XML Format for iCalendar」、RFC 6321、DOI 10.17487 / RFC6321、2011年8月、<http：//www.rfc-editor。 org / info / rfc6321>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<http://www.rfc-editor.org/info/rfc6335>。
[RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the Time Zone Database", BCP 175, RFC 6557, DOI 10.17487/RFC6557, February 2012, <http://www.rfc-editor.org/info/rfc6557>.
[RFC6557] Lear、E。およびP. Eggert、「Procedures for Maintaining the Time Zone Database」、BCP 175、RFC 6557、DOI 10.17487 / RFC6557、2012年2月、<http://www.rfc-editor.org/info / rfc6557>。
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <http://www.rfc-editor.org/info/rfc6570>.
[RFC6570]グレゴリオ、J。、フィールディング、R。、ハドリー、M。、ノッティンガム、M。、およびD.オーチャード、「URIテンプレート」、RFC 6570、DOI 10.17487 / RFC6570、2012年3月、<http：// www .rfc-editor.org / info / rfc6570>。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティ（DANE）トランスポート層セキュリティ（TLS）プロトコルの認証：TLSA」、RFC 6698、DOI 10.17487 / RFC6698、2012年8月、<http：/ /www.rfc-editor.org/info/rfc6698>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNS-Based Service Discovery」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<http://www.rfc-editor.org/info/rfc6763>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231 >。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、RFC 7232、DOI 10.17487 / RFC7232、2014年6月、<http://www.rfc-editor.org/info/rfc7232> 。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<http://www.rfc-editor.org/info/rfc7234>。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、DOI 10.17487 / RFC7235、2014年6月、<http://www.rfc-editor.org/info/rfc7235>。
[RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May 2014, <http://www.rfc-editor.org/info/rfc7265>.
[RFC7265] Kewisch、P.、Daboo、C。、およびM. Douglass、「jCal：The JSON Format for iCalendar」、RFC 7265、DOI 10.17487 / RFC7265、2014年5月、<http：//www.rfc-editor。 org / info / rfc7265>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, <http://www.rfc-editor.org/info/rfc7807>.
[RFC7807]ノッティンガム、M。およびE.ワイルド、「HTTP APIの問題の詳細」、RFC 7807、DOI 10.17487 / RFC7807、2016年3月、<http://www.rfc-editor.org/info/rfc7807>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<http://www.rfc-editor.org/info/rfc2131>。
Acknowledgements
謝辞
The authors would like to thank the members of the Calendaring and Scheduling Consortium's Time Zone Technical Committee, and the participants and chairs of the IETF tzdist working group. In particular, the following individuals have made important contributions to this work: Steve Allen, Lester Caine, Stephen Colebourne, Tobias Conradi, Steve Crocker, Paul Eggert, Daniel Kahn Gillmor, John Haug, Ciny Joy, Bryan Keller, Barry Leiba, Andrew McMillan, Ken Murchison, Tim Parenti, Arnaud Quillaud, Jose Edvaldo Saraiva, and Dave Thewlis.
著者は、Calendaring and Scheduling ConsortiumのTime Zone Technical Committeeのメンバー、およびIETF tzdistワーキンググループの参加者と議長に感謝します。特に、次の個人がこの作業に重要な貢献をしています。 、ケン・マーチソン、ティム・パレンティ、アルノー・キロー、ホセ・エドヴァルド・サライバ、デイブ・シューリス。
This specification originated from work at the Calendaring and Scheduling Consortium, which has supported the development and testing of implementations of the specification.
この仕様は、仕様の実装の開発とテストをサポートしているCalendaring and Scheduling Consortiumでの作業に基づいています。
Authors' Addresses
著者のアドレス
Michael Douglass Spherical Cow Group 226 3rd Street Troy, NY 12180 United States
Michael Douglass Spherical Cow Group 226 3rd Street Troy、NY 12180アメリカ合衆国
Email: mdouglass@sphericalcowgroup.com
URI: http://sphericalcowgroup.com
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino、CA 95014 United States
Email: cyrus@daboo.name
URI: http://www.apple.com/