rfc-5139

Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)

M. Thomson, J. Winterbottom
date2008-02 streamIETF arearai wggeopriv statusPROPOSED STANDARD pages14 canonicalhttps://www.rfc-editor.org/rfc/rfc5139 doi10.17487/RFC5139
This document defines an XML format for the representation of civic location. This format is designed for use with Presence Information Data Format Location Object (PIDF-LO) documents and replaces the civic location format in RFC 4119. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for Dynamic Host Configuration Protocol (DHCP), and adds a hierarchy to address complex road identity schemes. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. [STANDARDS-TRACK]

updates

Extracted elements (19)

design-rationale §3.2.1

Street numbering (HNO element) applies to the most specific road element specified — the first from RDSUBBR, RDBR, RDSEC, or RD — because sections can have repeated street numbers, so the section must be identified to uniquely locate an address.

realtime

design-rationale §3.5

The 'script' field from RFC 4776 is omitted in favor of using the 'xml:lang' attribute with a script subtag (RFC 4646), consolidating language and script identification into the standard XML language attribute mechanism.

realtime

design-rationale §3.5

The 'xml:lang' attribute is allowed on all elements except 'country' and 'PLC', which contain language-neutral values: 'country' values are from ISO 3166-1, and 'PLC' values are from the IANA location types registry defined by RFC 4589.

realtime, registry

interoperability-note §3.5.1

The DHCP civic address format (RFC 4776) permits an element multiple times with different languages or scripts, but this XML form permits only a single instance of each element. Multiple 'civicAddress' elements are required if any element is duplicated with different languages when converting from DHCP format.

realtime

normative-requirement §3.2.2 MUST

If road branches or sub-branches require street suffixes or qualifiers, they MUST be included in the 'RDBR' or 'RDSUBBR' element text, since PRM, POM, PRD, POD, and STS always apply only to the 'RD' element.

realtime

normative-requirement §3.4 SHOULD

In the absence of a country-specific guide, the second part of the ISO 3166-2 code SHOULD be used for the 'A1' element (top-level country subdivision), omitting the leading country code and hyphen.

realtime

normative-requirement §3.5 RECOMMENDED

It is RECOMMENDED that each 'civicAddress' element use one language only, or a consistent combination of languages. Where a civic location is represented in multiple languages, multiple 'civicAddress' elements SHOULD be included in the PIDF-LO document.

realtime

normative-requirement §3.5 SHOULD

Multiple 'civicAddress' elements representing the same location in different languages SHOULD be inserted into the same PIDF-LO tuple.

realtime

normative-requirement §3.2 MAY

Road branches (RDBR) MAY also be used where a major thoroughfare is split into sections, in addition to cases where the branch name does not uniquely identify the road.

realtime

normative-requirement §3.2 MUST NOT

Where 'A6' was previously used for street names in RFC 4119, it MUST NOT be used; the 'RD' element MUST be used for thoroughfare data.

realtime

protocol-element §3.2

A hierarchical thoroughfare structure is introduced using RD (primary road), RDSEC (road section), RDBR (road branch), and RDSUBBR (road sub-branch) to handle complex road identity schemes where street names or numbers may repeat across sections or branches.

realtime

protocol-element §3.1

Fourteen new civic address type elements are added: BLD (CAtype 25), UNIT (26), ROOM (28), PLC (29), PCN (30), POBOX (31), ADDCODE (32), SEAT (33), RD (34), RDSEC (35), RDBR (36), RDSUBBR (37), PRM (38), and POM (39). These extend the civic address vocabulary from RFC 4119 to match the DHCP civic address types in RFC 4776.

realtime

protocol-element §4

The civicAddress XML element is defined in the namespace 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' and contains a sequence of optional civic address fields including country, A1-A6, thoroughfare elements (RD, RDSEC, RDBR, RDSUBBR), and building-level elements (BLD, UNIT, ROOM, SEAT). All fields except 'country' and 'PLC' support the xml:lang attribute.

realtime, sip

protocol-element §3.3

The 'country' element is restricted to exactly two uppercase characters corresponding to ISO 3166-1 alpha-2 codes, a tighter constraint than the original RFC 4119 definition. The XML schema enforces this via the pattern '[A-Z]{2}'.

realtime

protocol-element §3.6

The XML schema uses 'token' as the base type for civic address fields instead of 'string' (as used in RFC 4119). This causes XML processors to normalize and collapse whitespace before processing, making fragments with different whitespace formatting equivalent.

realtime

registry §7.1

RFC 5139 registers a new XML namespace URN 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' with IANA per RFC 3688 guidelines, for use with PIDF-LO civic location documents.

registry, realtime

registry §7.2

RFC 5139 registers an XML schema with IANA at URI 'urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr', the full schema being the content of Section 4.

registry, realtime

registry §7.3

RFC 5139 updates the civic address type (CAtype) registry established by RFC 4776, adding PIDF column entries for the 14 new types defined in Table 1 (BLD, UNIT, ROOM, PLC, PCN, POBOX, ADDCODE, SEAT, RD, RDSEC, RDBR, RDSUBBR, PRM, POM).

registry, realtime

security-consideration §6

The XML civic location representation is designed for inclusion in a PIDF-LO document and is subject to the same security considerations as described in RFC 4119. Considerations for inclusion in other XML documents are outside the scope of this document.

security, realtime