Network Working Group M. Douglass
Internet-Draft RPI
Intended status: Standards Track C. Daboo
Expires: June 2, 2013 Apple
November 29, 2012
Timezone Service Protocol
draft-douglass-timezone-service-07
Abstract
This document defines a timezone service protocol that allows
reliable, secure and fast delivery of timezone information to client
systems such as calendaring and scheduling applications or operating
systems.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 2, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Douglass & Daboo Expires June 2, 2013 [Page 1]
Internet-Draft Timezone Service Protocol November 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Glossary of terms . . . . . . . . . . . . . . . . . . . . 4
2. Architectural Overview . . . . . . . . . . . . . . . . . . . . 5
3. General Considerations . . . . . . . . . . . . . . . . . . . . 6
3.1. Timezone Identitifiers . . . . . . . . . . . . . . . . . . 6
3.2. Timezone Identitifier Aliases . . . . . . . . . . . . . . 7
3.3. Timezone Localized Names . . . . . . . . . . . . . . . . . 7
3.4. Inactive Timezones . . . . . . . . . . . . . . . . . . . . 7
4. Timezones Service Protocol . . . . . . . . . . . . . . . . . . 8
4.1. Server Protocol . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Timezone Queries . . . . . . . . . . . . . . . . . . . 8
4.1.2. Timezone Formats . . . . . . . . . . . . . . . . . . . 8
4.1.3. Conditional Timezone Requests . . . . . . . . . . . . 8
4.1.4. Expanded Timezone Data . . . . . . . . . . . . . . . . 9
4.1.5. Server Requirements . . . . . . . . . . . . . . . . . 9
4.1.6. Error Responses . . . . . . . . . . . . . . . . . . . 9
4.1.7. Extensions . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Client Guidelines . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1.1. Timezone Service SRV Service Labels . . . . . . . 10
4.2.1.2. Timezone Service TXT records . . . . . . . . . . . 11
4.2.1.3. Timezone Service Well-Known URI . . . . . . . . . 11
4.2.1.3.1. Example: well-known URI redirects to
actual context path . . . . . . . . . . . . . 12
4.2.2. Initial Synchronization of All Timezones . . . . . . . 12
4.2.3. Subsequent Synchronization of All Timezones . . . . . 12
5. Request Parameters . . . . . . . . . . . . . . . . . . . . . . 12
5.1. "action" Parameter . . . . . . . . . . . . . . . . . . . . 13
5.2. "format" Parameter . . . . . . . . . . . . . . . . . . . . 13
5.3. "changedsince" Parameter . . . . . . . . . . . . . . . . . 13
5.4. "start" Parameter . . . . . . . . . . . . . . . . . . . . 14
5.5. "end" Parameter . . . . . . . . . . . . . . . . . . . . . 14
5.6. "lang" Parameter . . . . . . . . . . . . . . . . . . . . . 14
5.7. "returnall" Parameter . . . . . . . . . . . . . . . . . . 14
5.8. "tzid" Parameter . . . . . . . . . . . . . . . . . . . . . 14
5.9. "name" Parameter . . . . . . . . . . . . . . . . . . . . . 15
6. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. "capabilities" Action . . . . . . . . . . . . . . . . . . 15
6.1.1. Example: Get Capabilities . . . . . . . . . . . . . . 15
6.2. "list" Action . . . . . . . . . . . . . . . . . . . . . . 18
6.2.1. Example: List timezone identifiers . . . . . . . . . . 19
6.3. "get" Action . . . . . . . . . . . . . . . . . . . . . . . 19
6.3.1. Example: Get timezone . . . . . . . . . . . . . . . . 21
6.4. "expand" Action . . . . . . . . . . . . . . . . . . . . . 21
6.4.1. Example: Expanded JSON Data Format . . . . . . . . . . 23
Douglass & Daboo Expires June 2, 2013 [Page 2]
Internet-Draft Timezone Service Protocol November 2012
6.5. "find" Action . . . . . . . . . . . . . . . . . . . . . . 23
6.5.1. Example: Find action . . . . . . . . . . . . . . . . . 24
7. JSON Definitions . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. capabilities action response . . . . . . . . . . . . . . . 24
7.2. list action response . . . . . . . . . . . . . . . . . . . 26
7.3. expand action response . . . . . . . . . . . . . . . . . . 28
7.4. error response . . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9.1. Service Actions Registration . . . . . . . . . . . . . . . 30
9.1.1. Service Actions Registration Procedure . . . . . . . . 30
9.1.2. Registration Template for Actions . . . . . . . . . . 30
9.1.3. Registration Template for Action Parameters . . . . . 31
9.2. Initial Timezone Service Registries . . . . . . . . . . . 31
9.2.1. Actions Registry . . . . . . . . . . . . . . . . . . . 31
9.2.2. Action Parameters Registry . . . . . . . . . . . . . . 31
9.3. timezone Well-Known URI Registration . . . . . . . . . . . 32
9.4. Service Name Registrations . . . . . . . . . . . . . . . . 32
9.4.1. timezone Service Name Registration . . . . . . . . . . 32
9.4.2. timezones Service Name Registration . . . . . . . . . 33
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
11. Normative References . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Changes for version 07 . . . . . . . . . . . . . . . 35
Appendix B. Changes for version 06 . . . . . . . . . . . . . . . 35
Appendix C. Changes for version 05 . . . . . . . . . . . . . . . 35
Appendix D. Changes for version 04 . . . . . . . . . . . . . . . 35
Appendix E. Changes for version 03 . . . . . . . . . . . . . . . 36
Appendix F. Changes for version 02 . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Douglass & Daboo Expires June 2, 2013 [Page 3]
Internet-Draft Timezone Service Protocol November 2012
1. Introduction
Timezone information typically combines a coordinated universal time
(UTC) offset with daylight saving time (DST) rules. Timezones 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
(sometimes hours before a change comes into effect).
Calendaring and scheduling systems, such as those that use iCalendar
[RFC5545], as well as operating systems, critically rely on timezone
information to determine the correct local time. As such they need
to be kept up to date with changes to timezone information. To date
there has been no fast and easy way to do that. Timezone 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,
those changes often only get propagated out to client machines when
there is an operating system update and those can be infrequent,
resulting in inaccurate timezone data being present for significant
amounts of time.
This specification defines a timezone service protocol that allows
for fast, reliable and accurate delivery of timezone information to
client systems. This protocol is based on HTTP [RFC2616] using a
REST style API, with JSON [RFC4627] responses.
This specification does not define the source of the timezone
information. It is assumed that a reliable and accurate source is
available. One such source is the IANA hosted timezone database
[RFC6557].
This specification does not address the need for global timezone
identifiers for timezone data.
Discussion of this document should take place on the calsify mailing
list calsify@ietf.org
1.1. Conventions
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].
1.2. Glossary of terms
The following terms with the given meanings are used throughout this
document.
Douglass & Daboo Expires June 2, 2013 [Page 4]
Internet-Draft Timezone Service Protocol November 2012
Timezone Data: Data that defines a single timezone, including an
identifier, UTC offset values, and DST rules;
Timezone Server: A server implementing the Timezone Service Protocol
defined by this specification;
Timezone Identifier: A globally unique name which identifies
timezone information.
2. Architectural Overview
The overall process for the delivery of timezone data can be
visualized via the diagram shown below.
==================== ====================
(a) | Contributors | | Contributors |
==================== ====================
| |
==================== ====================
(b) | Publisher A | | Publisher B |
==================== ====================
|
====================
(c) | Provider |
====================
/ | \
/ | \
==================== | ====================
(d) | Provider | | | Provider |
==================== | ====================
| | | |
| | | |
========== ========== ========== ==========
(e) | Client | | Client | | Client | | Client |
========== ========== ========== ==========
Figure 1: Timezone Service Architecture
The overall service is made up of several layers:
(a) Contributors: Individuals, governments or organizations which
provide information about timezones to the publishing process.
There can be many contributors.
Douglass & Daboo Expires June 2, 2013 [Page 5]
Internet-Draft Timezone Service Protocol November 2012
(b) Publishers: Publishers aggregate information from contributors,
determine the reliability of the information and, based on that,
generate timezone data. There can be many publishers, each
getting information from many different contributors. In some
cases a publisher may choose to "re-publish" data from another
publisher.
(c) Root Providers: Servers which obtain and then provide the
timezone data from publishers and make that available to other
servers or clients. There can be many root providers. Root
providers can choose to supply timezone data from one or more
publishers.
(d) Local Providers: Servers which 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
setup their own local provider to allow clients within their
network to make requests of that server rather than making
requests of servers outside their network. Local servers will
cache and periodically refresh data from the root servers.
(e) Clients: Applications, operating systems etc., that make use of
timezone data and retrieve that from either root or local
providers.
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 local servers and a small number
of root servers.
This specification is only concerned 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.
3. General Considerations
3.1. Timezone Identitifiers
Timezone identifiers are the canonical names for identifiers. There
MUST be one and only one identifier per specification. iCalendar
Section 3.8.3.1 [RFC5545] has this text on the identifier:
Douglass & Daboo Expires June 2, 2013 [Page 6]
Internet-Draft Timezone Service Protocol November 2012
This is the label by which a time zone calendar component is
referenced by any iCalendar properties whose value type is
either "DATE-TIME" or "TIME" and not intended to specify a UTC
or a "floating" time. The presence of the SOLIDUS character
as a prefix, indicates that this "TZID" represents an unique
identifier in a globally defined time zone registry (when such
registry is defined).
This specification does not define what identifiers should be used.
While the above specifies that names must start with "/" to be
globally unique, it is assumed that a set of timezone identifiers
will be considered the default set with an implied "/" preceding the
identifier.
3.2. Timezone Identitifier Aliases
Timezone identifier aliases map a timezone identifier onto a
canonical timezone identifier. For example US/Eastern is usually
mapped on to America/New_York.
A timezone service needs to maintain timezone identifier alias
information, and return that data as well as allow queries using
aliases.
3.3. Timezone Localized Names
Localized names are names for timezones which can be presented to a
user in their own language. Each timezone 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.
A timezone service needs to return localized name information, for
one or more chosen languages, as well as provide a way for clients to
query for timezone data based on a localized name.
3.4. Inactive Timezones
Over time, timezones can be replaced by others, but need to be
maintained for historical purposes. Usually, clients are only
concerned with timezones valid for current and future dates and
times. A timezone service needs to return inactive timezones, but
only needs to do that at the specific request of a client. i.e.,
current timezones would be returned by default, but inactive
timezones could also be requested.
Douglass & Daboo Expires June 2, 2013 [Page 7]
Internet-Draft Timezone Service Protocol November 2012
4. Timezones Service Protocol
4.1. Server Protocol
The timezone service protocol uses HTTP [RFC2616] for query and
delivery of data. Queries are made on a single HTTP resource using
the GET method is used, with specific client request attributes
passed in request-URI parameters.
The "action" request-URI parameter defines the overall function being
requested, with other request parameters acting as arguments to that
function.
Most security considerations are already handled adequately by HTTP.
However, given the nature of the data being transferred and the
requirement it be correct all interactions between client and server
SHOULD use an HTTP connection protected with TLS [RFC5246] as defined
in [RFC2818].
4.1.1. Timezone Queries
Timezone identifiers, aliases or names can be used to query for
timezone data. This will be more explicitly defined below for each
action. In general however, if a "tzid" request parameter is used
then the value may be an identifier or an alias. When the "name"
parameter is used it may be an identifier, an alias or a localized
name.
4.1.2. Timezone Formats
The default format for returning timezone definitions is the
iCalendar [RFC5545] data format. In addition, the iCalendar-in-XML
[RFC6321], and iCalendar-in-JSON
[I-D.kewisch-et-al-icalendar-in-json] representations are also
available. The "format" request-URI parameter can be used to select
which data format is returned.
4.1.3. Conditional Timezone Requests
Timezone information is generally slow moving, with the set of
timezones that change from even year-to-year being relatively small.
However, any changes that do occur, need to be distributed in a
timely manner. Typically it is more efficient to just provide the
set of changes to timezone data, so a client can do updates to any
locally cached data.
When listing timezones, a timestamp is returned by the server, and
that can be used later by clients to determine if any "substantive"
Douglass & Daboo Expires June 2, 2013 [Page 8]
Internet-Draft Timezone Service Protocol November 2012
change has occurred in the timezone data. Clients can use a
conditional "list" action (see Section 6.2), supplying a previous
timestamp value, to limit the results to timezones which have changed
in a "substantive" manner since that previous timestamp. This allows
clients to cache the last timestamp and to periodically poll the
server for possible changes.
A "substantive" change is one which affects the calculated onsets for
a timezone. Changes to properties such as a description are not
treated as a "substantive" change.
Clients SHOULD NOT poll for such changes too frequently. See
Section 8 on expected client and server behavior regarding high
request rates.
4.1.4. Expanded Timezone Data
Determining timezone 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 timezone service provides an action
that allows clients to request the server to expand a timezone
definition into a set of "observances" over a fixed period of time
(see Section 6.4). Each of these observances describes a local 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 timezone expansion themselves.
4.1.5. Server Requirements
All servers MUST deliver timezone information for all timezones.
This means that any client API implementation can go to a single
server to get all timezone information. 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.
All service providers MUST deliver functionally equivalent data for
all timezones. This ensures that all parties in a contract agree on
the UTC time. Service providers (or publishers) may choose to map a
particular region on to a different timezone identifier to correct a
deficiency in the original timezone specification.
4.1.6. Error Responses
The following are examples of response codes one would expect to be
used by the server. Note, however, that unless explicitly prohibited
any 2/3/4/5xx series response code may be used in a response.
Douglass & Daboo Expires June 2, 2013 [Page 9]
Internet-Draft Timezone Service Protocol November 2012
200 (OK) - The command succeeded.
400 (Bad Request) - The Sender has provided an invalid request
parameter.
404 (Not Found) - The timezone was not found.
When an error status is set the server SHOULD respond with some
descriptive text in an error element Section 7.4
4.1.7. Extensions
This protocol is designed to be extensible through a standards based
registration mechanism (see Section 9). It is anticipated that other
useful timezone actions will be added in the future (e.g., mapping a
geographical location to timezone identifiers, getting change history
for timezones), 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.
4.2. Client Guidelines
4.2.1. Discovery
Client implementations need to either know where the timezone service
is located or discover it through some mechanism. To use a timezone
service, a client needs an FQDN, port and HTTP request-URI path.
4.2.1.1. Timezone Service SRV Service Labels
[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.
This specification adds two service types for use with SRV records:
timezone: Identifies a Timezone server that uses HTTP without
transport layer security ([RFC2818]).
timezones: Identifies a Timezone server that uses HTTP with
transport layer security ([RFC2818]).
Clients MUST honor "TTL", "Priority" and "Weight" values in the SRV
records, as described by [RFC2782].
Douglass & Daboo Expires June 2, 2013 [Page 10]
Internet-Draft Timezone Service Protocol November 2012
Example: service record for server without transport layer security
_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.
4.2.1.2. Timezone Service TXT records
When SRV RRs are used to advertise a timezone 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
[I-D.cheshire-dnsext-dns-sd] 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.
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 next.
Example: text record for service with transport layer security
_timezones._tcp TXT path=/timezones
4.2.1.3. Timezone Service Well-Known URI
A "well-known" URI [RFC5785] is registered by this specification for
the Timezone service, "timezone" (see Section 9). 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 a 301,
303, 307 response). Clients MUST handle HTTP redirects on the
".well-known" URI. Servers MUST NOT locate the actual timezone
service endpoint at the ".well-known" URI as per Section 1.1 of
[RFC5785].
Servers SHOULD set an appropriate Cache-Control header value (as per
Section 14.9 of [RFC2616]) in the redirect response to ensure caching
occurs or does not occur 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 a "no-cache"
value would be used.
To facilitate "context path's" that might differ from user to user,
Douglass & Daboo Expires June 2, 2013 [Page 11]
Internet-Draft Timezone Service Protocol November 2012
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 only after a successful authentication by the
client).
4.2.1.3.1. Example: well-known URI redirects to actual context path
A Timezone server has a "context path" that is "/servlet/timezone".
The client will use "/.well-known/timezone" as the path for the
service process after it has first found the FQDN and port number via
an SRV lookup or via manual entry of information by the user from
which the client can parse suitable information. 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 using the path "/servlet/timezone". The client would
then "follow" this redirect to the new resource and continue making
HTTP requests there.
4.2.2. Initial Synchronization of All Timezones
When a secondary service or a client wishing to cache all timezone
data first starts or wishes to do a full refresh it synchronizes with
another server by first issuing a list action with returnall="true".
The client should preserve the returned datestamp for subsequent use.
Each timezone in the returned list can then be fetched and stored
locally. In addition a mapping of aliases to timezones can be built.
4.2.3. Subsequent Synchronization of All Timezones
Periodically a secondary service or a client caching all timezone
data needs to synchronize with another server. To do so it should
issue a list action with the changedsince parameter set to the value
of the datestamp returned at the last synchronization. The client
should again preserve the returned datestamp for subsequent use.
Each timezone in the returned list can then be fetched and stored
locally.
Note, this process makes no provision for handling deleted timezones.
In general it is bad practice to delete timezones as they may now be
in use by consumers of timezone data.
5. Request Parameters
All requests require the "action" request-URI parameter to define
what action is required of the server.
Douglass & Daboo Expires June 2, 2013 [Page 12]
Internet-Draft Timezone Service Protocol November 2012
Servers MUST support the following request-URI parameters.
5.1. "action" Parameter
Name: action
Description: Specify the action to be carried out.
Value: Any IANA registered action name.
5.2. "format" Parameter
Name: format
Description: Specify the format for the timezone data returned by
the server as a standard MIME [RFC2046] media-type. If absent the
iCalendar [RFC5545] format will be returned with the timezones
contained within a "VCALENDAR" object (i.e., a default media-type
of "text/calendar").
Value: A MIME [RFC2046] media-type. The server MUST support the
following values:
text/calendar: Return data as "VTIMEZONE" components embedded in
a "VCALENDAR" object as per [RFC5545].
application/calendar+xml: Return data using the XML
representation of iCalendar data as per iCalendar-in-XML
[RFC6321].
application/calendar+json: Return data using the JSON
representation of iCalendar data as per iCalendar-in-JSON.
5.3. "changedsince" Parameter
Name: changedsince
Description: Specify the timestamp for a conditional "list" or
"expand" action in order to restrict the results to only changes
since the given timestamp (see Section 6.2).
Value: An [RFC3339] UTC date-time value, typically a value returned
in a previous "dtstamp" value.
Douglass & Daboo Expires June 2, 2013 [Page 13]
Internet-Draft Timezone Service Protocol November 2012
5.4. "start" Parameter
Name: start
Description: Specify the inclusive start of a period.
Value: An [RFC3339] full-date or UTC date-time value. If an "end"
parameter is also present, then both the "start" and "end" values
MUST have the same full-date or date-time value types.
5.5. "end" Parameter
Name: end
Description: Specify the exclusive end of a period.
Value: An [RFC3339] full-date or UTC date-time value. If an "end"
parameter is also present, then both the "start" and "end" values
MUST have the same full-date or date-time value types.
5.6. "lang" Parameter
Name: lang
Description: Specify the language in which locale specific values
are to be returned. e.g., when fetching display names, if a
language is specified, only display names for that language will
be returned.
Value: The value follows the specifications in [RFC5646].
5.7. "returnall" Parameter
Name: returnall
Description: If present indicates that all timezones should be
returned. When fetching the list of timezones the default action
is to omit inactive timezones. The inclusion of this parameter
causes inactive timezones to be returned in the list (see
Section 6.2).
Value: This parameter takes no value.
5.8. "tzid" Parameter
Douglass & Daboo Expires June 2, 2013 [Page 14]
Internet-Draft Timezone Service Protocol November 2012
Name: tzid
Description: This parameter is used to identify a timezone to be
targeted by an action.
Value: A timezone identifier or alias. In some cases the special
value "*" is used to indicate that all timezones should be
matched.
5.9. "name" Parameter
Name: name
Description: This parameter is used to specify a name for queries.
Value: A timezone identifier, alias or localized name. This
parameter is used when searching for matching specifications.
6. Actions
Servers MUST support the following actions.
6.1. "capabilities" Action
Name: 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:
action REQUIRED, value MUST be "capabilities"
Response A JSON object containing an "info" member and an "actions"
member, see Section 7.1.
6.1.1. Example: Get Capabilities
In this example the client requests the server capabilities.
>> Request <<
GET /?action=capabilities HTTP/1.1
Host: tz.example.com
>> Response <<
Douglass & Daboo Expires June 2, 2013 [Page 15]
Internet-Draft Timezone Service Protocol November 2012
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
{
"info": {
"primary-source": "Olson:2011m",
"contact": "mailto:tzs@example.org",
},
"actions": [
{
"name": "list",
"parameters": [
{
"name": "lang",
"required": false,
"multi": true
},
{
"name": "changedsince",
"required": false,
"multi": false
},
{
"name": "returnall",
"required": false,
"multi": false
}
]
},
{
"name": "get",
"parameters": [
{
"name": "format",
"required": false,
"multi": false,
"values": [
"text/calendar",
"application/calendar+xml",
"application/calendar+json"
]
},
{
"name": "lang",
Douglass & Daboo Expires June 2, 2013 [Page 16]
Internet-Draft Timezone Service Protocol November 2012
"required": false,
"multi": true
},
{
"name": "tzid",
"required": true,
"multi": true,
},
{
"name": "returnall",
"required": false,
"multi": false,
}
]
},
{
"name": "expand",
"parameters": [
{
"name": "tzid",
"required": true,
"multi": true,
},
{
"name": "start",
"required": false,
"multi": false
},
{
"name": "end",
"required": false,
"multi": false,
}
]
},
{
"name":"capabilities",
"parameters": []
},
]
}
Douglass & Daboo Expires June 2, 2013 [Page 17]
Internet-Draft Timezone Service Protocol November 2012
6.2. "list" Action
Name: list
Description: This action lists all non alias timezone identifiers,
in summary format, with aliases and optional localized data. In
addition, it returns a timestamp which is the current server last
modification value.
Parameters:
action REQUIRED, value MUST be "list"
lang=<lang-code> OPTIONAL, but MAY occur multiple times.
Specifies the language or languages for localized information.
returnall OPTIONAL, but MUST occur only once. If present,
indicates that all, including inactive, timezones should be
returned in the response. The JSON "inactive" member will flag
those timezones no longer in use.
changedsince OPTIONAL, but MUST occur only once. If present,
limits the response to timezones changed since the given
timestamp. MUST NOT be specified with the tzid parameter.
tzid=<identifier> OPTIONAL, and MAY occur once or more. If
specified identifies timezone(s) for which information is to be
returned. If this parameter is specified changedsince MUST NOT
be specified.
If tzid is specified the dtstamp element will be returned in
the response. This dtstamp is for the entire set of data and
allows the client to determine if it should refresh its full
set.
Response: A JSON object containing a "dtstamp" member and a
"timezones" member, see Section 7.2.
Douglass & Daboo Expires June 2, 2013 [Page 18]
Internet-Draft Timezone Service Protocol November 2012
6.2.1. Example: List timezone identifiers
In this example the client requests the timezone identifiers and in
addition requests that the US-English local names be returned.
>> Request <<
GET /?action=list&lang=en_US 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
{
"dtstamp": "2009-10-11T09:32:11Z",
"timezones": [
{
"tzid": "America/New_York",
"last-modified": "2009-09-17T01:39:34Z",
"aliases":["US/Eastern"],
"local-names": [
{
"name": "America/New_York",
"lang": "en_US"
}
]
},
...
]
}
6.3. "get" Action
Name: get
Description: This action returns a timezone. If a single timezone
is specified the response MUST contain an ETag response header
field indicating the current value of the strong entity tag of the
timezone resource.
If the identifier is actually an alias to a canonical name the
server will return the specification associated with the canonical
name. The "substitute-alias" parameter specifies whether or not
the alias is to be substituted for the canonical identifier in the
Douglass & Daboo Expires June 2, 2013 [Page 19]
Internet-Draft Timezone Service Protocol November 2012
resulting timezone data.
Parameters:
action REQUIRED, value MUST be "get"
format=<media-type> OPTIONAL, but MUST occur only once. Return
information using the specified media-type. In the absence of
this parameter, the value "text/calendar" MUST be assumed.
lang=<lang-code> OPTIONAL, but MAY occur multiple times. If
present, specifies the language or languages for localized
information.
tzid=<identifier> REQUIRED, and MUST occur only once. Identifies
the timezone for which information is returned. The server
MUST return an Etag header. Alternatively, if a value of "*"
is given, returns information for all timezones. The "*"
option will typically be used by servers that wish to retrieve
the entire set of timezones supported by another server to re-
synchronize their entire data cache. Clients will typically
only retrieve individual timezone data on a case-by-case basis.
substitute-alias=<true|false> OPTIONAL and defaults to false. If
true and the tzid is an alias it will replace the tzid in the
returned specification. If false, the returned specification
will have the canonical identifier.
Response: A document containing all the requested timezone data in
the format specified.
Douglass & Daboo Expires June 2, 2013 [Page 20]
Internet-Draft Timezone Service Protocol November 2012
6.3.1. Example: Get timezone
In this example the client requests the timezone with a specific
timezone identifier to be returned
>> Request <<
GET /?action=get&tzid=America/New_York
&format=text/calendar HTTP/1.1
Host: tz.example.com
>> 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
...
END:VTIMEZONE
END:VCALENDAR
6.4. "expand" Action
Name: expand
Description: This action expands the specified timezone into a list
of onset start date/time and UTC offsets. The response MUST
contain an ETag response header field indicating the current value
of the strong entity tag for the expanded data.
Parameters:
action REQUIRED, value MUST be "expand"
tzid=<identifier> REQUIRED, but MUST only occur once. Identifies
the timezone for which information is returned. The value "*",
which has a special meaning in the "get" action, is not
supported by this action.
lang=<lang-code> OPTIONAL, but MAY occur multiple times. If
present, specifies the language or languages for localized
information.
Douglass & Daboo Expires June 2, 2013 [Page 21]
Internet-Draft Timezone Service Protocol November 2012
start=date or date-time: OPTIONAL, but MUST occur only once. If
present, specifies the start of the period of interest. If
omitted, the current year is assumed.
end=date or date-time: OPTIONAL, but MUST occur only once. If
present, specifies the end of the period of interest. If
omitted, the current year + 10 is assumed. A
changedsince OPTIONAL, but MUST occur only once. If present, its
value MUST be taken from the "dtstamp" result of a previous
expand result. If the targetted timezone has not changed over
the expansion range queried in the request, then the server MUT
return a 304 HTTP status response.
Response: A JSON object containing a "dtstamp" member and an
"observances" member, see Section 7.3.
Douglass & Daboo Expires June 2, 2013 [Page 22]
Internet-Draft Timezone Service Protocol November 2012
6.4.1. Example: Expanded JSON Data Format
In this example the client requests a timezone in the expanded form.
>> Request <<
GET /?action=expand&tzid=America/New_York 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
ETag: "123456789-000-111"
{
"dtstamp": "2009-10-11T09:32:11Z",
"observances": [
{
"name": "Daylight",
"onset": "2008-03-09T07:00:00Z",
"utc-offset-from": -18000,
"utc-offset-to": -14400
},
{
"name": "Standard",
"onset": "2008-11-02T07:00:00Z",
"utc-offset-from": -14400,
"utc-offset-to": -18000
},
{
"name": "Daylight",
"onset": "2009-03-08T07:00:00Z",
"utc-offset-from": -18000,
"utc-offset-to": -14400
},
...
]
}
6.5. "find" Action
Douglass & Daboo Expires June 2, 2013 [Page 23]
Internet-Draft Timezone Service Protocol November 2012
Name: find
Description: This action allows a client to query the timezone
service for a matching identifier, alias or localized name.
Parameters:
action REQUIRED, value MUST be "find"
name=<text> REQUIRED, but MUST only occur once. Identifies the
name to search for. Only partial matching is supported.
lang=<lang-code> OPTIONAL, but MAY occur multiple times. If
present, specifies the language or languages for localized
information.
Response: The response has the same format as the "list" action,
with one result element per successful match, see Section 7.2.
6.5.1. Example: Find action
In this example the client asks for information about "America/
New_York".
>> Request <<
GET /?action=find&name=America/New_York 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
TBD
7. JSON Definitions
JSON members used by this specification are defined here using the
syntax in [I-D.newton-json-content-rules].
7.1. capabilities action response
JSON Content Rules for the JSON document returned for a
"capabilities" action request.
Douglass & Daboo Expires June 2, 2013 [Page 24]
Internet-Draft Timezone Service Protocol November 2012
; root object
root = {
info,
actions
}
; object containing service information
info "info" : {
primary_source / secondary_source,
contacts
}
; The source of the timezone data provided by a "primary" server
primary_source "primary-source" : string
; The timezone server from which data is provided by a "secondary"
; server
secondary_source "secondary-source" : uri
; Array of URIs providing contact details for the server
; administrator
contacts "contacts" : [ * :uri ]
; Array of actions supported by the server
actions "actions" : [ * action ]
; An action supported by the server
action : {
action_name,
action_params
}
; Name of the action
action_name "name" : string
; Array of request-URI query parameters supported by the action
action_params = "parameters" : [ * parameter ]
; Object defining an action parameter
parameter = {
param_name,
?param_required,
?param_multi,
?param_values
}
; Name of the parameter
Douglass & Daboo Expires June 2, 2013 [Page 25]
Internet-Draft Timezone Service Protocol November 2012
param_name "name" : string
; If true the parameter has to be present in the request-URI
; default is false
param_required "required" : boolean
; If true the parameter can occur more than once in the request-URI
; default is false
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
param_values "values" : [ * : string ]
7.2. list action response
JSON Content Rules for the JSON document returned for a "list" action
request.
; root object
root = {
dtstamp,
timezones
}
; Server generated timestamp used for synchronizing changes,
; [RFC3339] UTC value
dtstamp "dtstamp" : date-time
; Array of timezone objects
timezones "timezones" : [ * timezone ]
; Information about a timezone available on the server
timezone : {
tzid,
last_modified,
?inactive,
?aliases,
?local_names,
}
; Timezone identifier
tzid "tzid" : string
; Date/time when the timezone data was last modified
; [RFC3339] UTC value
last_modified "last-modified" : date-time
Douglass & Daboo Expires June 2, 2013 [Page 26]
Internet-Draft Timezone Service Protocol November 2012
; Indicates whether the timerzone is an inactive timezone
inactive "inactive" : boolean
; An array that lists the set of timezone identifier aliases
; available for the corresponding timezone
aliases "aliases" : [ * : string ]
; An array that lists the set of timezone identifier aliases
; available for the corresponding timezone
local_names "local-names" : [ * local_name ]
local_name = [lang, lname, ?pref]
; Language tag for the language of the associated name
lang : string
; Localized name
lname : string
; Indicates whether this is the preferred name for the associated
; language default: false
pref : boolean
Douglass & Daboo Expires June 2, 2013 [Page 27]
Internet-Draft Timezone Service Protocol November 2012
7.3. expand action response
JSON Content Rules for the JSON document returned for a "expand"
action request.
; root object
root = {
dtstamp,
observances
}
; Server generated timestamp used for synchronizing changes
; [RFC3339] UTC value
dtstamp "dtstamp" : date-time
; Array of timezone objects
observances "observances" : [ * observances ]
; Information about a timezone available on the server
observance : {
oname,
?olocal_names,
onset,
utc_offset_from,
utc_offset_to
}
; Observance name
oname "name" : string
; Array of localized observance names
olocal_names "local-names" : [ * :string]
; The local time at which the observance takes effect
; [RFC3339] value modified to exclude "time-offset" part
onset "onset" : date-time
; The UTC offset in seconds before the start of this observance
utc_offset_from "utc-offset-from" : integer
; The UTC offset in seconds at and after the start of this observance
utc_offset_to "utc-offset-to" : integer
Douglass & Daboo Expires June 2, 2013 [Page 28]
Internet-Draft Timezone Service Protocol November 2012
7.4. error response
JSON Content Rules for the JSON document returned when an error
occurs.
; root object
root = {
error,
?description
}
; Error code
error "error" : integer
; Description of the error
description "description" : string
8. Security Considerations
Timezone 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 timezone data is used. Servers
providing a timezone service MUST support HTTP over Transport Layer
Security (TLS) (as defined by [RFC2818]) with a valid certificate.
Clients and servers making use of a timezone service SHOULD use HTTP
over TLS and verify the authenticity of the service being used before
accepting and using any timezone data from that source.
Clients that support transport layer security as defined by [RFC2818]
SHOULD try the "_timezones" service first before trying the
"_timezone" service. Clients MUST follow the certificate
verification process specified in [RFC6125].
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 matches the original service
domain that was queried. If the target FQDN is not in the queried
domain, clients SHOULD verify with the user that the SRV target FQDN
is suitable for use before executing any connections to the host.
Timezone servers SHOULD protect themselves against errant 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.3
Douglass & Daboo Expires June 2, 2013 [Page 29]
Internet-Draft Timezone Service Protocol November 2012
9. IANA Considerations
This defines a new registry of "actions" for the timezone service
protocol, and defines a "well-known" URI using the registration
procedure and template from Section 5.1 of [RFC5785], and creates two
new SRV service label aliases.
9.1. Service Actions Registration
This section defines the process to register new or modified timezone
service actions with IANA.
9.1.1. Service Actions Registration Procedure
The IETF will create a mailing list, timezone-service@ietf.org, which
can be used for public discussion of timezone service actions
proposals prior to registration. Use of the mailing list is strongly
encouraged. The IESG will appoint a designated expert who will
monitor the timezone-service@ietf.org mailing list and review
registrations.
Registration of new timezone service actions MUST be reviewed by the
designated expert and published in an RFC. A Standard Tracks RFC is
REQUIRED for the registration of new timezone service actions. A
Standard Tracks RFC is also REQUIRED for changes to actions
previously documented in a Standard Tracks RFC.
The registration procedure begins when a completed registration
template, defined in the sections below, is sent to
timezone-service@ietf.org and iana@iana.org. The designated expert
is expected to tell IANA and the submitter of the registration within
two weeks whether the registration is approved, approved with minor
changes, or rejected with cause. When a registration is rejected
with cause, it can be re-submitted if the concerns listed in the
cause are addressed. Decisions made by the designated expert can be
appealed to the IESG Applications Area Director, then to the IESG.
They follow the normal appeals procedure for IESG decisions.
9.1.2. Registration Template for Actions
An action is defined by completing the following template.
Name: The name of the action. This is also the value of the
"action" parameter used in timezone service requests.
Douglass & Daboo Expires June 2, 2013 [Page 30]
Internet-Draft Timezone Service Protocol November 2012
Description: A general description of the action, its purpose, etc.
Parameters: A list of allowed request parameters, indicating whether
they are "REQUIRED" or "OPTIONAL" and whether they can occur only
once or multiple times.
Response The nature of the response to the HTTP request, e.g., what
format the response data is in.
9.1.3. Registration Template for Action Parameters
An action parameter is defined by completing the following template.
Name: The name of the parameter.
Description: A general description of the parameter, its purpose,
etc.
Value: The format of the parameter value, or an indication that the
parameter has no value.
9.2. Initial Timezone Service Registries
The IANA is requested to create and maintain the following registries
for timezone service actions with pointers to appropriate reference
documents.
9.2.1. Actions Registry
The following table is to be used to initialize the actions registry.
+--------------+---------+----------------------+
| Action Name | Status | Reference |
+--------------+---------+----------------------+
| capabilities | Current | RFCXXXX, Section 6.1 |
| list | Current | RFCXXXX, Section 6.2 |
| get | Current | RFCXXXX, Section 6.3 |
| expand | Current | RFCXXXX, Section 6.4 |
| find | Current | RFCXXXX, Section 6.5 |
+--------------+---------+----------------------+
9.2.2. Action Parameters Registry
The following table is to be used to initialize the parameters
registry.
Douglass & Daboo Expires June 2, 2013 [Page 31]
Internet-Draft Timezone Service Protocol November 2012
+--------------+---------+----------------------+
| Parameter | Status | Reference |
+--------------+---------+----------------------+
| action | Current | RFCXXXX, Section 5.1 |
| changedsince | Current | RFCXXXX, Section 5.3 |
| end | Current | RFCXXXX, Section 5.5 |
| format | Current | RFCXXXX, Section 5.2 |
| lang | Current | RFCXXXX, Section 5.6 |
| returnall | Current | RFCXXXX, Section 5.7 |
| start | Current | RFCXXXX, Section 5.4 |
| tzid | Current | RFCXXXX, Section 5.8 |
+--------------+---------+----------------------+
9.3. timezone Well-Known URI Registration
URI suffix: timezone
Change controller: IETF.
Specification document(s): This RFC.
Related information:
9.4. Service Name Registrations
This document registers two new service names as per [RFC6335]. Both
are defined within this document.
9.4.1. timezone Service Name Registration
Service Name: timezone
Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Timezone Service Protocol - non-TLS
Reference: [draft-douglass-timezone-service]
Assignment Note: This is an extension of the http service. Defined
TXT keys: path=<context path>
Douglass & Daboo Expires June 2, 2013 [Page 32]
Internet-Draft Timezone Service Protocol November 2012
9.4.2. timezones Service Name Registration
Service Name: timezones
Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Timezone Service Protocol - over TLS
Reference: [draft-douglass-timezone-service]
Assignment Note: This is an extension of the https service. Defined
TXT keys: path=<context path>
10. Acknowledgements
The authors would like to thank the members of the Calendaring and
Scheduling Consortium's Timezone Technical Committee and the
following individuals for contributing their ideas and support: Steve
Allen, John Haug, Ciny Joy, Bryan Keller, Andrew McMillan, Arnaud
Quillaud, Jose Edvaldo Saraiva.
The authors would also like to thank the Calendaring and Scheduling
Consortium for advice with this specification.
11. Normative References
[I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", draft-cheshire-dnsext-dns-sd-11 (work in
progress), December 2011.
[I-D.kewisch-et-al-icalendar-in-json]
Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON
format for iCalendar",
draft-kewisch-et-al-icalendar-in-json-00 (work in
progress), November 2012.
[I-D.newton-json-content-rules]
Newton, A., "A Language for Rules Describing JSON
Content", draft-newton-json-content-rules-00 (work in
progress), September 2012.
Douglass & Daboo Expires June 2, 2013 [Page 33]
Internet-Draft Timezone Service Protocol November 2012
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", RFC 5545,
September 2009.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
April 2010.
[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, March 2011.
[RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML
Format for iCalendar", RFC 6321, August 2011.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Douglass & Daboo Expires June 2, 2013 [Page 34]
Internet-Draft Timezone Service Protocol November 2012
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, August 2011.
[RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the
Time Zone Database", BCP 175, RFC 6557, February 2012.
Appendix A. Changes for version 07
o Switched to JSON instead of XML and clean-ed up schema a little
bit.
o Added changedsince to expand action.
o Added find into registry table.
o Re-organized some sections.
Appendix B. Changes for version 06
o Refresh prior to last call
Appendix C. Changes for version 05
o Replaced reference to draft RFC with RFC6557 and RFC6125.
o New XML namespace contact.
o Templates for service name.
o Various typos fixed.
o More acknowledgements.
Appendix D. Changes for version 04
o Replaced reference to RFC4646 with reference to RFC5646
o New wording on polling.
Douglass & Daboo Expires June 2, 2013 [Page 35]
Internet-Draft Timezone Service Protocol November 2012
Appendix E. Changes for version 03
o Replaced erroneous reference to ISO3036 with reference to RFC4646
o Update reference to iCalendar in XML (RFC6321)
o More description of ids/aliases/names
o Add substitute-alias parameter for action=get
o Allow tzid on list
o Added name request parameter
o Added find action
Appendix F. Changes for version 02
o Missed definitions of the inactive element
o Restrict UtcOffsetFromType, UtcOffsetToType to a pattern - allow
seconds.
o Use restricted XML dateTime as base for onset
o Use restricted XML dateTime for lastmodified and dtstamp
o Note that 0 and 1 are valid values for an XML boolean.
o Set pref to a default value of false
o Server will now set tzid of aliased timezones to the alias name
o Remove returnaliases option
o Aliases should not have lang attribute - removed
o Add text on status codes and an error element
o Added capabilities info element containing source | primary-source
and contacts.
Douglass & Daboo Expires June 2, 2013 [Page 36]
Internet-Draft Timezone Service Protocol November 2012
Authors' Addresses
Michael Douglass
Rensselaer Polytechnic Institute
110 8th Street
Troy, NY 12180
USA
Email: douglm@rpi.edu
URI: http://www.rpi.edu/
Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
Email: cyrus@daboo.name
URI: http://www.apple.com/
Douglass & Daboo Expires June 2, 2013 [Page 37]