The Geopriv civic location specifications (, ) define an XML and binary representations for civic addresses that allow for the expression of civic addresses. Guidance for the use of these formats for the civic addresses in different countries is included in . Subsequent to these specifications being produced, use cases for extending the civic address format with new elements have emerged. describes a mechanism for mapping long-standing address formats into the civic address elements defined in and . However, some of these existing address elements do not readily fit into the civic address elements defined in and . In these cases, creating new civic address elements provides a better solution than overloading existing civic address fields, which may cause confusion. The XML format for civic addresses provides a mechanism that allows for the addition of standardized or privately understood elements. A similar facility for private extension is not provided for the DHCP format, though new specifications are able to define new CAtypes (civic address types). A recipient of a civic address in either format currently has no option other than to ignore elements that it does not understand. This results in any elements that are unknown to that recipient being discarded if a recipient performs a translation between the two formats. In order for a new extension to be preserved through translation by any recipient, the recipient has to understand the extension and know how to correlate an XML element with a CAtype. This document describes how new civic address elements are added. Extensions always start with the definition of XML elements. A mechanism for carrying the extension in the DHCP format is described. A new XML namespace containing a small number of additional civic elements is also defined and can be used as a template to illustrate how other extensions can be defined as required. These mechanisms ensure that any translation between formats can be performed consistently and without loss of information. Translation between formats can occur without knowledge of every extension that is present. The registry of numeric CAtypes is modified so that the creators of extensions can advertise new namespaces and civic elements to encourage maximum reuse. The additions described in this document are backwardly compatible. Existing implementations may cause extension information to be lost, but the presence of extensions does not affect an implementation that conforms to either or . This document also normatively updates to clarify that the namespace must be included with the element name in the lists of valid, invalid, and not checked elements in the <locationValidation> part of a Location-to-Service Translation (LoST) response. While the LoST schema does not need to be changed, the example in the document is updated to show the namespaces in the lists.

One instance where translation might be necessary is where a device receives location configuration using DHCP. Conversion of DHCP information to an XML form is necessary if the device wishes to use the DHCP-provided information in a range of applications, including location-based presence services and emergency calling.

| |-------->| | Agent +--------+ +--------+ +-----------+ ]]> The device that performs the translation between the DHCP and XML formats might not be aware of some of the extensions that are in use. Without knowledge of these extensions and how they are represented in XML, the device is forced to discard them. These extensions could be useful, or may be critical, to the ultimate consumers of this information. For instance, an extension element might provide a presence watcher with important information in locating the device, or an extension might be significant in choosing a particular call route.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The civic schema in defines an ordered structure of elements that can be combined to describe a civic address. The XML extension point at the end of this sequence is used to extend the address. New elements are defined in a new XML namespace. This is true of address elements with significance within private or localized domains as well as those that are intended for global applicability. New elements SHOULD use the basic caType schema type defined in . This type provides an optional xml:lang attribute. For example, suppose the (fictitious) Central Devon Canals Authority wishes to introduce a new civic element called "bridge". The authority defines an XML namespace that includes a "bridge" element. The namespace needs to be a unique URI, for example http://devon.canals.example.com/civic. A civic address that includes the new "bridge" element is shown in .

UK Devon Monkokehampton Deckport Cross 21451338 ]]> An entity that receives this location information might not understand the extension address element. As long as the added element is able to be safely ignored, the remainder of the civic address can be used. The result is that the information is not as useful as it could be, but the added element does not prevent the use of the remainder of the address. The address can be passed to other applications, such as a LoST server, without modification. If the application understands the added element(s), it is able to make use of that information. For example, if this civic address is acquired using HTTP-Enabled Location Delivery (HELD), it can be included in a LoST request directly.

Unsupported civic address elements can be carried without consequence as long as the format of the address does not change. However, conversion between formats has been shown to be necessary. Format conversion requires knowledge of the format of the address elements. An entity performing a conversion between XML and DHCP address formats is forced to discard unrecognized elements. The entity performing the conversion has no way to know the correct element to use in the target format. This document defines a single extension element for the DHCP format that makes knowledge of extensions unnecessary during conversion. 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.

Extensions to the XML format are defined in a new XML namespace. The XML namespace received in DHCP is expressed as a URL, however, it should not be dereferenced or treated as a source location for the actual schema and doing so will serve no useful purpose. Extensions in the XML format can be added to a DHCP format civic address using an extension CAtype.

The extension CAtype (CAtype code 40) includes three values that uniquely identify the XML extension and its value: a namespace URI, the local name of the XML element, and the text content of that element. These three values are all included in the value of the CAtype, each separated by a single whitespace character.

CAtype (40) identifies the extension CAtype. Length is the number of octets used to represent the namespace URI, local name, and value. The length includes the space between the namespace URI and local name and the space between the local name and value fields. The content of a CAtype (after the CAtype code and length) is UTF-8 encoded Unicode text . A maximum of 255 octets is allowed. Octets consumed by the namespace URI and local name reduce the space available for values. This conversion only works for elements that have textual content and an optional xml:lang attribute. Elements with complex content or other attributes -- aside from namespace bindings -- MUST be ignored if they are not understood.

The registration of a new CAtype following the process in means that a recipient that does not know the equivalent XML is unable to produce a complete XML representation of the DHCP civic address. For this reason, this document ends the registration of new numeric CAtypes. No new registrations of numeric CAtypes can be made. In lieu of making new numerical CAtype assignments, this document creates a new extensionCA type that is defined in a manner that lets new civic elements be described in DHCP form by carrying the namespace and type name of the extension in parameters of the extensionCA type. When converting to XML, the namespace prefix used for the extension element is selected by the entity that performs the conversion.

The following example civic address contains two extensions: US CA 2471 AQ-374-4(c) LAX Tom Bradley G 36B ]]>

This is converted to a DHCP form as follows:

created the CAtype registry. Among other things, this registry advertised available civic elements. While it has always been possible to use an extension namespace to define civic elements that are not in the CAtype registry, and this document does not change that, the registry is valuable to alert implementors of commonly used civic elements and provides guidance to clients of what elements they should support. This document alters the CAtype registry in several ways. It closes the registry to new numeric CAtypes. It deletes the "NENA" column, which is not needed. It adds columns for a namespace and contact, and changes the name of the column currently called "PIDF" to "Local Name". It also adds a column to the registry called "Type". "Type" can have one of two values "A" and "B". Type A elements are intended for wide use with many applications and SHOULD be implemented by all 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 require an expert review.

We use this new extension method to define some additional civic address elements that are needed to correctly encode civic locations in several countries. The definition of these new civic address elements also serves as an example of how to define additional elements using the mechanisms described in this document.

In some areas, utility and lamp posts carry a unique identifier, which we call a pole number in this document. In some countries, the label on the lamp post also carries the local emergency service number, such as "110", encouraging callers to use the pole number to identify their location.

| Number | | | / |110| '---------' | | / |`-'| |_|/ | 2 | ,---------, | | | 1 | |Lamp Post| | | | 2 |----->| Number | |-| | 1 | '---------' | |\ | 0 | | | \ | 1 | | | \ | 4 | | | \|,,,| _ | | ``-..|.| ``--.._ `'--.._ ]]>

On some roads, trails, railroad rights of way, and other linear features, a post with a mile or kilometer distance from one end of the feature may be found (a "milepost"). There are other cases of poles or markers with numeric indications that are not the same as a "house number" or street address number.

The civic schema defined in allows the definition of address "123 Colorado Boulevard", but it does not allow for the easy expression of "123 Boulevard Colorado". Adding a street type prefix, allows a street named in this manner to be more easily represented.

The civic schema defined in provides a house number suffix element, allowing one to express an address like "123A Main Street", but it does not contain a corresponding house number prefix. The house number prefix element allows the expression of address such as "Z123 Main Street".

]]>

US CA Sacramento I5 248 22-109-689 ]]>

US CA Sacramento Colorado 223 Boulevard A ]]>

One critical use of civic location information is in next generation emergency services applications, in particular, call routing applications. In such cases, location information is provided to a location-based routing service using the LoST protocol . LoST is used to provide call routing information, but it is also used to validate location information to ensure that it can route to an emergency center when required. LoST is an XML-based protocol, and so the namespace extension mechanisms described in this document do not impact LoST. When LoST is used for validation, a <locationValidation> element is returned containing a list of valid, a list of invalid, and a list of unchecked civic elements. is an extract of the validation response in Figure 6 from .

country A1 A3 A6 PC HNO ]]> The RelaxNG schema in requires the elements in each of these lists to be namespace qualified, which makes the example in Figure 6 of erroneous. This issue is especially significant when local-civic extensions are used as the domain to which the extensions are attributed may impact their interpretation by the server or client. To ensure that local-civic extensions do not cause issues with the LoST server and client implementations, all elements listed in a <valid>, <invalid>, or <unchecked> element MUST be qualified with a namespace. To illustrate this, the extract above from Figure 6 in becomes .

ca:country ca:A1 ca:A3 ca:A6 ca:PC ca:HNO ]]> If a validation request has also included the extensions defined in , then the validation response would look like .

ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP ca:PC ca:HNO cae:MP cae:HNP ]]>

This document defines a formal way to extend the existing Geopriv civic address schema. While no security threats are directly introduced by this document, creators of new civic address extensions should refer to Sections 4.3.1 and 5.1 of to understand the environments in which these new elements will be used. New elements should only be registered if the person or organization performing the registration understands any associated risks. Security threats applicable to the civic address formats are described in DHCP and XML.

This document alters the "CAtypes" registry in the Civic Address Types Registry established by .

IANA has allocated a CAtype code of 40 for the extension CAtype. Registrations using this code will be made below, in .

IANA has made the following changes to the CAtype registry: No registrations of new CAtype numbers in the Civic Address Types Registry are permitted, except by IESG Approval under unusual circumstances. The following note has been placed in the header of the CAtypes registry, above the table: Note: As specified in RFC 6848, new registrations are only accepted for CAtype 40, using the template specified in . The registration procedures are changed: IETF Review (if Type=A), Expert Review (if Type=B). The designated expert is unchanged. The reference for the table is changed: , RFC 6848 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". All existing entries will have the following values for those new columns: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr The IESG (iesg@ietf.org); the GEOPRIV working group (geopriv@ietf.org) urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr A

New registrations in the Civic Address Types Registry require the following information: The assigned numeric CAtype. All new registrations will use the value 40. A unique identifier for the XML namespace used for the extension element. The local name of an XML element that carries the civic address element. A brief description of the semantics of the civic address element. One or more simple examples of the element. Contact details for the person providing the extension. A reference to a specification for the civic address element. A reference to a formal schema (XML schema, RelaxNG, or other form) that defines the extension. "A" or "B". If Type is "A", all clients SHOULD implement this element. If Type is "B", clients MAY implement this element.

This section registers the following four new CAtypes in the Civic Address Types Registry. Post Number (see ): 40 urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext PN Post number that is attributed to a lamp post or utility pole. The IESG (iesg@ietf.org); the GEOPRIV working group (geopriv@ietf.org) RFC 6848, urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext A Milepost (see ): 40 urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext MP Milepost: a marker indicating distance to or from a place (often a town). The IESG (iesg@ietf.org); the GEOPRIV working group (geopriv@ietf.org) RFC 6848, urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext A Street Type Prefix (see ): 40 urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext STP Street Type Prefix. The IESG (iesg@ietf.org); the GEOPRIV working group (geopriv@ietf.org) RFC 6848, urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext A House Number Prefix (see ): 40 urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext HNP House Number Prefix. The IESG (iesg@ietf.org); the GEOPRIV working group (geopriv@ietf.org) RFC 6848, urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext A

The "CAtypes" registry is altered to operate on a registration policy of "Expert Review", and optionally "Specification Required" if the element being registered has a Type value of "B". The registration rules for "Specification Required" are followed only if a registration includes a reference to a specification. Registrations can be made without a specification reference. If the element being registered has a Type value of "A", then the registration policy is "IETF Review" . All registrations are reviewed to identify potential duplication between registered elements. Duplicated semantics are not prohibited in the registry, though it is preferred if existing elements are used. The expert review is advised to recommend the use of existing elements following the guidance in . Any registration that is a duplicate or could be considered a close match for the semantics of an existing element SHOULD include a discussion of the reasons that the existing element was not reused. provides a comprehensive framework concerning the privacy of location information as pertaining to its use in Internet applications. The expert reviewer is asked to keep the spirit of this document in mind when reviewing new CAtype registrations.

IANA has registered a new XML namespace, as per the guidelines in . urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext IETF GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.Winterbottom@commscope.com)

GEOPRIV Civic Address Extensions

Additional Fields for GEOPRIV Civic Address

urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext

See RFC 6848.

END ]]>

This section registers an XML schema as per the procedures in . urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext IETF GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.Winterbottom@commscope.com) The XML for this schema can be found as the entirety of of this document.

Thanks to anyone who has tried to extend the civic schema and found it a little less than intuitive.