< draft-ietf-geopriv-revised-civic-lo-04.txt		draft-ietf-geopriv-revised-civic-lo-05.txt >
	GEOPRIV WG M. Thomson		GEOPRIV WG M. Thomson
	Internet-Draft J. Winterbottom		Internet-Draft J. Winterbottom
	Intended status: Informational Andrew		Updates: 4119 (if approved) Andrew
	Expires: March 24, 2007 September 20, 2006		Intended status: Standards Track February 15, 2007
			Expires: August 19, 2007
	Revised Civic Location Format for PIDF-LO		Revised Civic Location Format for PIDF-LO
	draft-ietf-geopriv-revised-civic-lo-04.txt		draft-ietf-geopriv-revised-civic-lo-05.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 35 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 24, 2007.		This Internet-Draft will expire on August 19, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document defines an XML format for the representation of civic		This document defines an XML format for the representation of civic
	location. This format is designed for use with PIDF Location Object		location. This format is designed for use with PIDF Location Object
	(PIDF-LO) documents. The format is based on the civic address		(PIDF-LO) documents. The format is based on the civic address
	definition in PIDF-LO, but adds several new elements based on the		definition in PIDF-LO, but adds several new elements based on the
	civic types defined for DHCP, and adds a hierarchy to address complex		civic types defined for DHCP, and adds a hierarchy to address complex
	road identity schemes. The format also includes support for the		road identity schemes. The format also includes support for the
	xml:lang language tag and restricts the types of elements where		xml:lang language tag and restricts the types of elements where
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 5		3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Additional Civic Address Types . . . . . . . . . . . . . . 5		3.1. Additional Civic Address Types . . . . . . . . . . . . . . 5
	3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 6		3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 6
	3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 7		3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 7
	3.2.2. Directionals and other Qualifiers . . . . . . . . . . 7		3.2.2. Directionals and other Qualifiers . . . . . . . . . . 7
	3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 7		3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 7
	3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 7		3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 8		3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 8
	3.5.1. Converting from the DHCP Format . . . . . . . . . . . 8		3.5.1. Converting from the DHCP Format . . . . . . . . . . . 8
	3.5.2. Combining Multiple Elements Based on Language		3.5.2. Combining Multiple Elements Based on Language
	Preferences . . . . . . . . . . . . . . . . . . . . . 9		Preferences . . . . . . . . . . . . . . . . . . . . . 8
	3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 9		3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 9
	4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 10		4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 10
	5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	7.1. URN sub-namespace registration for		7.1. URN sub-namespace registration for
	'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 14		'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 14
	7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14		7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		7.3. CAtype Registry Update . . . . . . . . . . . . . . . . . . 15
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 15		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.2. Informative References . . . . . . . . . . . . . . . . . . 15		8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16		8.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
			Intellectual Property and Copyright Statements . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Since the publication of the original PIDF-LO civic specification, in		Since the publication of the original PIDF-LO civic specification, in
	[RFC4119], it has been found that the specification is lacking a		[RFC4119], it has been found that the specification is lacking a
	number of additional parameters that can be used to more precisely		number of additional parameters that can be used to more precisely
	specify a civic location. These additional parameters have been		specify a civic location. These additional parameters have been
	largely captured in [I-D.ietf-geopriv-dhcp-civil].		largely captured in [RFC4776].
	This document revises the GEOPRIV civic form to include the		This document revises the GEOPRIV civic form to include the
	additional civic parameters captured in		additional civic parameters captured in [RFC4776]. The document also
	[I-D.ietf-geopriv-dhcp-civil]. The document also introduces a		introduces a hierarchical structure for thoroughfare (road)
	hierarchical structure for thoroughfare (road) identification which		identification which is employed in some countries. New elements are
	is employed in some countries. New elements are defined to allow for		defined to allow for even more precision in specifying a civic
	even more precision in specifying a civic location.		location.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	The term "thoroughfare" is used in this document to describe a road		The term "thoroughfare" is used in this document to describe a road
	or part of a road or other access route along which a final point is		or part of a road or other access route along which a final point is
	identified. This is consistent with the definition used in		identified. This is consistent with the definition used in
	[UPU-S42].		[UPU-S42].
	3. Changes from PIDF-LO		3. Changes from PIDF-LO
	3.1. Additional Civic Address Types		3.1. Additional Civic Address Types
	[I-D.ietf-geopriv-dhcp-civil] provides a full set of parameters that		[RFC4776] provides a full set of parameters that may be used to
	may be used to describe a civic location. Specifically		describe a civic location. Specifically [RFC4776] lists several
	[I-D.ietf-geopriv-dhcp-civil] lists several civic address types		civic address types (CAtypes) that require support in the formal
	(CAtypes) that require support in the formal PIDF-LO definition that		PIDF-LO definition that are not in [RFC4119].
	are not in [RFC4119].
	These changes include and new elements that are required to support		These changes include and new elements that are required to support
	more complex structures for naming street addresses, this is		more complex structures for naming street addresses, this is
	described in more detail in Section 3.2.		described in more detail in Section 3.2.
	+---------------+--------+----------------------------+-------------+		+---------------+--------+----------------------------+-------------+
	| New Civic | CAtype | Description | Example |		| New Civic | CAtype | Description | Example |
	| Field | | | |		| Field | | | |
	+---------------+--------+----------------------------+-------------+		+---------------+--------+----------------------------+-------------+
	| BLD | 25 | Building (structure) | Hope |		| BLD | 25 | Building (structure) | Hope |
	skipping to change at page 6, line 6 ¶		skipping to change at page 6, line 6 ¶
	| RDBR | 36 | Road branch | Lane 7 |		| RDBR | 36 | Road branch | Lane 7 |
	| | | | |		| | | | |
	| RDSUBBR | 37 | Road sub-branch | Alley 8 |		| RDSUBBR | 37 | Road sub-branch | Alley 8 |
	| | | | |		| | | | |
	| PRM | 38 | Road pre-modifier | Old |		| PRM | 38 | Road pre-modifier | Old |
	| | | | |		| | | | |
	| POM | 39 | Road post-modifier | Extended |		| POM | 39 | Road post-modifier | Extended |
	+---------------+--------+----------------------------+-------------+		+---------------+--------+----------------------------+-------------+
	Table 1: New Civic PIDF-LO Types		Table 1: New Civic PIDF-LO Types
	A complete description of these types is included in		A complete description of these types is included in [RFC4776].
	[I-D.ietf-geopriv-dhcp-civil].
	3.2. New Thoroughfare Elements		3.2. New Thoroughfare Elements
	In some countries a thoroughfare can be broken up into sections, and		In some countries a thoroughfare can be broken up into sections, and
	it is not uncommon for street numbers to be repeated between		it is not uncommon for street numbers to be repeated between
	sections. A road section identifier is required to ensure that an		sections. A road section identifier is required to ensure that an
	address is unique. For example, "West Alice Parade" has 5 sections,		address is unique. For example, "West Alice Parade" has 5 sections,
	each numbered from 1; unless the section is specified "7 West Alice		each numbered from 1; unless the section is specified "7 West Alice
	Parade" could exist in 5 different places. The "RDSEC" element is		Parade" could exist in 5 different places. The "RDSEC" element is
	used to specify the section.		used to specify the section.
	skipping to change at page 6, line 37 ¶		skipping to change at page 6, line 36 ¶
	Similar to the way that a road branch is associated with a road, a		Similar to the way that a road branch is associated with a road, a
	road sub-branch is associated with a road branch. The "RDSUBBR"		road sub-branch is associated with a road branch. The "RDSUBBR"
	element is used to identify road sub-branches.		element is used to identify road sub-branches.
	The "A6" element is retained for use in those countries that require		The "A6" element is retained for use in those countries that require
	this level of detail. Where "A6" was previously used for street		this level of detail. Where "A6" was previously used for street
	names in [RFC4119], it MUST NOT be used, the "RD" element MUST be		names in [RFC4119], it MUST NOT be used, the "RD" element MUST be
	used for thoroughfare data. However, without additional information		used for thoroughfare data. However, without additional information
	these fields MUST not be interchanged when converting between		these fields MUST not be interchanged when converting between
	different civic formats. Where civic address information is obtained		different civic formats. Where civic address information is obtained
	from another format, such as the DHCP form		from another format, such as the DHCP form [RFC4776], the "A6"
	[I-D.ietf-geopriv-dhcp-civil], the "A6" element MUST be copied		element MUST be copied directly from the source format.
	directly from the source format.
	The following example figure shows a fictional arrangement of roads		The following example figure shows a fictional arrangement of roads
	where these new thoroughfare elements are applicable.		where these new thoroughfare elements are applicable.
	| ||		| ||
	| ---------------||		| ---------------||
	| Carol La. Carol La. || Bob		| Carol La. Carol La. || Bob
	| || St.		| || St.
	| West Alice Pde. ||		| West Alice Pde. ||
	==========/=================/===============/==========||===========		==========/=================/===============/==========||===========
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 4 ¶
	LU-L; Australia uses both two and three character codes: AU-ACT, AU-		LU-L; Australia uses both two and three character codes: AU-ACT, AU-
	NSW, AU-NT; France uses numerical codes for mainland France and		NSW, AU-NT; France uses numerical codes for mainland France and
	letters for territories: FR-75, FR-NC. This results in the following		letters for territories: FR-75, FR-NC. This results in the following
	fragments:		fragments:
	<country>CA</country><A1>ON</A1>		<country>CA</country><A1>ON</A1>
	<country>LU</country><A1>L</A1>		<country>LU</country><A1>L</A1>
	<country>AU</country><A1>ACT</A1>		<country>AU</country><A1>ACT</A1>
	<country>FR</country><A1>75</A1>		<country>FR</country><A1>75</A1>
	3.5. Languages and Scripts		3.5. Languages and Scripts
	The XML schema defined for civic addresses allows for the addition of		The XML schema defined for civic addresses allows for the addition of
	the "xml:lang" attribute to all elements except "country" and "PLC",		the "xml:lang" attribute to all elements except "country" and "PLC",
	which both contain enumerated values.		which both contain enumerated values.
	The "script" field defined in [I-D.ietf-geopriv-dhcp-civil] is		The "script" field defined in [RFC4776] is omitted in favour of using
	omitted in favour of using the "xml:lang" attribute.		the "xml:lang" attribute.
	It is RECOMMENDED that each "civicAddress" element use one language		It is RECOMMENDED that each "civicAddress" element use one language
	only, or a combination of languages that is consistent. Where a		only, or a combination of languages that is consistent. Where a
	civic location is represented in multiple languages multiple		civic location is represented in multiple languages multiple
	"civicAddress" elements SHOULD be included in the PIDF-LO document.		"civicAddress" elements SHOULD be included in the PIDF-LO document.
	For civic addresses that form a complex to describe the same		For civic addresses that form a complex to describe the same
	location, these SHOULD be inserted into the same tuple.		location, these SHOULD be inserted into the same tuple.
	3.5.1. Converting from the DHCP Format		3.5.1. Converting from the DHCP Format
	The DHCP format for civic addresses [I-D.ietf-geopriv-dhcp-civil]		The DHCP format for civic addresses [RFC4776] permits the inclusion
	permits the inclusion of an element multiple times with different		of an element multiple times with different languages or scripts.
	languages or scripts. However, this XML form only permits a single		However, this XML form only permits a single instance of each
	instance of each element. Multiple "civicAddress" elements are		element. Multiple "civicAddress" elements are required if any
	required if any element is duplicated with different languages. If		element is duplicated with different languages. If the same language
	the same language and script is used for all elements, or no elements		and script is used for all elements, or no elements are duplicated,
	are duplicated, the format can be converted into a single civic		the format can be converted into a single civic address.
	address.
	Where there are duplicated elements in different languages, a		Where there are duplicated elements in different languages, a
	"civicAddress" element is created for each language that is present.		"civicAddress" element is created for each language that is present.
	All elements that are in that language are included. Elements that		All elements that are in that language are included. Elements that
	are language independent, like the "country" and "PLC" elements, are		are language independent, like the "country" and "PLC" elements, are
	added to all "civicAddress" elements.		added to all "civicAddress" elements.
	3.5.2. Combining Multiple Elements Based on Language Preferences		3.5.2. Combining Multiple Elements Based on Language Preferences
	If the receiver of the XML representation is known, and that receiver		If the receiver of the XML representation is known, and that receiver
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 5 ¶
	[RFC3688].		[RFC3688].
	URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr		URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
	Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),		Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
	Martin Thomson (martin.thomson@andrew.com).		Martin Thomson (martin.thomson@andrew.com).
	The XML for this schema can be found as the entirety of Section 4		The XML for this schema can be found as the entirety of Section 4
	of this document.		of this document.
			7.3. CAtype Registry Update
			This document updates the civic address type registry established by
			[RFC4776]. The "PIDF" column of the CAtypes table has been updated
			to include the types shown in the first column of Table 1.
	8. References		8. References
	8.1. Normative References		8.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
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[W3C.REC-xmlschema-2-20041028]		[W3C.REC-xmlschema-2-20041028]
	Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes		Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
	Second Edition", World Wide Web Consortium		Second Edition", World Wide Web Consortium
	Recommendation REC-xmlschema-2-20041028, October 2004,		Recommendation REC-xmlschema-2-20041028, October 2004,
	<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.		<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
	[I-D.ietf-geopriv-dhcp-civil]		[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
	Schulzrinne, H., "Dynamic Host Configuration Protocol		(DHCPv4 and DHCPv6) Option for Civic Addresses
	(DHCPv4 and DHCPv6) Option for Civic Addresses		Configuration Information", RFC 4776, November 2006.
	Configuration Information",
	draft-ietf-geopriv-dhcp-civil-09 (work in progress),
	January 2006.
	[ISO.3166-1]		[ISO.3166-1]
	International Organization for Standardization, "Codes for		International Organization for Standardization, "Codes for
	the representation of names of countries and their		the representation of names of countries and their
	subdivisions - Part 1: Country codes", ISO Standard 3166-		subdivisions - Part 1: Country codes", ISO Standard 3166-
	1:1997, 1997,		1:1997, 1997,
	<http://www.iso.org/iso/en/prods-services/iso3166ma/>.		<http://www.iso.org/iso/en/prods-services/iso3166ma/>.
	[ISO.3166-2]		[ISO.3166-2]
	International Organization for Standardization, "Codes for		International Organization for Standardization, "Codes for
	skipping to change at page 18, line 7 ¶		skipping to change at page 19, line 7 ¶
	PO Box U40		PO Box U40
	Wollongong University Campus, NSW 2500		Wollongong University Campus, NSW 2500
	AU		AU
	Phone: +61 2 4221 2938		Phone: +61 2 4221 2938
	Email: james.winterbottom@andrew.com		Email: james.winterbottom@andrew.com
	URI: http://www.andrew.com/		URI: http://www.andrew.com/
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 18 change blocks.
	50 lines changed or deleted		50 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/