< draft-ietf-geopriv-local-civic-02.txt		draft-ietf-geopriv-local-civic-03.txt >
	GEOPRIV J. Winterbottom		GEOPRIV J. Winterbottom
	Internet-Draft M. Thomson		Internet-Draft CommScope
	Updates: 5222 (if approved) CommScope		Updates: 5222 (if approved) M. Thomson
	Intended status: Standards Track R. Barnes		Intended status: Standards Track Skype
	Expires: April 20, 2012 BBN Technologies		Expires: August 4, 2012 R. Barnes
			BBN Technologies
	B. Rosen		B. Rosen
	NeuStar, Inc.		NeuStar, Inc.
	R. George		R. George
	Huawei Technologies		Huawei Technologies
	October 18, 2011		Feb 2012
	Specifying Civic Address Extensions in PIDF-LO		Specifying Civic Address Extensions in PIDF-LO
	draft-ietf-geopriv-local-civic-02		draft-ietf-geopriv-local-civic-03
	Abstract		Abstract
	New fields are occasionally added to civic addresses. A backwardly-		New fields are occasionally added to civic addresses. A backwardly-
	compatible mechanism for adding civic address elements to the Geopriv		compatible mechanism for adding civic address elements to the Geopriv
	civic address format is described. A formal mechanism for handling		civic address format is described. A formal mechanism for handling
	unsupported extensions when translating between XML and DHCP civic		unsupported extensions when translating between XML and DHCP civic
	address forms is defined for entities that need to perform this		address forms is defined for entities that need to perform this
	translation. Intial extensions for some new elements are also		translation. Intial extensions for some new elements are also
	defined. The LoST protocol mechanism that returns civic address		defined. The LoST protocol mechanism that returns civic address
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 45 ¶
	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 April 20, 2012.		This Internet-Draft will expire on August 4, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 39 ¶
	5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 9		5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 10		5.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 10		5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 10
	5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 10		5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 10
	5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 11		5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 11
	5.6. Extension examples . . . . . . . . . . . . . . . . . . . . 11		5.6. Extension examples . . . . . . . . . . . . . . . . . . . . 11
	6. Using Local Civic Extension with the LoST Protocol . . . . . . 12		6. Using Local Civic Extension with the LoST Protocol . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	8.1. CAtype Registration for Extensions . . . . . . . . . . . . 14		8.1. CAtype Registration for Extensions . . . . . . . . . . . . 14
	8.2. End of Numeric CAtype Registration . . . . . . . . . . . . 14		8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 14
	8.3. URN sub-namespace registration for		8.3. URN sub-namespace registration for
	'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext' . . 14		'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext' . . 14
	8.4. XML Schema Registration . . . . . . . . . . . . . . . . . 15		8.4. XML Schema Registration . . . . . . . . . . . . . . . . . 15
	8.5. Registration Template . . . . . . . . . . . . . . . . . . 15		8.5. Registration Template . . . . . . . . . . . . . . . . . . 15
	8.6. Registration Policy and Expert Guidance . . . . . . . . . 17		8.6. Registration Policy and Expert Guidance . . . . . . . . . 17
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . . 18		10.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The Geopriv civic location specifications ([RFC4776], [RFC5139])		The Geopriv civic location specifications ([RFC4776], [RFC5139])
	define an XML and binary representtations for civic addresses that		define an XML and binary representations for civic addresses that
	allow for the expression of civic addresses. Guidance for the use of		allow for the expression of civic addresses. Guidance for the use of
	these formats for the civic addresses in different countries is		these formats for the civic addresses in different countries is
	included in [RFC5774].		included in [RFC5774].
	Subsequent to these specifications being produced, use cases for		Subsequent to these specifications being produced, use cases for
	extending the civic address format with new elements have emerged.		extending the civic address format with new elements have emerged.
	Extension elements do not readily fit existing elements, as		Extension elements do not readily fit existing elements, as
	recommended in [RFC5774].		recommended in [RFC5774].
	The XML format for civic addresses [RFC5139] provides a mechanism		The XML format for civic addresses [RFC5139] provides a mechanism
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	A recipient of a civic address in either format currently has no		A recipient of a civic address in either format currently has no
	option other than to ignore elements that it does not understand.		option other than to ignore elements that it does not understand.
	This results in any elements that are unknown to that recipient being		This results in any elements that are unknown to that recipient being
	discarded if a recipient performs a translation between the two		discarded if a recipient performs a translation between the two
	formats. In order for a new extension to be preserved through		formats. In order for a new extension to be preserved through
	translation by any recipient, the recipient has to understand the		translation by any recipient, the recipient has to understand the
	extension and know how to correlate an XML element with a CAtype.		extension and know how to correlate an XML element with a CAtype.
	This document describes how new civic address elements are added.		This document describes how new civic address elements are added.
	Extension always starts with the definition of XML elements. A		Extensions always starts with the definition of XML elements. A
	mechanism for carrying the extension in the DHCP format is described.		mechanism for carrying the extension in the DHCP format is described.
	A new XML namespace containing a small number of additional civic		A new XML namespace containing a small number of additional civic
	elements is also defined and can be used as a template to illustrate		elements is also defined and can be used as a template to illustrate
	how other extensions can be defined as required.		how other extensions can be defined as required.
	These mechanisms ensure that any translation between formats can be		These mechanisms ensure that any translation between formats can be
	performed consistently and without loss of information. Translation		performed consistently and without loss of information. Translation
	between formats can occur without knowledge of every extension that		between formats can occur without knowledge of every extension that
	is present.		is present.
	The existing registry of numeric CAtypes is closed, and a new		The registry of numeric CAtypes is modified so that creators of
	registry is created that advertises new namespaces and the associated		extension can advertise new namespaces and the civic elements to
	civic elements to encourage maximum reuse.		encourage maximum reuse.
	These additions described in this document are backwardly compatible.		The additions described in this document are backwardly compatible.
	Existing implementations may cause extension information to be lost,		Existing implementations may cause extension information to be lost,
	but the presence of extensions does not affect an implementation that		but the presence of extensions does not affect an implementation that
	conforms to either [RFC4776] or [RFC5139].		conforms to either [RFC4776] or [RFC5139].
	This document also normatively updates [RFC5222] to clarify that the		This document also normatively updates [RFC5222] to clarify that the
	namespace must be included with the element name in the lists of		namespace must be included with the element name in the lists of
	valid, invalid and not checked elements in the <locationValidation>		valid, invalid and not checked elements in the <locationValidation>
	part of a LoST response. While the LoST schema does not need to be		part of a LoST response. While the LoST schema does not need to be
	changed, the example in the document is updated to show the		changed, the example in the document is updated to show the
	namespaces in the lists.		namespaces in the lists.
	skipping to change at page 8, line 48 ¶		skipping to change at page 8, line 48 ¶
	4. CAtypes Registry		4. CAtypes Registry
	[RFC4776] created the CAtype registry. Among other things, this		[RFC4776] created the CAtype registry. Among other things, this
	registry advertised available civic elements. While it has always		registry advertised available civic elements. While it has always
	been possible to use an extension namespace to define civic elements		been possible to use an extension namespace to define civic elements
	that are not in the CAtype registry, and this document does not		that are not in the CAtype registry, and this document does not
	change that, the registry is valuable to alert implementors of		change that, the registry is valuable to alert implementors of
	commonly used civic elements and provides guidance to clients of what		commonly used civic elements and provides guidance to clients of what
	elements they should suppport.		elements they should suppport.
	This document creates a new CAtype registry that differs from the		This document alters the CAtype registry in several ways. It closes
	original CAtype registry in two ways. The original registry is		the registry to new numeric CAtypes. It deletes the "NENA" column,
	closed to new numeric CAtypes. The new registry adds a column to the		which is not needed. It adds columns for a namespace and contact,
	registry called "Type". "Type" can have one of two values "A" or		and changes the name of the column currently called "PIDF" to "Local
	"B". Type A elements are intended for wide use with many		Name". It also adds a column to the registry called "Type". "Type"
	applications and SHOULD be implemented by all clients unless the		can have one of two values "A" and "B". Type A elements are intended
	client is certain the element will not be encountered. Type "B"		for wide use with many applications and SHOULD be implemented by all
	civic elements MAY be implemented by any client.		clients unless the client is certain the element will not be
			encountered. Type "B" civic elements MAY be implemented by any
			client.
	Type A civic elements require IETF review, while Type B elements only		Type A civic elements require IETF review, while Type B elements only
	require an expert review.		require an expert review.
	5. Civic Extensions		5. Civic Extensions
	We use this new extension method to define some additional civic		We use this new extension method to define some additional civic
	address elements which are needed to correctly encode civic locations		address elements which are needed to correctly encode civic locations
	in several countries. The definition of these new civic address		in several countries. The definition of these new civic address
	elements also serves as an example of how to define additional		elements also serves as an example of how to define additional
	skipping to change at page 10, line 31 ¶		skipping to change at page 10, line 31 ¶
	| | \|,,,|		| | \|,,,|
	_ | |		_ | |
	``-..|.|		``-..|.|
	``--.._		``--.._
	`'--.._		`'--.._
	Figure 5: Lamp post with emergency number		Figure 5: Lamp post with emergency number
	5.2. Mile Post		5.2. Mile Post
	On some roads, and many trails, railroad rights of way and other		On some roads, trails, railroad rights of way and other linear
	linear features, a post with a mile or kilometer distance from one		features, a post with a mile or kilometer distance from one end of
	end of the feature may be found (a "milepost"). There are other		the feature may be found (a "milepost"). There are other cases of
	cases of poles or markers with numeric indications that are not the		poles or markers with numeric indications that are not the same as a
	same as a "house number" or street address number.		"house number" or street address number.
	5.3. Street Type Prefix		5.3. Street Type Prefix
	The civic schema defined in [RFC5139] allows the definition of		The civic schema defined in [RFC5139] allows the definition of
	address "123 Colorado Boulevard", but it does not allow for the easy		address "123 Colorado Boulevard", but it does not allow for the easy
	expression of "123 Boulevard Colorado". Adding a street-type prefix,		expression of "123 Boulevard Colorado". Adding a street-type prefix,
	allows street named in this manner to be more easily represented.		allows street named in this manner to be more easily represented.
	5.4. House Number Prefix		5.4. House Number Prefix
	skipping to change at page 13, line 43 ¶		skipping to change at page 13, line 43 ¶
	This document defines a formal way to extend the existing Geopriv		This document defines a formal way to extend the existing Geopriv
	civic address schema. No security threats are introduced by this		civic address schema. No security threats are introduced by this
	document.		document.
	Security threats applicable to the civic address formats are		Security threats applicable to the civic address formats are
	described in [RFC4776] (DHCP) and [RFC5139] (XML).		described in [RFC4776] (DHCP) and [RFC5139] (XML).
	8. IANA Considerations		8. IANA Considerations
	This document replaces the "CAtypes" registry established by		This document alters the "CAtypes" registry established by [RFC4776].
	[RFC4776].
	8.1. CAtype Registration for Extensions		8.1. CAtype Registration for Extensions
	IANA has allocated a CAtype code of XX for the extension CAtype.		IANA has allocated a CAtype code of XX for the extension CAtype.
	[[IANA/RFC-EDITOR: Please replace XX with the allocated CAtype]]		[[IANA/RFC-EDITOR: Please replace XX with the allocated CAtype]]
	8.2. End of Numeric CAtype Registration		8.2. Changes to the CAtype Registry
	No further registration of numeric CAtypes is permitted, and the		No further registration of numeric CAtypes is permitted.
	registry created as part of [RFC4776] replaced with the registry
	defined in this document. New registrations use the registration		The column called "NENA" is removed.
	template in Section 8.5.
			The column called "PIDF" is renamed to "Local Name".
			New columns are added named "Namespace URI", "Contact", "Schema" and
			"Type".
			New registrations use the registration template in Section 8.5.
	8.3. URN sub-namespace registration for		8.3. URN sub-namespace registration for
	'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext'		'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext'
	This document calls for IANA to register a new XML namespace, as per		This document calls for IANA to register a new XML namespace, as per
	the guidelines in [RFC3688].		the guidelines in [RFC3688].
	URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext		URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
	Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),		Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
	skipping to change at page 16, line 11 ¶		skipping to change at page 16, line 11 ¶
	Registrations from [RFC4776] and [RFC5139] are registered with the		Registrations from [RFC4776] and [RFC5139] are registered with the
	following form:		following form:
	CAtype: (The existing CAtype.)		CAtype: (The existing CAtype.)
	Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr		Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
	Local Name: (The contents of the PIDF column.)		Local Name: (The contents of the PIDF column.)
	Description: (The existing description for the element, including a		Description: (The existing description for the element.)
	note about the equivalent NENA field, if present.)
	Contact: The IESG (iesg@ietf.org); the GEOPRIV working group		Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
	(geopriv@ietf.org).		(geopriv@ietf.org).
	Specification: RFC4776 and RFC5139		Specification: RFC4776 and RFC5139
	Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr		Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
	Type: A		Type: A
	skipping to change at page 17, line 4 ¶		skipping to change at page 16, line 48 ¶
	Description: HNP: House Number Prefix.		Description: HNP: House Number Prefix.
	Contact: The IESG (iesg@ietf.org); the GEOPRIV working group		Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
	(geopriv@ietf.org).		(geopriv@ietf.org).
	Specification: RFCXXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC		Specification: RFCXXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC
	URL and replace XXXX with the RFC number for this specification.]]		URL and replace XXXX with the RFC number for this specification.]]
	Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext		Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
	Type: A		Type: A
	8.6. Registration Policy and Expert Guidance		8.6. Registration Policy and Expert Guidance
	The "CAtypes" registry will operate on a registration policy of		The "CAtypes" registry is altered to operate on a registration policy
	"Expert Review", and optionally "Specification Required" [RFC5226] if		of "Expert Review", and optionally "Specification Required" [RFC5226]
	the element being registered has a Type value of "B".		if the element being registered has a Type value of "B".
	The registration rules for "Specification Required" are followed only		The registration rules for "Specification Required" are followed only
	if a registration includes a reference to a specification.		if a registration includes a reference to a specification.
	Registrations can be made without a specification reference.		Registrations can be made without a specification reference.
	If the element being registered has a Type value of "A" then the		If the element being registered has a Type value of "A" then the
	registration policy is "IETF Review".		registration policy is "IETF Review".
	All registrations are reviewed to identify potential duplication		All registrations are reviewed to identify potential duplication
	between registered elements. Duplicated semantics are not prohibited		between registered elements. Duplicated semantics are not prohibited
	skipping to change at page 19, line 9 ¶		skipping to change at page 18, line 43 ¶
	Object (PIDF-LO): Guidelines and IANA Registry		Object (PIDF-LO): Guidelines and IANA Registry
	Definition", BCP 154, RFC 5774, March 2010.		Definition", BCP 154, RFC 5774, March 2010.
	[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",		[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
	RFC 5985, September 2010.		RFC 5985, September 2010.
	Authors' Addresses		Authors' Addresses
	James Winterbottom		James Winterbottom
	CommScope		CommScope
	Andrew Building (39)		Suit 1, Level 2
	Wollongong University Campus		iC Enterprise 1, Innovation Campus
	Northfields Avenue		Squires Way
	Wollongong, NSW 2522		North Wollongong, NSW 2500
	AU		AU
	Phone: +61 242 212938		Phone: +61 242 212938
	Email: james.winterbottom@commscope.com		Email: james.winterbottom@commscope.com
	Martin Thomson		Martin Thomson
	CommScope		Skype
	Andrew Building (39)		3210 Porter Drive
	Wollongong University Campus		Palo Alto, California 94304
	Northfields Avenue		US
	Wollongong, NSW 2522
	AU
	Phone: +61 2 4221 2915		Email: martin.thomson@gmail.com
	Email: martin.thomson@commscope.com
	Richard Barnes		Richard Barnes
	BBN Technologies		BBN Technologies
	9861 Broken Land Parkway		9861 Broken Land Parkway
	Columbia, MD 21046		Columbia, MD 21046
	US		US
	Phone: +1 410 290 6169		Phone: +1 410 290 6169
	Email: rbarnes@bbn.com		Email: rbarnes@bbn.com
End of changes. 22 change blocks.
	53 lines changed or deleted		57 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/