< draft-ietf-tzdist-service-09.txt		draft-ietf-tzdist-service-10.txt >
	Network Working Group M. Douglass		Network Working Group M. Douglass
	Internet-Draft Spherical Cow Group		Internet-Draft Spherical Cow Group
	Intended status: Standards Track C. Daboo		Intended status: Standards Track C. Daboo
	Expires: December 31, 2015 Apple		Expires: January 23, 2016 Apple
	June 29, 2015		July 22, 2015
	Time Zone Data Distribution Service		Time Zone Data Distribution Service
	draft-ietf-tzdist-service-09		draft-ietf-tzdist-service-10
	Abstract		Abstract
	This document defines a time zone data distribution service that		This document defines a time zone data distribution service that
	allows reliable, secure and fast delivery of time zone data and leap		allows reliable, secure and fast delivery of time zone data and leap
	second rules to client systems such as calendaring and scheduling		second rules to client systems such as calendaring and scheduling
	applications or operating systems.		applications or operating systems.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 31, 2015.		This Internet-Draft will expire on January 23, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	4.1.3. Time Zone Localization . . . . . . . . . . . . . . . 12		4.1.3. Time Zone Localization . . . . . . . . . . . . . . . 12
	4.1.4. Conditional Time Zone Requests . . . . . . . . . . . 12		4.1.4. Conditional Time Zone Requests . . . . . . . . . . . 12
	4.1.5. Expanded Time Zone Data . . . . . . . . . . . . . . . 14		4.1.5. Expanded Time Zone Data . . . . . . . . . . . . . . . 14
	4.1.6. Server Requirements . . . . . . . . . . . . . . . . . 14		4.1.6. Server Requirements . . . . . . . . . . . . . . . . . 14
	4.1.7. Error Responses . . . . . . . . . . . . . . . . . . . 14		4.1.7. Error Responses . . . . . . . . . . . . . . . . . . . 14
	4.1.8. Extensions . . . . . . . . . . . . . . . . . . . . . 14		4.1.8. Extensions . . . . . . . . . . . . . . . . . . . . . 14
	4.2. Client Guidelines . . . . . . . . . . . . . . . . . . . . 14		4.2. Client Guidelines . . . . . . . . . . . . . . . . . . . . 14
	4.2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 14		4.2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 14
	4.2.1.1. Time Zone Data Distribution Service SRV Service		4.2.1.1. Time Zone Data Distribution Service SRV Service
	Labels . . . . . . . . . . . . . . . . . . . . . 15		Labels . . . . . . . . . . . . . . . . . . . . . 15
	4.2.1.2. Time Zone Data Distribution Service TXT records . 15		4.2.1.2. Time Zone Data Distribution Service TXT Records . 15
	4.2.1.3. Time Zone Data Distribution Service Well-Known		4.2.1.3. Time Zone Data Distribution Service Well-Known
	URI . . . . . . . . . . . . . . . . . . . . . . . 16		URI . . . . . . . . . . . . . . . . . . . . . . . 16
	4.2.1.3.1. Example: well-known URI redirects to actual		4.2.1.3.1. Example: well-known URI redirects to actual
	context path . . . . . . . . . . . . . . . . 17		context path . . . . . . . . . . . . . . . . 17
	4.2.2. Synchronization of Time Zones . . . . . . . . . . . . 17		4.2.2. Synchronization of Time Zones . . . . . . . . . . . . 17
	4.2.2.1. Initial Synchronization of All 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.2. Subsequent Synchronization of All Time Zones . . 17
	4.2.2.3. Synchronization with Pre-Existing Time Zone Data 18		4.2.2.3. Synchronization with Pre-Existing Time Zone Data 18
	5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	5.1. "capabilities" Action . . . . . . . . . . . . . . . . . . 18		5.1. "capabilities" Action . . . . . . . . . . . . . . . . . . 18
	5.1.1. Example: Get Capabilities . . . . . . . . . . . . . . 19		5.1.1. Example: get capabilities . . . . . . . . . . . . . . 19
	5.2. "list" Action . . . . . . . . . . . . . . . . . . . . . . 21		5.2. "list" Action . . . . . . . . . . . . . . . . . . . . . . 21
	5.2.1. Example: List time zone identifiers . . . . . . . . . 22		5.2.1. Example: list time zone identifiers . . . . . . . . . 22
	5.3. "get" Action . . . . . . . . . . . . . . . . . . . . . . 23		5.3. "get" Action . . . . . . . . . . . . . . . . . . . . . . 23
	5.3.1. Example: Get time zone data . . . . . . . . . . . . . 24		5.3.1. Example: get time zone data . . . . . . . . . . . . . 24
	5.3.2. Example: Conditional Get time zone data . . . . . . . 24		5.3.2. Example: conditional get time zone data . . . . . . . 24
	5.3.3. Example: Get time zone data using a time zone alias . 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.4. Example: get truncated time zone data . . . . . . . . 26
	5.3.5. Example: Request for a non-existent time zone . . . . 27		5.3.5. Example: request for a non-existent time zone . . . . 27
	5.4. "expand" Action . . . . . . . . . . . . . . . . . . . . . 28		5.4. "expand" Action . . . . . . . . . . . . . . . . . . . . . 28
	5.4.1. Example: Expanded JSON Data Format . . . . . . . . . 29		5.4.1. Example: expanded JSON data format . . . . . . . . . 29
	5.5. "find" Action . . . . . . . . . . . . . . . . . . . . . . 30		5.5. "find" Action . . . . . . . . . . . . . . . . . . . . . . 30
	5.5.1. Example: Find action . . . . . . . . . . . . . . . . 32		5.5.1. Example: find action . . . . . . . . . . . . . . . . 32
	5.6. "leapseconds" Action . . . . . . . . . . . . . . . . . . 34		5.6. "leapseconds" Action . . . . . . . . . . . . . . . . . . 34
	5.6.1. Example: Get leapsecond information . . . . . . . . . 34		5.6.1. Example: get leapsecond information . . . . . . . . . 34
	6. JSON Definitions . . . . . . . . . . . . . . . . . . . . . . 35		6. JSON Definitions . . . . . . . . . . . . . . . . . . . . . . 35
	6.1. capabilities action response . . . . . . . . . . . . . . 36		6.1. capabilities Action Response . . . . . . . . . . . . . . 36
	6.2. list/find action response . . . . . . . . . . . . . . . . 39		6.2. list/find Action Response . . . . . . . . . . . . . . . . 39
	6.3. expand action response . . . . . . . . . . . . . . . . . 40		6.3. expand Action Response . . . . . . . . . . . . . . . . . 40
	6.4. leapseconds action response . . . . . . . . . . . . . . . 42		6.4. leapseconds Action Response . . . . . . . . . . . . . . . 42
	7. New iCalendar Properties . . . . . . . . . . . . . . . . . . 42		7. New iCalendar Properties . . . . . . . . . . . . . . . . . . 42
	7.1. Time Zone Upper Bound . . . . . . . . . . . . . . . . . . 42		7.1. Time Zone Upper Bound . . . . . . . . . . . . . . . . . . 42
	7.2. Time Zone Identifier Alias Property . . . . . . . . . . . 43		7.2. Time Zone Identifier Alias Property . . . . . . . . . . . 43
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 44		8. Security Considerations . . . . . . . . . . . . . . . . . . . 44
	9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 45		9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 45
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
	10.1. Service Actions Registration . . . . . . . . . . . . . . 47		10.1. Service Actions Registration . . . . . . . . . . . . . . 47
	10.1.1. Service Actions Registration Procedure . . . . . . . 47		10.1.1. Service Actions Registration Procedure . . . . . . . 47
	10.1.2. Registration Template for Actions . . . . . . . . . 48		10.1.2. Registration Template for Actions . . . . . . . . . 48
	10.1.3. Actions Registry . . . . . . . . . . . . . . . . . . 49		10.1.3. Actions Registry . . . . . . . . . . . . . . . . . . 49
	10.2. timezone Well-Known URI Registration . . . . . . . . . . 49		10.2. timezone Well-Known URI Registration . . . . . . . . . . 49
	10.3. Service Name Registrations . . . . . . . . . . . . . . . 49		10.3. Service Name Registrations . . . . . . . . . . . . . . . 49
	10.3.1. timezone Service Name Registration . . . . . . . . . 50		10.3.1. timezone Service Name Registration . . . . . . . . . 50
	10.3.2. timezones Service Name Registration . . . . . . . . 50		10.3.2. timezones Service Name Registration . . . . . . . . 50
	10.4. tzdist Identifiers Registry . . . . . . . . . . . . . . 50		10.4. tzdist Identifiers Registry . . . . . . . . . . . . . . 50
	10.4.1. Registration of invalid-action error URN . . . . . . 51		10.4.1. Registration of invalid-action Error URN . . . . . . 51
	10.4.2. Registration of invalid-changedsince error URN . . . 51		10.4.2. Registration of invalid-changedsince Error URN . . . 51
	10.4.3. Registration of tzid-not-found error URN . . . . . . 52		10.4.3. Registration of tzid-not-found Error URN . . . . . . 52
	10.4.4. Registration of invalid-format error URN . . . . . . 52		10.4.4. Registration of invalid-format Error URN . . . . . . 52
	10.4.5. Registration of invalid-start error URN . . . . . . 52		10.4.5. Registration of invalid-start Error URN . . . . . . 52
	10.4.6. Registration of invalid-end error URN . . . . . . . 53		10.4.6. Registration of invalid-end Error URN . . . . . . . 53
	10.4.7. Registration of invalid-pattern error URN . . . . . 53		10.4.7. Registration of invalid-pattern Error URN . . . . . 53
	10.5. iCalendar Property Registrations . . . . . . . . . . . . 53		10.5. iCalendar Property Registrations . . . . . . . . . . . . 53
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
	12.1. Normative References . . . . . . . . . . . . . . . . . . 54		12.1. Normative References . . . . . . . . . . . . . . . . . . 54
	12.2. Informative References . . . . . . . . . . . . . . . . . 56		12.2. Informative References . . . . . . . . . . . . . . . . . 56
	Appendix A. Change History (to be removed prior to publication		Appendix A. Change History (to be removed prior to publication
	as an RFC) . . . . . . . . . . . . . . . . . . . . . 56		as an RFC) . . . . . . . . . . . . . . . . . . . . . 56
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62
	1. Introduction		1. Introduction
	skipping to change at page 10, line 50 ¶		skipping to change at page 10, line 50 ¶
	The time zone data distribution service protocol uses HTTP [RFC7230]		The time zone data distribution service protocol uses HTTP [RFC7230]
	for query and delivery of time zone data and meta-data, and leap		for query and delivery of time zone data and meta-data, and leap
	second information. The interactions with the HTTP server can be		second information. The interactions with the HTTP server can be
	broken down into a set of "actions" that define the overall function		broken down into a set of "actions" that define the overall function
	being requested (see Section 5). Each action targets a specific HTTP		being requested (see Section 5). Each action targets a specific HTTP
	resource using the GET method, with various request-URI parameters		resource using the GET method, with various request-URI parameters
	altering the behavior as needed.		altering the behavior as needed.
	The HTTP resources used for requests will be identified via URI		The HTTP resources used for requests will be identified via URI
	templates [RFC6570]. The overall time zone distribution service has		templates [RFC6570]. The overall time zone data distribution service
	a "context path" request-URI defined as "{/service-prefix}". This		has a "context path" request-URI template defined as "{/service-
	"root" prefix is discovered by the client as per Section 4.2.1.		prefix}". This "root" prefix is discovered by the client as per
			Section 4.2.1. Request-URIs that target time zone data directly use
	Request-URIs that target time zone data directly use the prefix		the prefix template "{/service-prefix,data-prefix}". The second
	"{/service-prefix,data-prefix}". The second component of the prefix		component of the prefix template can be used to introduce additional
	template can be used to introduce additional path segments in the		path segments in the request-URI to allow for alternative ways to
	request-URI to allow for alternative ways to "partition" the time		"partition" the time zone data. For example, time zone data might be
	zone data. For example, time zone data might be partitioned by		partitioned by publisher release dates, or version identifiers. This
	publisher release dates, or version identifiers. This specification		specification does not define any partitions, which is left for
	does not define any partitions, which is left for future extensions.		future extensions. When the "data-prefix" variable is empty, the
	When the "data-prefix" variable is empty, the server is expected to		server is expected to return the current version of time zone data it
	return the current version of time zone data it has for all		has for all publishers it supports.
	publishers it supports.
	All template-URI variable values, and URI request parameters that		All URI template variable values, and URI request parameters that
	contain text values, MUST be encoded using the UTF-8 [RFC3629]		contain text values, MUST be encoded using the UTF-8 [RFC3629]
	character set. All responses MUST return data using the UTF-8		character set. All responses MUST return data using the UTF-8
	[RFC3629] character set. It is important to note that any "/"		[RFC3629] character set. It is important to note that any "/"
	characters, which are frequently found in time zone identifiers, are		characters, which are frequently found in time zone identifiers, are
	percent-encoded when used in the value of a path segment expansion		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		variable in a URI template (as per Section 3.2.6 of [RFC6570]). Thus
	the time zone identifier "America/New_York" would appear as		the time zone identifier "America/New_York" would appear as
	"America%2FNew_York" when used as the value for the "{/tzid}" URI		"America%2FNew_York" when used as the value for the "{/tzid}" URI
	template variable defined later in this specification.		template variable defined later in this specification.
	skipping to change at page 15, line 41 ¶		skipping to change at page 15, line 41 ¶
	records, as described by [RFC2782].		records, as described by [RFC2782].
	Example: service record for server without transport layer security.		Example: service record for server without 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.		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.
	4.2.1.2. Time Zone Data Distribution Service TXT records		4.2.1.2. Time Zone Data Distribution Service TXT Records
	When SRV RRs are used to advertise a time zone data distribution		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"		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		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		specification uses a TXT RR that follows the syntax defined in
	Section 6 of [RFC6763] and defines a "path" key for use in that		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		record. The value of the key MUST be the actual "context path" to
	the corresponding service on the server.		the corresponding service on the server.
	A site might provide TXT records in addition to SRV records for each		A site might provide TXT records in addition to SRV records for each
	service. When present, clients MUST use the "path" value as the		service. When present, clients MUST use the "path" value as the
	"context path" for the service in HTTP requests. When not present,		"context path" for the service in HTTP requests. When not present,
	clients use the ".well-known" URI approach described in		clients use the ".well-known" URI approach described in
	Section 4.2.1.3.		Section 4.2.1.3.
	To facilitate "context path's" that might differ from user to user,		As per Section 8, the server MAY require authentication when a client
	the server MAY require authentication when a client tries to access		tries to access the path URI specified by the TXT RR (i.e., the
	the path URI specified by the TXT RR (i.e., the server would return a		server would return a 401 status response to the unauthenticated
	401 status response to the unauthenticated request from the client,		request from the client, then return a redirect response after a
	then return a redirect response after a successful authentication by		successful authentication by the client).
	the client).
	Example: text record for service with transport layer security.		Example: text record for service with transport layer security.
	_timezones._tcp TXT path=/timezones		_timezones._tcp TXT path=/timezones
	4.2.1.3. Time Zone Data Distribution Service Well-Known URI		4.2.1.3. Time Zone Data Distribution Service Well-Known URI
	A "well-known" URI [RFC5785] is registered by this specification for		A "well-known" URI [RFC5785] is registered by this specification for
	the Time Zone Data Distribution service, "timezone" (see Section 10).		the Time Zone Data Distribution service, "timezone" (see Section 10).
	This URI points to a resource that the client can use as the initial		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		"context path" for the service they are trying to connect to. The
	server MUST redirect HTTP requests for that resource to the actual		server MUST redirect HTTP requests for that resource to the actual
	"context path" using one of the available mechanisms provided by HTTP		"context path" using one of the available mechanisms provided by HTTP
	(e.g., using an appropriate 3xx status response). Clients MUST		(e.g., using an appropriate 3xx status response). Clients MUST
	handle HTTP redirects on the ".well-known" URI. Servers MUST NOT		handle HTTP redirects on the ".well-known" URI, taking into account
	locate the actual time zone data distribution service endpoint at the		security restrictions on redirects described in Section 8. Servers
	".well-known" URI as per Section 1.1 of [RFC5785]. The "well-known"		MUST NOT locate the actual time zone data distribution service
	URI MUST be present on the server, even when a TXT RR		endpoint at the ".well-known" URI as per Section 1.1 of [RFC5785].
	(Section 4.2.1.2) is used in the DNS to specify a "context path".		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".
	Servers SHOULD set an appropriate Cache-Control header field value		Servers SHOULD set an appropriate Cache-Control header field value
	(as per Section 5.2 of [RFC7234]) in the redirect response to ensure		(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		caching occurs as needed, or as required by the type of response
	generated. For example, if it is anticipated that the location of		generated. For example, if it is anticipated that the location of
	the redirect might change over time, then an appropriate "max-age"		the redirect might change over time, then an appropriate "max-age"
	value would be used.		value would be used.
	To facilitate "context path's" that might differ from user to user,		As per Section 8, the server MAY require authentication when a client
	the server MAY require authentication when a client tries to access		tries to access the ".well-known" URI (i.e., the server would return
	the ".well-known" URI (i.e., the server would return a 401 status		a 401 status response to the unauthenticated request from the client,
	response to the unauthenticated request from the client, then return		then return the redirect response after a successful authentication
	the redirect response after a successful authentication by the		by the client).
	client).
	4.2.1.3.1. Example: well-known URI redirects to actual context path		4.2.1.3.1. Example: well-known URI redirects to actual context path
	A Time Zone Data Distribution server has a "context path" that is		A Time Zone Data Distribution server has a "context path" that is
	"/servlet/timezone". The client will use "/.well-known/timezone" as		"/servlet/timezone". The client will use "/.well-known/timezone" as
	the path for the service after it has first found the FQDN and port		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		number via an SRV lookup or via manual entry of information by the
	user. When the client makes its initial HTTP request against		user. When the client makes its initial HTTP request against
	"/.well-known/timezone", the server would issue an HTTP 301 redirect		"/.well-known/timezone", the server would issue an HTTP 301 redirect
	response with a Location response header field using the path		response with a Location response header field using the path
	skipping to change at page 17, line 35 ¶		skipping to change at page 17, line 35 ¶
	4.2.2.1. Initial Synchronization of All Time Zones		4.2.2.1. Initial Synchronization of All Time Zones
	When a secondary service or a client wishing to cache all time zone		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		data first starts, or wishes to do a full refresh, it synchronizes
	with another server by first issuing a "list" action to retrieve all		with another server by first issuing a "list" action to retrieve all
	the time zone meta-data. The client would preserve the returned		the time zone meta-data. The client would preserve the returned
	opaque token for subsequent use (see "synctoken" in Section 5.2.1).		opaque token for subsequent use (see "synctoken" in Section 5.2.1).
	The client will store the meta-data for each time zone returned in		The client will store the meta-data for each time zone returned in
	the response. Time zone data for each corresponding time zone can		the response. Time zone data for each corresponding time zone can
	then be fetched and stored locally. In addition a mapping of aliases		then be fetched and stored locally. In addition a mapping of aliases
	to time zones can be built from the meta-data.		to time zones can be built from the meta-data. 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.
	4.2.2.2. Subsequent Synchronization of All Time Zones		4.2.2.2. Subsequent Synchronization of All Time Zones
	A secondary service or a client caching all time zones needs to		A secondary service or a client caching all time zones needs to
	periodically synchronize with a server. To do so it would issue a		periodically synchronize with a server. To do so it would issue a
	"list" action with the "changedsince" URI query parameter set to the		"list" action with the "changedsince" URI query parameter set to the
	value of the opaque token returned by the last synchronization. The		value of the opaque token returned by the last synchronization. The
	client would again preserve the returned opaque token for subsequent		client would again preserve the returned opaque token for subsequent
	use. The client will update its stored time zone meta-data using the		use. The client will update its stored time zone meta-data using the
	new values returned in the response, which contains just the time		new values returned in the response, which contains just the time
	skipping to change at page 19, line 4 ¶		skipping to change at page 19, line 6 ¶
	Name: capabilities		Name: capabilities
	Request-URI Template:		Request-URI Template:
	{/service-prefix}/capabilities		{/service-prefix}/capabilities
	Description: This action returns the capabilities of the server,		Description: This action returns the capabilities of the server,
	allowing clients to determine if a specific feature has been		allowing clients to determine if a specific feature has been
	deployed and/or enabled.		deployed and/or enabled.
	Parameters: None		Parameters: None
	Response A JSON object containing a "version" member, an "info"		Response A JSON object containing a "version" member, an "info"
	member, and an "actions" member, see Section 6.1.		member, and an "actions" member, see Section 6.1.
	Possible Error Codes No specific code.		Possible Error Codes No specific code.
	5.1.1. Example: Get Capabilities		5.1.1. Example: get capabilities
	>> Request <<		>> Request <<
	GET /servlet/timezone/capabilities HTTP/1.1		GET /servlet/timezone/capabilities HTTP/1.1
	Host: tz.example.com		Host: tz.example.com
	>> Response <<		>> Response <<
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Date: Wed, 4 Jun 2008 09:32:12 GMT		Date: Wed, 4 Jun 2008 09:32:12 GMT
	skipping to change at page 22, line 13 ¶		skipping to change at page 22, line 13 ¶
	changedsince OPTIONAL, and MUST NOT occur more than once.		changedsince OPTIONAL, and MUST NOT occur more than once.
	Response: A JSON object containing a "synctoken" member and a		Response: A JSON object containing a "synctoken" member and a
	"timezones" member, see Section 6.2.		"timezones" member, see Section 6.2.
	Possible Error Codes		Possible Error Codes
	urn:ietf:params:tzdist:error:invalid-changedsince The		urn:ietf:params:tzdist:error:invalid-changedsince The
	"changedsince" URI query parameter appears more than once.		"changedsince" URI query parameter appears more than once.
	5.2.1. Example: List time zone identifiers		5.2.1. Example: list time zone identifiers
	In this example the client requests the full set of time zone		In this example the client requests the full set of time zone
	identifiers.		identifiers.
	>> Request <<		>> Request <<
	GET /servlet/timezone/zones HTTP/1.1		GET /servlet/timezone/zones HTTP/1.1
	Host: tz.example.com		Host: tz.example.com
	>> Response <<		>> Response <<
	skipping to change at page 24, line 16 ¶		skipping to change at page 24, line 16 ¶
	parameter has an incorrect value, or appears more than once, or		parameter has an incorrect value, or appears more than once, or
	does not match one of the fixed truncation range start values		does not match one of the fixed truncation range start values
	advertised in the "capabilities" action response.		advertised in the "capabilities" action response.
	urn:ietf:params:tzdist:error:invalid-end The "end" URI query		urn:ietf:params:tzdist:error:invalid-end The "end" URI query
	parameter has an incorrect value, or appears more than once, or		parameter has an incorrect value, or appears more than once, or
	has a value less than or equal to the "start" URI query		has a value less than or equal to the "start" URI query
	parameter, or does not match one of the fixed truncation range		parameter, or does not match one of the fixed truncation range
	end values advertised in the "capabilities" action response.		end values advertised in the "capabilities" action response.
	5.3.1. Example: Get time zone data		5.3.1. Example: get time zone data
	In this example the client requests the time zone with a specific		In this example the client requests the time zone with a specific
	time zone identifier to be returned.		time zone identifier to be returned.
	>> Request <<		>> Request <<
	GET /servlet/timezone/zones/America%2FNew_York HTTP/1.1		GET /servlet/timezone/zones/America%2FNew_York HTTP/1.1
	Host: tz.example.com		Host: tz.example.com
	Accept:text/calendar		Accept:text/calendar
	skipping to change at page 24, line 43 ¶		skipping to change at page 24, line 43 ¶
	ETag: "123456789-000-111"		ETag: "123456789-000-111"
	BEGIN:VCALENDAR		BEGIN:VCALENDAR
	...		...
	BEGIN:VTIMEZONE		BEGIN:VTIMEZONE
	TZID:America/New_York		TZID:America/New_York
	...		...
	END:VTIMEZONE		END:VTIMEZONE
	END:VCALENDAR		END:VCALENDAR
	5.3.2. Example: Conditional Get time zone data		5.3.2. Example: conditional get time zone data
	In this example the client requests the time zone with a specific		In this example the client requests the time zone with a specific
	time zone identifier to be returned, but uses an If-None-Match header		time zone identifier to be returned, but uses an If-None-Match header
	field in the request, set to the value of a previously returned ETag		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"		header field, or the value of the "etag" member in a JSON "timezone"
	object returned from a "list" action response. In this example, the		object returned from a "list" action response. In this example, the
	data on the server has not changed, so a 304 response is returned.		data on the server has not changed, so a 304 response is returned.
	>> Request <<		>> Request <<
	GET /servlet/timezone/zones/America%2FNew_York HTTP/1.1		GET /servlet/timezone/zones/America%2FNew_York HTTP/1.1
	Host: tz.example.com		Host: tz.example.com
	Accept:text/calendar		Accept:text/calendar
	If-None-Match: "123456789-000-111"		If-None-Match: "123456789-000-111"
	>> Response <<		>> Response <<
	HTTP/1.1 304 Not Modified		HTTP/1.1 304 Not Modified
	Date: Wed, 4 Jun 2008 09:32:12 GMT		Date: Wed, 4 Jun 2008 09:32:12 GMT
	5.3.3. Example: Get time zone data using a time zone alias		5.3.3. Example: get time zone data using a time zone alias
	In this example the client requests the time zone with an aliased		In this example the client requests the time zone with an aliased
	time zone identifier to be returned, and the server returns the time		time zone identifier to be returned, and the server returns the time
	zone data with that identifier, and two aliases.		zone data with that identifier, and two aliases.
	>> Request <<		>> Request <<
	GET /servlet/timezone/zones/US%2FEastern HTTP/1.1		GET /servlet/timezone/zones/US%2FEastern HTTP/1.1
	Host: tz.example.com		Host: tz.example.com
	Accept:text/calendar		Accept:text/calendar
	skipping to change at page 26, line 32 ¶		skipping to change at page 26, line 32 ¶
	BEGIN:VCALENDAR		BEGIN:VCALENDAR
	...		...
	BEGIN:VTIMEZONE		BEGIN:VTIMEZONE
	TZID:US/Eastern		TZID:US/Eastern
	TZID-ALIAS-OF:America/New_York		TZID-ALIAS-OF:America/New_York
	TZID-ALIAS-OF:America/Montreal		TZID-ALIAS-OF:America/Montreal
	...		...
	END:VTIMEZONE		END:VTIMEZONE
	END:VCALENDAR		END:VCALENDAR
	5.3.4. Example: Get truncated time zone data		5.3.4. Example: get truncated time zone data
	Assume the server advertises a "truncated" object in its		Assume the server advertises a "truncated" object in its
	"capabilities" response that appears as:		"capabilities" response that appears as:
	"truncated": {		"truncated": {
	"any": false,		"any": false,
	"ranges": [		"ranges": [
	{"start": "1970-01-01T00:00:00Z", "end": "*"},		{"start": "1970-01-01T00:00:00Z", "end": "*"},
	{"start":"2010-01-01T00:00:00Z", "end":"2020-01-01T00:00:00Z"}		{"start":"2010-01-01T00:00:00Z", "end":"2020-01-01T00:00:00Z"}
	],		],
	skipping to change at page 27, line 43 ¶		skipping to change at page 27, line 43 ¶
	BEGIN:STANDARD		BEGIN:STANDARD
	DTSTART:20101231T190000		DTSTART:20101231T190000
	TZNAME:EST		TZNAME:EST
	TZOFFSETFROM:-0500		TZOFFSETFROM:-0500
	TZOFFSETTO:-0500		TZOFFSETTO:-0500
	END:STANDARD		END:STANDARD
	...		...
	END:VTIMEZONE		END:VTIMEZONE
	END:VCALENDAR		END:VCALENDAR
	5.3.5. Example: Request for a non-existent time zone		5.3.5. Example: request for a non-existent time zone
	In this example the client requests the time zone with a specific		In this example the client requests the time zone with a specific
	time zone identifier to be returned. As it turns out, no time zone		time zone identifier to be returned. As it turns out, no time zone
	exists with that identifier.		exists with that identifier.
	>> Request <<		>> Request <<
	GET /servlet/timezone/zones/America%2FPittsburgh HTTP/1.1		GET /servlet/timezone/zones/America%2FPittsburgh HTTP/1.1
	Host: tz.example.com		Host: tz.example.com
	Accept:application/calendar+json		Accept:application/calendar+json
	skipping to change at page 29, line 36 ¶		skipping to change at page 29, line 36 ¶
	parameter has an incorrect value, or appears more than once, or		parameter has an incorrect value, or appears more than once, or
	is missing, or has a value outside any fixed truncation ranges		is missing, or has a value outside any fixed truncation ranges
	advertised in the "capabilities" action response.		advertised in the "capabilities" action response.
	urn:ietf:params:tzdist:error:invalid-end The "end" URI query		urn:ietf:params:tzdist:error:invalid-end The "end" URI query
	parameter has an incorrect value, or appears more than once, or		parameter has an incorrect value, or appears more than once, or
	has a value less than or equal to the "start" URI query		has a value less than or equal to the "start" URI query
	parameter, or has a value outside any fixed truncation ranges		parameter, or has a value outside any fixed truncation ranges
	advertised in the "capabilities" action response..		advertised in the "capabilities" action response..
	5.4.1. Example: Expanded JSON Data Format		5.4.1. Example: expanded JSON data format
	In this example the client requests a time zone in the expanded form.		In this example the client requests a time zone in the expanded form.
	>> Request <<		>> Request <<
	GET /servlet/timezone/zones/America%2FNew_York/observances		GET /servlet/timezone/zones/America%2FNew_York/observances
	?start=2008-01-01T00:00:00Z&end=2009-01-01T00:00:00Z HTTP/1.1		?start=2008-01-01T00:00:00Z&end=2009-01-01T00:00:00Z HTTP/1.1
	Host: tz.example.com		Host: tz.example.com
	>> Response <<		>> Response <<
	skipping to change at page 32, line 11 ¶		skipping to change at page 32, line 11 ¶
	Response: The response has the same format as the "list" action,		Response: The response has the same format as the "list" action,
	with one result object per successful match, see Section 6.2.		with one result object per successful match, see Section 6.2.
	Possible Error Codes		Possible Error Codes
	urn:ietf:params:tzdist:error:invalid-pattern The "pattern" URI		urn:ietf:params:tzdist:error:invalid-pattern The "pattern" URI
	query parameter has an incorrect value, or appears more than		query parameter has an incorrect value, or appears more than
	once.		once.
	5.5.1. Example: Find action		5.5.1. Example: find action
	In this example the client asks for data about the time zone "US/		In this example the client asks for data about the time zone "US/
	Eastern".		Eastern".
	>> Request <<		>> Request <<
	GET /servlet/timezone/zones?pattern=US/Eastern HTTP/1.1		GET /servlet/timezone/zones?pattern=US/Eastern HTTP/1.1
	Host: tz.example.com		Host: tz.example.com
	>> Response <<		>> Response <<
	skipping to change at page 34, line 41 ¶		skipping to change at page 34, line 41 ¶
	member specifies the date (with the implied time of 00:00:00 UTC)		member specifies the date (with the implied time of 00:00:00 UTC)
	at which the corresponding UTC offset from TAI takes effect. In		at which the corresponding UTC offset from TAI takes effect. In
	other words, a leap second is added or removed just prior to time		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		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		added, the "utc-offset" value will be incremented by one, when a
	leap second is removed, the "utc-offset" value will be decremented		leap second is removed, the "utc-offset" value will be decremented
	by one.		by one.
	Possible Error Codes No specific code.		Possible Error Codes No specific code.
	5.6.1. Example: Get leapsecond information		5.6.1. Example: get leapsecond information
	In this example the client requests the current leap second		In this example the client requests the current leap second
	information from the server.		information from the server.
	>> Request <<		>> Request <<
	GET /servlet/timezone/leapseconds HTTP/1.1		GET /servlet/timezone/leapseconds HTTP/1.1
	Host: tz.example.com		Host: tz.example.com
	>> Response <<		>> Response <<
	skipping to change at page 36, line 37 ¶		skipping to change at page 36, line 37 ¶
	STRING represents a JSON string, defined in Section 7 of [RFC7159].		STRING represents a JSON string, defined in Section 7 of [RFC7159].
	BOOLEAN represents either of the JSON values "true" or "false",		BOOLEAN represents either of the JSON values "true" or "false",
	defined in Section 3 of [RFC7159].		defined in Section 3 of [RFC7159].
	; a line starting with a ";" (0x3B) character is a comment.		; a line starting with a ";" (0x3B) character is a comment.
	Note, clients MUST ignore any unexpected JSON members in responses		Note, clients MUST ignore any unexpected JSON members in responses
	from the server.		from the server.
	6.1. capabilities action response		6.1. capabilities Action Response
	Rules for the JSON document returned for a "capabilities" action		Rules for the JSON document returned for a "capabilities" action
	request.		request.
	; root object		; root object
	OBJECT (version, info, actions)		OBJECT (version, info, actions)
	; The version number of the protocol supported - MUST be 1		; The version number of the protocol supported - MUST be 1
	MEMBER version "version" : NUMBER		MEMBER version "version" : NUMBER
	skipping to change at page 39, line 5 ¶		skipping to change at page 39, line 5 ¶
	MEMBER param_required "required" : BOOLEAN		MEMBER param_required "required" : BOOLEAN
	; If true the parameter can occur more than once in the request-URI		; If true the parameter can occur more than once in the request-URI
	; default is false		; default is false
	MEMBER param_multi "multi" : BOOLEAN,		MEMBER param_multi "multi" : BOOLEAN,
	; An array that defines the allowed set of values for the parameter		; An array that defines the allowed set of values for the parameter
	; In the absence of this member, any string value is acceptable		; In the absence of this member, any string value is acceptable
	MEMBER param_values "values" ARRAY STRING		MEMBER param_values "values" ARRAY STRING
	6.2. list/find action response		6.2. list/find Action Response
	Rules for the JSON document returned for a "list" or "find" action		Rules for the JSON document returned for a "list" or "find" action
	request.		request.
	; root object		; root object
	OBJECT (synctoken, timezones)		OBJECT (synctoken, timezones)
	; Server generated opaque token used for synchronizing changes,		; Server generated opaque token used for synchronizing changes,
	MEMBER synctoken "synctoken" : STRING		MEMBER synctoken "synctoken" : STRING
	skipping to change at page 40, line 14 ¶		skipping to change at page 40, line 14 ¶
	; Language tag for the language of the associated name		; Language tag for the language of the associated name
	MEMBER: lang "lang" : STRING		MEMBER: lang "lang" : STRING
	; Localized name		; Localized name
	MEMBER lname "name" : STRING		MEMBER lname "name" : STRING
	; Indicates whether this is the preferred name for the associated		; Indicates whether this is the preferred name for the associated
	; language default: false		; language default: false
	MEMBER pref "pref" : BOOLEAN		MEMBER pref "pref" : BOOLEAN
	6.3. expand action response		6.3. expand Action Response
	Rules for the JSON document returned for a "expand" action request.		Rules for the JSON document returned for a "expand" action request.
	; root object		; root object
	OBJECT (		OBJECT (
	tzid,		tzid,
	?start,		?start,
	?end,		?end,
	observances		observances
	)		)
	skipping to change at page 42, line 5 ¶		skipping to change at page 42, line 5 ¶
	; [RFC3339] UTC date-time value at which the observance takes effect		; [RFC3339] UTC date-time value at which the observance takes effect
	MEMBER onset "onset" : STRING		MEMBER onset "onset" : STRING
	; The UTC offset in seconds before the start of this observance		; The UTC offset in seconds before the start of this observance
	MEMBER utc_offset_from "utc-offset-from" : NUMBER		MEMBER utc_offset_from "utc-offset-from" : NUMBER
	; The UTC offset in seconds at and after the start of this observance		; The UTC offset in seconds at and after the start of this observance
	MEMBER utc_offset_to "utc-offset-to" : NUMBER		MEMBER utc_offset_to "utc-offset-to" : NUMBER
	6.4. leapseconds action response		6.4. leapseconds Action Response
	Rules for the JSON document returned for a "leapseconds" action		Rules for the JSON document returned for a "leapseconds" action
	request.		request.
	; root object		; root object
	OBJECT (		OBJECT (
	expires,		expires,
	publisher,		publisher,
	version,		version,
	leapseconds		leapseconds
	skipping to change at page 46, line 25 ¶		skipping to change at page 46, line 25 ¶
	servers being able to identify the client by the specific		servers being able to identify the client by the specific
	periodicity of its polling behavior.		periodicity of its polling behavior.
	9. A server trying to "fingerprint" clients might insert a "fake"		9. A server trying to "fingerprint" clients might insert a "fake"
	time zone into the time zone data, using a unique identifier for		time zone into the time zone data, using a unique identifier for
	each client making a request. The server can then watch for		each client making a request. The server can then watch for
	client requests that refer to that "fake" time zone and thus		client requests that refer to that "fake" time zone and thus
	track the activity of each client. It is hard for clients to		track the activity of each client. It is hard for clients to
	identify a "fake" time zone given that new time zones are added		identify a "fake" time zone given that new time zones are added
	from time to time. One option to mitigate this would be for the		from time to time. One option to mitigate this would be for the
	client to make use of two time zone distribution servers from two		client to make use of two time zone data distribution servers
	independent providers, that provide time zone data from the same		from two independent providers, that provide time zone data from
	publisher. The client can then compare the list of time zones		the same publisher. The client can then compare the list of time
	from each server (assuming they both have the same version of		zones from each server (assuming they both have the same version
	time zone data from the common publisher) and detect ones that		of time zone data from the common publisher) and detect ones that
	appear to be added on one server and not the other.		appear to be added on one server and not the other.
	Alternatively, the client can check the publisher data directly		Alternatively, the client can check the publisher data directly
	to verify that time zones match the set the publisher has.		to verify that time zones match the set the publisher has.
	Note that some of the above recommendations will result in less		Note that some of the above recommendations will result in less
	efficient use of the protocol due to fetching data that might not be		efficient use of the protocol due to fetching data that might not be
	relevant to the client.		relevant to the client.
	An organization can setup a secondary server within their own domain,		An organization can setup a secondary server within their own domain,
	and configure their clients to use that server, to protect the		and configure their clients to use that server, to protect the
	organization's users from the possibility of being tracked by an		organization's users from the possibility of being tracked by an
	untrusted time zone distribution server. Clients can then use more		untrusted time zone data distribution server. Clients can then use
	efficient protocol interactions, free from the concerns above, on the		more efficient protocol interactions, free from the concerns above,
	basis that their organization's server is trusted. When doing this,		on the basis that their organization's server is trusted. When doing
	the secondary server would follow the recommendations for clients		this, the secondary server would follow the recommendations for
	(listed in the previous paragraph) so that the untrusted server is		clients (listed in the previous paragraph) so that the untrusted
	not able to gain information about the organization as a whole.		server is not able to gain information about the organization as a
	Note, however, that if client requests to the secondary server are		whole. Note, however, that if client requests to the secondary
	subject to tracking by a network observer so clients ought to apply		server are subject to tracking by a network observer so clients ought
	some of the randomization techniques from the list above.		to apply some of the randomization techniques from the list above.
	Servers that want to avoid accidentally storing information that		Servers that want to avoid accidentally storing information that
	could be used to identify clients can take the following precautions:		could be used to identify clients can take the following precautions:
	1. Avoid logging client request activity, or anonymize information		1. Avoid logging client request activity, or anonymize information
	in any logs (e.g., client IP address, client user-agent details,		in any logs (e.g., client IP address, client user-agent details,
	authentication credentials, etc).		authentication credentials, etc).
	2. Add an unused HTTP response header to each response with a random		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		amount of data in it (e.g., to pad the overall request size to
	skipping to change at page 47, line 29 ¶		skipping to change at page 47, line 29 ¶
	using the registration procedure and template from Section 5.1 of		using the registration procedure and template from Section 5.1 of
	[RFC5785], creates two new SRV service label aliases, and defines one		[RFC5785], creates two new SRV service label aliases, and defines one
	new iCalendar property parameter as per the registration procedure in		new iCalendar property parameter as per the registration procedure in
	[RFC5545]. It also adds a new "tzdist Identifiers Registry" to the		[RFC5545]. It also adds a new "tzdist Identifiers Registry" to the
	IETF parameters URN sub-namespace as per [RFC3553] for use with		IETF parameters URN sub-namespace as per [RFC3553] for use with
	protocol related error codes.		protocol related error codes.
	10.1. Service Actions Registration		10.1. Service Actions Registration
	IANA is asked to create a new top-level category called "Time Zone		IANA is asked to create a new top-level category called "Time Zone
	Distribution Service (TZDIST) Parameters", and to put all the		Data Distribution Service (TZDIST) Parameters", and to put all the
	registries created herein into that category.		registries created herein into that category.
	IANA is asked to create a new registry called "TZDIST Service		IANA is asked to create a new registry called "TZDIST Service
	Actions", as defined below.		Actions", as defined below.
	10.1.1. Service Actions Registration Procedure		10.1.1. Service Actions Registration Procedure
	This registry uses the "Specification Required" policy defined in		This registry uses the "Specification Required" policy defined in
	[I-D.leiba-cotton-iana-5226bis], which makes use of a designated		[I-D.leiba-cotton-iana-5226bis], which makes use of a designated
	expert to review potential registrations.		expert to review potential registrations.
	skipping to change at page 50, line 20 ¶		skipping to change at page 50, line 20 ¶
	Assignee: IESG <iesg@ietf.org>		Assignee: IESG <iesg@ietf.org>
	Contact: IETF Chair <chair@ietf.org>		Contact: IETF Chair <chair@ietf.org>
	Description: Time Zone Data Distribution Service - non-TLS		Description: Time Zone Data Distribution Service - non-TLS
	Reference: RFCXXXX		Reference: RFCXXXX
	Assignment Note: This is an extension of the http service. Defined		Assignment Note: This is an extension of the http service. Defined
	TXT keys: path=<context path>		TXT keys: path=<context path> (as per Section 6 of [RFC6763]).
	10.3.2. timezones Service Name Registration		10.3.2. timezones Service Name Registration
	Service Name: timezones		Service Name: timezones
	Transport Protocol(s): TCP		Transport Protocol(s): TCP
	Assignee: IESG <iesg@ietf.org>		Assignee: IESG <iesg@ietf.org>
	Contact: IETF Chair <chair@ietf.org>		Contact: IETF Chair <chair@ietf.org>
	Description: Time Zone Data Distribution Service - over TLS		Description: Time Zone Data Distribution Service - over TLS
	Reference: RFCXXXX		Reference: RFCXXXX
	Assignment Note: This is an extension of the https service. Defined		Assignment Note: This is an extension of the https service. Defined
	TXT keys: path=<context path>		TXT keys: path=<context path> (as per Section 6 of [RFC6763]).
	10.4. tzdist Identifiers Registry		10.4. tzdist Identifiers Registry
	IANA is requested to register a new URN sub-namespace within the IETF		IANA is requested to register a new URN sub-namespace within the IETF
	URN Sub-namespace for Registered Protocol Parameter Identifiers		URN Sub-namespace for Registered Protocol Parameter Identifiers
	defined in [RFC3553].		defined in [RFC3553].
			Registrations in this registry follow the "IETF Review"
			[I-D.leiba-cotton-iana-5226bis] policy.
	Registry name: tzdist Identifiers		Registry name: tzdist Identifiers
	URN prefix: urn:ietf:params:tzdist		URN prefix: urn:ietf:params:tzdist
	Specification: RFCXXXX		Specification: RFCXXXX
	Repository: http://www.iana.org/assignments/tzdist-identifiers.		Repository: http://www.iana.org/assignments/tzdist-identifiers.
	Index value:: Values in this registry are URNs or URN prefixes that		Index value:: Values in this registry are URNs or URN prefixes that
	start with the prefix "urn:ietf:params:tzdist:". Each is		start with the prefix "urn:ietf:params:tzdist:". Each is
	registered independently. The prefix		registered independently. The prefix
	"urn:ietf:params:tzdist:error:" is used to represent specific		"urn:ietf:params:tzdist:error:" is used to represent specific
	error codes within the protocol as defined in the list of actions		error codes within the protocol as defined in the list of actions
	in Section 5 and used in problem reports (Section 4.1.7).		in Section 5 and used in problem reports (Section 4.1.7).
	Each registration in the "tzdist Identifiers" registry requires the		Each registration in the "tzdist Identifiers" registry requires the
	skipping to change at page 51, line 31 ¶		skipping to change at page 51, line 32 ¶
	Contact: Email for the person or groups making the registration.		Contact: Email for the person or groups making the registration.
	Index Value: As described in [RFC3553], URN prefixes that are		Index Value: As described in [RFC3553], URN prefixes that are
	registered include a description of how the URN is constructed.		registered include a description of how the URN is constructed.
	This is not applicable for specific URNs.		This is not applicable for specific URNs.
	The "tzdist Identifiers" registry has the initial registrations		The "tzdist Identifiers" registry has the initial registrations
	included in the following sections.		included in the following sections.
	10.4.1. Registration of invalid-action error URN		10.4.1. Registration of invalid-action Error URN
	This section registers the "urn:ietf:params:tzdist:error:invalid-		This section registers the "urn:ietf:params:tzdist:error:invalid-
	action" URN in the "tzdist Identifiers" registry.		action" URN in the "tzdist Identifiers" registry.
	URN: urn:ietf:params:tzdist:error:invalid-action		URN: urn:ietf:params:tzdist:error:invalid-action
	Specification: RFCXXXX, Section 5		Specification: RFCXXXX, Section 5
	Repository: http://www.iana.org/assignments/tzdist-identifiers.		Repository: http://www.iana.org/assignments/tzdist-identifiers.
	Contact: IESG <iesg@ietf.org>		Contact: IESG <iesg@ietf.org>
	Index value:: N/A.		Index value:: N/A.
	10.4.2. Registration of invalid-changedsince error URN		10.4.2. Registration of invalid-changedsince Error URN
	This section registers the "urn:ietf:params:tzdist:error:invalid-		This section registers the "urn:ietf:params:tzdist:error:invalid-
	changedsince" URN in the "tzdist Identifiers" registry.		changedsince" URN in the "tzdist Identifiers" registry.
	URN: urn:ietf:params:tzdist:error:invalid-changedsince		URN: urn:ietf:params:tzdist:error:invalid-changedsince
	Specification: RFCXXXX, Section 5.2		Specification: RFCXXXX, Section 5.2
	Repository: http://www.iana.org/assignments/tzdist-identifiers.		Repository: http://www.iana.org/assignments/tzdist-identifiers.
	Contact: IESG <iesg@ietf.org>		Contact: IESG <iesg@ietf.org>
	Index value:: N/A.		Index value:: N/A.
	10.4.3. Registration of tzid-not-found error URN		10.4.3. Registration of tzid-not-found Error URN
	This section registers the "urn:ietf:params:tzdist:error:tzid-not-		This section registers the "urn:ietf:params:tzdist:error:tzid-not-
	found" URN in the "tzdist Identifiers" registry.		found" URN in the "tzdist Identifiers" registry.
	URN: urn:ietf:params:tzdist:error:tzid-not-found		URN: urn:ietf:params:tzdist:error:tzid-not-found
	Specification: RFCXXXX, Section 5.3 & Section 5.4		Specification: RFCXXXX, Section 5.3 & Section 5.4
	Repository: http://www.iana.org/assignments/tzdist-identifiers.		Repository: http://www.iana.org/assignments/tzdist-identifiers.
	Contact: IESG <iesg@ietf.org>		Contact: IESG <iesg@ietf.org>
	Index value:: N/A.		Index value:: N/A.
	10.4.4. Registration of invalid-format error URN		10.4.4. Registration of invalid-format Error URN
	This section registers the "urn:ietf:params:tzdist:error:invalid-		This section registers the "urn:ietf:params:tzdist:error:invalid-
	format" URN in the "tzdist Identifiers" registry.		format" URN in the "tzdist Identifiers" registry.
	URN: urn:ietf:params:tzdist:error:invalid-format		URN: urn:ietf:params:tzdist:error:invalid-format
	Specification: RFCXXXX, Section 5.3		Specification: RFCXXXX, Section 5.3
	Repository: http://www.iana.org/assignments/tzdist-identifiers.		Repository: http://www.iana.org/assignments/tzdist-identifiers.
	Contact: IESG <iesg@ietf.org>		Contact: IESG <iesg@ietf.org>
	Index value:: N/A.		Index value:: N/A.
	10.4.5. Registration of invalid-start error URN		10.4.5. Registration of invalid-start Error URN
	This section registers the "urn:ietf:params:tzdist:error:invalid-		This section registers the "urn:ietf:params:tzdist:error:invalid-
	start" URN in the "tzdist Identifiers" registry.		start" URN in the "tzdist Identifiers" registry.
	URN: urn:ietf:params:tzdist:error:invalid-start		URN: urn:ietf:params:tzdist:error:invalid-start
	Specification: RFCXXXX, Section 5.3 & Section 5.4		Specification: RFCXXXX, Section 5.3 & Section 5.4
	Repository: http://www.iana.org/assignments/tzdist-identifiers.		Repository: http://www.iana.org/assignments/tzdist-identifiers.
	Contact: IESG <iesg@ietf.org>		Contact: IESG <iesg@ietf.org>
	Index value:: N/A.		Index value:: N/A.
	10.4.6. Registration of invalid-end error URN		10.4.6. Registration of invalid-end Error URN
	This section registers the "urn:ietf:params:tzdist:error:invalid-end"		This section registers the "urn:ietf:params:tzdist:error:invalid-end"
	URN in the "tzdist Identifiers" registry.		URN in the "tzdist Identifiers" registry.
	URN: urn:ietf:params:tzdist:error:invalid-end		URN: urn:ietf:params:tzdist:error:invalid-end
	Specification: RFCXXXX, Section 5.3 & Section 5.4		Specification: RFCXXXX, Section 5.3 & Section 5.4
	Repository: http://www.iana.org/assignments/tzdist-identifiers.		Repository: http://www.iana.org/assignments/tzdist-identifiers.
	Contact: IESG <iesg@ietf.org>		Contact: IESG <iesg@ietf.org>
	Index value:: N/A.		Index value:: N/A.
	10.4.7. Registration of invalid-pattern error URN		10.4.7. Registration of invalid-pattern Error URN
	This section registers the "urn:ietf:params:tzdist:error:invalid-		This section registers the "urn:ietf:params:tzdist:error:invalid-
	pattern" URN in the "tzdist Identifiers" registry.		pattern" URN in the "tzdist Identifiers" registry.
	URN: urn:ietf:params:tzdist:error:invalid-pattern		URN: urn:ietf:params:tzdist:error:invalid-pattern
	Specification: RFCXXXX, Section 5.5		Specification: RFCXXXX, Section 5.5
	Repository: http://www.iana.org/assignments/tzdist-identifiers.		Repository: http://www.iana.org/assignments/tzdist-identifiers.
	skipping to change at page 54, line 12 ¶		skipping to change at page 54, line 12 ¶
	| TZID-ALIAS-OF | Current | RFCXXXX, Section 7.2 |		| TZID-ALIAS-OF | Current | RFCXXXX, Section 7.2 |
	+----------------+----------+-----------------------+		+----------------+----------+-----------------------+
	11. Acknowledgements		11. Acknowledgements
	The authors would like to thank the members of the Calendaring and		The authors would like to thank the members of the Calendaring and
	Scheduling Consortium's Time Zone Technical Committee, and the		Scheduling Consortium's Time Zone Technical Committee, and the
	participants and chairs of the IETF tzdist working group. In		participants and chairs of the IETF tzdist working group. In
	particular, the following individuals have made important		particular, the following individuals have made important
	contributions to this work: Steve Allen, Lester Caine, Stephen		contributions to this work: Steve Allen, Lester Caine, Stephen
	Colebourne, Tobias Conradi, Steve Crocker, Paul Eggert, John Haug,		Colebourne, Tobias Conradi, Steve Crocker, Daniel Kahn Gillmor, Paul
	Ciny Joy, Bryan Keller, Barry Leiba, Andrew McMillan, Ken Murchison,		Eggert, John Haug, Ciny Joy, Bryan Keller, Barry Leiba, Andrew
	Tim Parenti, Arnaud Quillaud, Jose Edvaldo Saraiva, and Dave Thewlis.		McMillan, Ken Murchison, Tim Parenti, Arnaud Quillaud, Jose Edvaldo
			Saraiva, and Dave Thewlis.
	This specification originated from work at the Calendaring and		This specification originated from work at the Calendaring and
	Scheduling Consortium, which has supported the development and		Scheduling Consortium, which has supported the development and
	testing of implementations of the specification.		testing of implementations of the specification.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.ietf-appsawg-http-problem]		[I-D.ietf-appsawg-http-problem]
	skipping to change at page 56, line 48 ¶		skipping to change at page 56, line 48 ¶
	(DTLS)", BCP 195, RFC 7525, May 2015.		(DTLS)", BCP 195, RFC 7525, May 2015.
	12.2. Informative References		12.2. Informative References
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
	2131, March 1997.		2131, March 1997.
	Appendix A. Change History (to be removed prior to publication as an		Appendix A. Change History (to be removed prior to publication as an
	RFC)		RFC)
			Changes for -10
			1. OPSDIR: minor editorial tweaks.
			2. OPSDIR: Add RFC6763 reference into IANA registration templates.
			3. IESG: add reference to security section for well-known redirects.
			4. IESG: Add sentence describing current size of an initial JSON
			response for IANA data.
			5. IESG: don't mention per-user context paths - just refer to
			generic HTTP auth.
			6. IANA: tzdist registry policy added.
			7. Make sure "data" appears between "time zone" and "distribution"
	Changes for -09		Changes for -09
	1. Added June 30th 2015 leap second data into example.		1. Added June 30th 2015 leap second data into example.
	2. GENART: clarify how "utc-offset" changes as leap seconds are		2. GENART: clarify how "utc-offset" changes as leap seconds are
	added or removed.		added or removed.
	3. GENART: ".well-known" MUST be present.		3. GENART: ".well-known" MUST be present.
	4. GENART: switch RFC5226 reference to 5226bis.		4. GENART: switch RFC5226 reference to 5226bis.
End of changes. 52 change blocks.
	103 lines changed or deleted		126 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/