draft-ietf-geopriv-local-civic-07.txt		draft-ietf-geopriv-local-civic-08.txt
	skipping to change at page 1, line 16		skipping to change at page 1, line 16
	Intended status: Standards Track Skype		Intended status: Standards Track Skype
	Expires: April 4, 2013 R. Barnes		Expires: April 4, 2013 R. Barnes
	BBN Technologies		BBN Technologies
	B. Rosen		B. Rosen
	NeuStar, Inc.		NeuStar, Inc.
	R. George		R. George
	Huawei Technologies		Huawei Technologies
	Oct 2012		Oct 2012
	Specifying Civic Address Extensions in PIDF-LO		Specifying Civic Address Extensions in PIDF-LO
	draft-ietf-geopriv-local-civic-07		draft-ietf-geopriv-local-civic-08
	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 (RFC5222) protocol mechanism that returns civic		defined. The LoST (RFC5222) protocol mechanism that returns civic
	skipping to change at page 2, line 19		skipping to change at page 2, line 19
	(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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 5		1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 4
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Specifying Civic Address Extensions . . . . . . . . . . . . . 5		2. Specifying Civic Address Extensions . . . . . . . . . . . . . 4
	3. Translating Unsupported Elements . . . . . . . . . . . . . . . 7		3. Translating Unsupported Elements . . . . . . . . . . . . . . . 6
	3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 7		3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6
	3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 7		3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6
	3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 8		3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 7
	3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 8		3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 8
	4. CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . . 9		4. CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 10		5. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 10		5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 11		5.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 11		5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 10
	5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 11		5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 10
	5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 12		5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 11
	5.6. Extension examples . . . . . . . . . . . . . . . . . . . . 12		5.6. Extension examples . . . . . . . . . . . . . . . . . . . . 11
	6. Using Local Civic Extension with the LoST Protocol . . . . . . 13		6. Using Local Civic Extension with the LoST Protocol . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	8.1. CAtype Registration for Extensions . . . . . . . . . . . . 15		8.1. CAtype Registration for Extensions . . . . . . . . . . . . 14
	8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 15		8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 14
	8.3. URN sub-namespace registration for		8.3. Registration Template . . . . . . . . . . . . . . . . . . 14
	'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext' . . 15		8.4. Registration of the CAtypes defined in this document . . . 15
	8.4. XML Schema Registration . . . . . . . . . . . . . . . . . 16		8.5. Registration Policy and Expert Guidance . . . . . . . . . 16
	8.5. Registration Template . . . . . . . . . . . . . . . . . . 16		8.6. URN sub-namespace registration . . . . . . . . . . . . . . 17
	8.5.1. Registration of the schema defined in this document . 17		8.7. XML Schema Registration . . . . . . . . . . . . . . . . . 17
	8.6. Registration Policy and Expert Guidance . . . . . . . . . 18		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 19		10.2. Informative References . . . . . . . . . . . . . . . . . . 19
	10.2. Informative References . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	The Geopriv civic location specifications ([RFC4776], [RFC5139])		The Geopriv civic location specifications ([RFC4776], [RFC5139])
	define an XML and binary representations 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
	skipping to change at page 7, line 8		skipping to change at page 6, line 8
	The address can be passed to other applications, such as a LoST		The address can be passed to other applications, such as a LoST
	server [RFC5222], without modification. If the application		server [RFC5222], without modification. If the application
	understands the added element(s), it is able to make use of that		understands the added element(s), it is able to make use of that
	information. For example, if this civic address is acquired using		information. For example, if this civic address is acquired using
	HELD [RFC5985], it can be included in a LoST request directly.		HELD [RFC5985], it can be included in a LoST request directly.
	3. Translating Unsupported Elements		3. Translating Unsupported Elements
	Unsupported civic address elements can be carried without consequence		Unsupported civic address elements can be carried without consequence
	only as long as the format of the address does not change. When		as long as the format of the address does not change. However,
	converting between the XML and DHCP formats, these unsupported		conversion between formats has been shown to be necessary.
	elements are necessarily discarded: the entity performing the
	translation has no way to know the correct element to use in the
	target format.
	All extensions MUST be defined using the mechanism described in this		Format conversion required knowledge of the format of the address
	document. Extensions that use numeric CAtypes or other mechanisms		elements. An entity performing a conversion between XML and DHCP
	cannot be safely translated between XML and DHCP representations.		address formats was forced to discard unrecognized elements. The
			entity performing the conversion had no way to know the correct
			element to use in the target format.
	An entity that does not support these extension mechanisms is		This document defines a single extension element for the DHCP format
	expected to remove elements it doesn't understand when performing		that makes knowledge of extensions unnecessary during conversion.
	conversions.		This extension element relies on the extension mechanisms defined for
			the XML format. New extensions to the civic address format MUST be
			defined only for the XML format; these extensions are then conveyed
			in DHCP using the extension element.
			Further extensions to the DHCP format are prohibited: these
			extensions cannot be safely conveyed in environments where conversion
			is possible.
	3.1. XML to DHCP Format Translation		3.1. XML to DHCP Format Translation
	Extensions to the XML format [RFC5139] are defined in a new XML		Extensions to the XML format [RFC5139] are defined in a new XML
	namespace [XMLNS].		namespace [XMLNS].
	Extensions in the XML format can be added to a DHCP format civic		Extensions in the XML format can be added to a DHCP format civic
	address using an extension CAtype.		address using an extension CAtype.
	3.2. Extension Civic Address Type (CAtype)		3.2. Extension Civic Address Type (CAtype)
	skipping to change at page 15, line 8		skipping to change at page 14, line 8
	described in [RFC4776] (DHCP) and [RFC5139] (XML).		described in [RFC4776] (DHCP) and [RFC5139] (XML).
	8. IANA Considerations		8. IANA Considerations
	This document alters the "CAtypes" registry on the "Civic Address		This document alters the "CAtypes" registry on the "Civic Address
	Types Registry" page established by [RFC4776].		Types Registry" page established by [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.
			Registrations using this code will be made below, in Section 8.4.
	[[IANA/RFC-EDITOR: Please replace XX with the allocated CAtype]]
	8.2. Changes to the CAtype Registry		8.2. Changes to the CAtype Registry
	No further registration of numeric CAtypes in the Civic Address Types		IANA ia asked to make the following changes to the CAtype registry:
	Registry is permitted.
	The column called "NENA" is removed.
	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.		o No registrations of new CAtype numbers in the Civic Address Types
			Registry are permitted, except by IESG Approval [RFC5226] under
			unusual circumstances.
	8.3. URN sub-namespace registration for		o The following note will be placed in the header of the CAtypes
	'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext'		registry, above the table:
	This document calls for IANA to register a new XML namespace, as per		Note: As specified in [[this RFC]], new registrations are only
	the guidelines in [RFC3688].		accepted for CAtype XX, using the template specified in
			Section 8.3.
	URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext		o The registration procedures are changed: IETF Review (if Type=A),
			Expert Review (if Type=B). The designated expert is unchanged.
	Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),		o The reference for the table is changed: [RFC4776], [[this RFC]]
	James Winterbottom (james.winterbottom@commscope.com).
	XML:		o The column called "NENA" is removed.
	BEGIN		o The column called "PIDF" is renamed to "Local Name".
	<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
	<head>
	<title>GEOPRIV Civic Address Extensions</title>
	</head>
	<body>
	<h1>Additional Fields for GEOPRIV Civic Address</h1>
	<h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</h2>
	[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
	with the RFC number for this specification.]]
	<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
	</body>
	</html>
	END
	8.4. XML Schema Registration		o New columns are added named "Namespace URI", "Contact", "Schema"
			and "Type". All existing entries will have the following values
			for those new columns:
	This section registers an XML schema as per the procedures in		Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
	[RFC3688].
	URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext		Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
			(geopriv@ietf.org)
	Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),		Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
	James Winterbottom (james.Winterbottom@commscope.com).
	The XML for this schema can be found as the entirety of		Type: A
	Section 5.5 of this document.
	8.5. Registration Template		8.3. Registration Template
	New registrations in the Civic Address Types Registry require the		New registrations in the Civic Address Types Registry require the
	following information:		following information:
	CAtype: The assigned numeric CAtype. All new registrations use the		CAtype: The assigned numeric CAtype. All new registrations will use
	value XX. [[IANA/RFC-Editor: update XX] Existing registrations		the value XX.
	use their assigned value.
	Namespace URI: A unique identifier for the XML namespace used for		Namespace URI: A unique identifier for the XML namespace used for
	the extension element.		the extension element.
	Local Name: The local name of an XML element that carries the civic		Local Name: The local name of an XML element that carries the civic
	address element.		address element.
	Description: A brief description of the semantics of the civic		Description: A brief description of the semantics of the civic
	address element.		address element.
	(Optional) Example: One or more simple examples of the element.		Example (optional): One or more simple examples of the element.
	Contact: Contact details for the person providing the extension.		Contact: Contact details for the person providing the extension.
	(Optional) Specification: A reference to a specification for the		Specification (optional): A reference to a specification for the
	civic address element.		civic address element.
	(Optional) Schema: A reference to a formal schema (XML schema,		Schema (optional): A reference to a formal schema (XML schema,
	RelaxNG, or other form) that defines the extension.		RelaxNG, or other form) that defines the extension.
	Type: If Type is "A", all clients SHOULD implement this element. If		Type: "A" or "B".
			If Type is "A", all clients SHOULD implement this element. If
	Type is "B", clients MAY implement this element.		Type is "B", clients MAY implement this element.
	Registrations from [RFC4776] and [RFC5139] are registered with the		8.4. Registration of the CAtypes defined in this document
	following form:
	CAtype: (The existing CAtype.)
	Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
	Local Name: (The contents of the PIDF column.)
	Description: (The existing description for the element.)
	Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
	(geopriv@ietf.org).
	Specification: RFC4776 and RFC5139
	Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
	Type: A
	8.5.1. Registration of the schema defined in this document
	This section registers the following four new CATypes in the Civic		This section registers the following four new CATypes in the Civic
	Address Types Registry per the scheme in Section 5.5 whose parameters		Address Types Registry.
	are identical except for their Local Names and Descriptions:
	CAtype: The assigned numeric CAtype value is XX. [[IANA/RFC-Editor:
	update XX]
			Post Number (see Section 5.1):
			CAtype: XX
	Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext		Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
	Local Name: PN		Local Name: PN
			Description: Post number that is attributed to a lamp post or
	Description: PN: Post number that is attributed to a lamp post or
	utility pole.		utility pole.
			Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
			(geopriv@ietf.org)
			Specification: [[this RFC]], Section 5
			Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
			Type: A
	Local Name: MP		Mile Post (see Section 5.2):
	Description: MP: Mile Post a marker indicating distance to or from a		CAtype: XX
			Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
			Local Name: MP
			Description: Mile Post a marker indicating distance to or from a
	place (often a town).		place (often a town).
			Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
			(geopriv@ietf.org)
			Specification: [[this RFC]], Section 5
			Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
			Type: A
			Street Type Prefix (see Section 5.3):
			CAtype: XX
			Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
	Local Name: STP		Local Name: STP
			Description: Street Type Prefix.
			Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
			(geopriv@ietf.org)
			Specification: [[this RFC]], Section 5
			Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
			Type: A
	Description: STP: Street Type Prefix.		House Number Prefix (see Section 5.4):
			CAtype: XX
			Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
	Local Name: HNP		Local Name: HNP
			Description: 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: [[this RFC]], Section 5
	Specification: RFCXXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC
	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.5. Registration Policy and Expert Guidance
	The "CAtypes" registry is altered to operate on a registration policy		The "CAtypes" registry is altered to operate on a registration policy
	of "Expert Review", and optionally "Specification Required" [RFC5226]		of "Expert Review", and optionally "Specification Required" [RFC5226]
	if 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" [RFC5226].
	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
	in the registry, though it is preferred if existing elements are		in the registry, though it is preferred if existing elements are
	used. The expert review is advised to recommend the use of existing		used. The expert review is advised to recommend the use of existing
	elements following the guidance in [RFC5774]. Any registration that		elements following the guidance in [RFC5774]. Any registration that
	is a duplicate or could be considered a close match for the semantics		is a duplicate or could be considered a close match for the semantics
	of an existing element SHOULD include a discussion of the reasons		of an existing element SHOULD include a discussion of the reasons
	that the existing element was not reused.		that the existing element was not reused.
			8.6. URN sub-namespace registration
			This document calls for IANA to register a new XML namespace, as per
			the guidelines in [RFC3688].
			URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
			Registrant Contact: IETF GEOPRIV working group, (geopriv@ietf.org),
			James Winterbottom (james.Winterbottom@commscope.com)
			XML:
			BEGIN
			<?xml version="1.0"?>
			<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
			"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
			<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
			<head>
			<title>GEOPRIV Civic Address Extensions</title>
			</head>
			<body>
			<h1>Additional Fields for GEOPRIV Civic Address</h1>
			<h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</h2>
			<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
			</body>
			</html>
			END
			8.7. XML Schema Registration
			This section registers an XML schema as per the procedures in
			[RFC3688]
			URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
			Registrant Contact: IETF GEOPRIV working group, (geopriv@ietf.org),
			James Winterbottom (james.Winterbottom@commscope.com)
			XML: The XML for this schema can be found as the entirety of
			Section 5.5 of this document.
	9. Acknowledgements		9. Acknowledgements
	Thanks to anyone who has tried to extend the civic schema and found		Thanks to anyone who has tried to extend the civic schema and found
	it a little less than intuitive.		it a little less than intuitive.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
End of changes. 44 change blocks.
	142 lines changed or deleted		158 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/