]> Rensselaer Polytechnic Institute

110 8th Street Troy NY 12180 USA douglm@rpi.edu http://www.rpi.edu/

Apple Inc.

1 Infinite Loop Cupertino CA 95014 USA cyrus@daboo.name http://www.apple.com/

Applications timezones calendaring scheduling This document defines a timezone service protocol that allows reliable, secure and fast delivery of timezone data to client systems such as calendaring and scheduling applications or operating systems.

Timezone data 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, as well as operating systems, critically rely on timezone data to determine the correct local time. As such they need to be kept up to date with changes to timezone data. 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 data to client systems. This protocol is based on HTTP using a REST style API, with JSON responses. This specification does not define the source of the timezone data. It is assumed that a reliable and accurate source is available. One such source is the IANA hosted timezone database. Discussion of this document should take place on the calsify mailing list calsify@ietf.org

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 .

The following terms with the given meanings are used throughout this document. Data that defines a single timezone, including an identifier, UTC offset values, and DST rules; A server implementing the Timezone Service Protocol defined by this specification; A globally unique name which identifies timezone data.

The overall process for the delivery of timezone data can be visualized via the diagram shown below.

The overall service is made up of several layers: Individuals, governments or organizations which provide information about timezones to the publishing process. There can be many contributors. 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. 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. 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. 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.

Timezone identifiers are unique names associated with each timezone, as defined by publishers. The iCalendar specification has a "TZID" property and parameter whose value is set to the corresponding timezone identifier, and used to identify timezones data and relate timezones to start and end dates in events, etc. This specification does not define what format of timezone identifiers should be used. It is possible that timezone 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) timezone identifier naming scheme is out of scope for this specification.

Timezone aliases map a name onto a timezone identifier. For example "US/Eastern" is usually mapped on to "America/New_York". Timezone aliases are typically used interchangeably with timezone identifiers when presenting information to users. A timezone service needs to maintain timezone alias mapping information, and expose that data to clients as well as allow clients to query for timezone data using aliases.

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 might need to maintain localized name information, for one or more chosen languages, as well as allow clients to query for timezone data using localized names.

The timezone service protocol uses HTTP 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 as defined in .

Timezone identifiers, aliases or localized 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.

The default format for returning timezone definitions is the iCalendar data format. In addition, the iCalendar-in-XML, and iCalendar-in-JSON representations are also available. The "format" request-URI parameter can be used to select which data format is returned.

Timezone data 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" change has occurred in the timezone data. Clients can use a conditional "list" action (see ), 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, typically once a day ought to be sufficient. See on expected client and server behavior regarding high request rates.

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

To enable a simple client implementation, servers SHOULD ensure that they provide or cache data for all commonly used timezones, from various publishers. That allows client implementations to configure a single server to get all timezone 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.

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. 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 object as per

This protocol is designed to be extensible through a standards based registration mechanism (see ). 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.

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.

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: Identifies a Timezone server that uses HTTP without transport layer security (). Identifies a Timezone server that uses HTTP with transport layer security (). Clients MUST honor "TTL", "Priority" and "Weight" values in the SRV records, as described by .

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.

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

A "well-known" URI is registered by this specification for the Timezone service, "timezone" (see ). 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. Servers MUST NOT locate the actual timezone service endpoint at the ".well-known" URI as per Section 1.1 of . Servers SHOULD set an appropriate Cache-Control header value (as per Section 14.9 of ) 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 a "no-cache" value would be used. To facilitate "context path's" that might differ from user to user, 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).

A Timezone 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 using the path "/servlet/timezone". The client would then "follow" this redirect to the new resource and continue making HTTP requests there.

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. The client would 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.

A secondary service or a client caching all timezone data needs to periodically synchronize with a server. To do so it would issue a "list" action with the "changedsince" parameter set to the value of the datestamp returned by the last synchronization. The client would 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 might still be in use by consumers of timezone data.

The "action" request-URI parameter MUST be included in all requests to define what action is required of the server. The following request-URI parameters are used with the various actions.

action Specify the action to be carried out. Any IANA registered action name (see ).

format Specify the format of the timezone data returned by the server as a standard MIME media-type. If absent, the iCalendar format will be returned with the timezones contained within a "VCALENDAR" object (i.e., a default media-type of "text/calendar"). A MIME media-type. The following values MAY be used, with servers advertising the values they do support via the "capabilities" action response (see ): Return data as "VTIMEZONE" components embedded in a "VCALENDAR" object as per . Return data using the XML representation of iCalendar data as per iCalendar-in-XML. Return data using the JSON representation of iCalendar data as per iCalendar-in-JSON.

changedsince Specify the timestamp for a conditional "list" (see ) or "expand" (see ) action in order to restrict the results to only changes since the given timestamp. An UTC date-time value, typically a value returned by a previous request.

start Specify the inclusive start of a period. An 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.

end Specify the exclusive end of a period. An 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.

lang Specify the language in which locale specific values are to be returned. e.g., if a language is specified, only localized names for that language would be returned. The value follows the specifications in .

tzid Specify a timezone to be targeted by an action. A timezone identifier or alias. In some cases the special value "*" is used to indicate that all timezones should be matched.

name Specify a name for queries. A timezone identifier, alias or localized name. This parameter is used when searching for matching timezones (see ).

Servers MUST support the following actions.

capabilities This action returns the capabilities of the server, allowing clients to determine if a specific feature has been deployed and/or enabled. REQUIRED with value "capabilities" A JSON object containing a "version" member, an "info" member, and an "actions" member, see . No specific code.

> Request << GET /?action=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, "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": "get", "parameters": [ { "name": "format", "required": false, "multi": false, "values": [ "text/calendar", "application/calendar+xml", "application/calendar+json" ] }, { "name": "lang", "required": false, "multi": true }, { "name": "tzid", "required": true, "multi": true, } ] }, { "name": "expand", "parameters": [ { "name": "tzid", "required": true, "multi": true, }, { "name": "start", "required": false, "multi": false }, { "name": "end", "required": false, "multi": false, } ] }, { "name": "find", "parameters": [ { "name": "name", "required": true, "multi": false, }, { "name": "lang", "required": false, "multi": true } ] }, { "name":"capabilities", "parameters": [] }, ] } ]]>

list This action lists all 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. REQUIRED with value "list" OPTIONAL, but MAY occur multiple times. OPTIONAL, but MUST occur only once. MUST NOT be present if the "tzid" parameter is present. OPTIONAL, and MAY occur multiple times. MUST NOT be present if the "tzid" parameter is present. If "tzid" is specified, a "dtstamp" member MUST be returned in the response. The value of the "dtstamp" member corresponds to the entire set of data and allows the client to determine if it should refresh its full set. A JSON object containing a "dtstamp" member and a "timezones" member, see . The "changedsince" query parameter is not present, or has an incorrect value, or appears more than once. The "tzid" query parameter is present along with the "changedsince", or has an incorrect value.

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" } ] }, ... ] } ]]>

get 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 a timezone alias, the server will return the matching timezone data. The "substitute-alias" parameter specifies whether or not the alias name is to be substituted for the timezone identifier in the resulting timezone data. REQUIRED with value "get" OPTIONAL, but MUST occur only once. OPTIONAL, but MAY occur multiple times. REQUIRED, and MUST occur only once. If a value of "*" is given, returns data 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. OPTIONAL and defaults to false. If true and the "tzid" value is a timezone alias, it will replace the timezone identifier in the returned timezone data. If false, the returned timezone data will use the normal timezone identifier. A document containing all the requested timezone data in the format specified. The "tzid" query parameter is not present, or appears more than once. The "tzid" query parameter value does not map to a timezone identifier known to the server.

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 ]]>

expand 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. REQUIRED with value "expand" REQUIRED, but MUST only occur once. The value "*" is not supported by this action. OPTIONAL, but MAY occur multiple times. OPTIONAL, but MUST occur only once. If present, specifies the start of the period of interest. If omitted, the current year is assumed. OPTIONAL, but MUST occur only once. If present, specifies the end of the period of interest. If omitted, the current year + 10 is assumed. OPTIONAL, but MUST occur only once. If present, its value MUST be taken from the "dtstamp" result of a previous expand result. If the targeted timezone has not changed over the expansion range queried in the request, then the server MUST return a 304 HTTP status response. A JSON object containing a "dtstamp" member and an "observances" member, see . The "tzid" query parameter is not present, or appears more than once. The "tzid" query parameter value does not map to a timezone identifier known to the server. The "start" query parameter has an incorrect value, or appears more than once. The "end" query parameter has an incorrect value, or appears more than once, or has a value less than our equal to the "start" query parameter. The "changedsince" query parameter has an incorrect value, or appears more than once.

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 }, ... ] } ]]>

find This action allows a client to query the timezone service for a matching identifier, alias or localized name, using a sub-string match against the names known to the server. REQUIRED with value "find" REQUIRED, but MUST only occur once. OPTIONAL, but MAY occur multiple times. The response has the same format as the "list" action, with one result object per successful match, see . The "name" query parameter is not present, or appears more than once.

In this example the client asks for data about the timezone "America/New_York". > Request << GET /?action=find&name=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 { "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" } ] }, { "tzid": "America/Detroit", "last-modified": "2009-09-17T01:39:34Z", "aliases":["US/Eastern"], "local-names": [ { "name": "America/Detroit", "lang": "en_US" } ] }, ... ] } ]]>

JSON members used by this specification are defined here using the syntax in . Clients MUST ignore any JSON members they do not expect.

JSON Content Rules for the JSON document returned for a "capabilities" action request.

JSON Content Rules for the JSON document returned for a "list" action request.

JSON Content Rules for the JSON document returned for a "expand" action request.

JSON Content Rules for the JSON document returned when an error occurs.

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 ) 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 SHOULD try the "_timezones" service first before trying the "_timezone" service. Clients MUST follow the certificate verification process specified in . 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

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 , and creates two new SRV service label aliases.

This section defines the process to register new or modified timezone service actions with IANA.

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.

An action is defined by completing the following template. The name of the action. This is also the value of the "action" parameter used in timezone service requests. A general description of the action, its purpose, etc. A list of allowed request parameters, indicating whether they are "REQUIRED" or "OPTIONAL" and whether they can occur only once or multiple times. The nature of the response to the HTTP request, e.g., what format the response data is in.

An action parameter is defined by completing the following template. The name of the parameter. A general description of the parameter, its purpose, etc. The format of the parameter value, or an indication that the parameter has no value.

The IANA is requested to create and maintain the following registries for timezone service actions with pointers to appropriate reference documents.

The following table is to be used to initialize the actions registry. Action Name Status Reference capabilities Current RFCXXXX, list Current RFCXXXX, get Current RFCXXXX, expand Current RFCXXXX, find Current RFCXXXX,

The following table is to be used to initialize the parameters registry. Parameter Status Reference action Current RFCXXXX, changedsince Current RFCXXXX, end Current RFCXXXX, format Current RFCXXXX, lang Current RFCXXXX, start Current RFCXXXX, tzid Current RFCXXXX,

timezone IETF. This RFC.

This document registers two new service names as per . Both are defined within this document.

timezone TCP IESG <iesg@ietf.org> IETF Chair <chair@ietf.org> Timezone Service Protocol - non-TLS [draft-douglass-timezone-service] This is an extension of the http service. Defined TXT keys: path=<context path>

timezones TCP IESG <iesg@ietf.org> IETF Chair <chair@ietf.org> Timezone Service Protocol - over TLS [draft-douglass-timezone-service] This is an extension of the https service. Defined TXT keys: path=<context path>

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, and Jose Edvaldo Saraiva. The authors would also like to thank the Calendaring and Scheduling Consortium for advice with this specification.

&I-D.newton-json-content-rules; &I-D.kewisch-et-al-icalendar-in-json; &RFC2046; &RFC2119; &RFC2616; &RFC2782; &RFC2818; &RFC3339; &RFC4627; &RFC5246; &RFC5545; &RFC5646; &RFC5785; &RFC6125; &RFC6321; &RFC6335; &RFC6557; &RFC6763;

Changes for -08 Editorial changes. Fixed JSON content rule syntax. Added a "version" to capabilities. Changed "error" member to a string. Added error codes. Updated reference. Removed inactive timezone feature and returnall parameter. Changes for -07 Switched to JSON instead of XML and clean-ed up schema a little bit. Added changedsince to expand action. Added find into registry table. Re-organized some sections. Changes for -06 Refresh prior to last call Changes for -05 Replaced reference to draft RFC with RFC6557 and RFC6125. New XML namespace contact. Templates for service name. Various typos fixed. More acknowledgements. Changes for -04 Replaced reference to RFC4646 with reference to RFC5646 New wording on polling. Changes for -03 Replaced erroneous reference to ISO3036 with reference to RFC4646 Update reference to iCalendar in XML (RFC6321) More description of ids/aliases/names Add substitute-alias parameter for action=get Allow tzid on list Added name request parameter Added find action Changes for -02 Missed definitions of the inactive element Restrict UtcOffsetFromType, UtcOffsetToType to a pattern - allow seconds. Use restricted XML dateTime as base for onset Use restricted XML dateTime for lastmodified and dtstamp Note that 0 and 1 are valid values for an XML boolean. Set pref to a default value of false Server will now set tzid of aliased timezones to the alias name Remove returnaliases option Aliases should not have lang attribute - removed Add text on status codes and an error element Added capabilities info element containing source | primary-source and contacts.