Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)
updates
Extracted elements (22)
Extensions are always defined first in XML, not DHCP, because the XML format has a well-defined extension point (via XML namespaces) while DHCP does not. DHCP carriage is achieved by encoding the XML namespace URI, local name, and value into the single extension CAtype 40, avoiding the need for translating entities to understand each extension individually.
New civic address extensions MUST be defined only in the XML format; the DHCP format is not extended further because DHCP extensions cannot be safely conveyed in environments where format conversion is possible. This ensures lossless round-trip conversion between XML and DHCP representations.
The RelaxNG schema in RFC 5222 requires namespace-qualified element names in <locationValidation> lists, making the example in Figure 6 of RFC 5222 erroneous. RFC 6848 provides the corrected example with proper namespace prefixes on all civic element names.
The XML namespace URI used for extensions is expressed as a URL in DHCP but MUST NOT be dereferenced or treated as a schema source location; it serves only as a unique identifier. Existing implementations conforming to RFC 4776 or RFC 5139 may discard extension elements but are not broken by their presence.
All elements listed in a LoST <valid>, <invalid>, or <unchecked> element MUST be qualified with a namespace. The example in RFC 5222 Section 6 is erroneous because it omits namespace qualification; this document normatively corrects that.
Any CAtype registration that duplicates or closely matches the semantics of an existing element SHOULD include a discussion of why the existing element was not reused, per expert reviewer guidance.
Elements with complex content or attributes other than namespace bindings and 'xml:lang' MUST be ignored if they are not understood during XML-to-DHCP conversion. Only elements with textual content and an optional xml:lang attribute can be carried in CAtype 40.
New civic address elements SHOULD use the basic 'caType' schema type defined in RFC 5139, which provides an optional 'xml:lang' attribute.
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 CAtype (CAtype 40). Further extensions to the DHCP format are prohibited.
No new registrations of numeric CAtype numbers are permitted in the Civic Address Types Registry, except by IESG Approval under unusual circumstances. All new civic elements use CAtype 40 with a namespace URI and local name.
Type A civic elements SHOULD be implemented by all clients unless the client is certain the element will not be encountered. Type A elements require IETF Review; Type B elements only require Expert Review and MAY be implemented.
The extension CAtype (CAtype code 40) carries three whitespace-separated values: a namespace URI, the local name of the XML element, and the text content of that element. This allows unsupported XML civic address extensions to be conveyed in DHCP without requiring the translating entity to understand the extension.
The House Number Prefix (HNP) extension element complements the existing house number suffix, allowing expression of addresses like 'Z123 Main Street' where an alphanumeric prefix precedes the house number.
The Milepost (MP) extension element indicates distance to or from a place along a road, trail, railroad, or other linear feature, for cases where a pole or marker with a numeric indication is not a house number.
The Pole Number (PN) extension element identifies a lamp post or utility pole by its unique identifier. In some countries, the pole number is used by emergency callers to report their location.
The Street Type Prefix (STP) extension element allows expression of addresses where the street type precedes the street name (e.g., 'Boulevard Colorado'), which the RFC 5139 schema could not easily represent.
A new URN sub-namespace is registered: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext, for the civic address extension elements defined in this document.
A new XML schema is registered at urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext, defining the PN, MP, STP, and HNP extension elements using the caType base type from RFC 5139.
Four new CAtypes are registered under CAtype 40 in the Civic Address Types Registry: Post Number (PN), Milepost (MP), Street Type Prefix (STP), and House Number Prefix (HNP), all in namespace urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext, all Type A.
The CAtype registry (originally created by RFC 4776) is modified: it is closed to new numeric CAtypes, the NENA column is removed, columns for Namespace URI, Contact, Schema, and Type (A or B) are added, and the PIDF column is renamed to Local Name. All new civic address element registrations use CAtype 40.
This document introduces no new security threats directly, but creators of civic address extensions should consult RFC 3694 Sections 4.3.1 and 5.1 to understand threat environments. Security threats applicable to civic address formats are described in RFC 4776 (DHCP) and RFC 5139 (XML).
CAtype 40 encodes: 1-octet CAtype code (40), 1-octet Length, followed by UTF-8 encoded content consisting of Namespace URI, a space (U+0020), XML element local name, a space (U+0020), and extension value. Maximum total content is 255 octets.