CurrentPROPOSED STANDARDIETF stream

RFC 6848: Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)

In plain English — editorial summary, not part of the RFC

New fields are occasionally added to civic addresses. A backward- compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Initial extensions for some new elements are also defined. The Location-to-Service Translation (LoST) protocol mechanism (defined in RFC 5222) that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process. [STANDARDS-TRACK]

Document record

Document ID
RFC6848
Published
January 2013
Authors
J. Winterbottom; M. Thomson; R. Barnes; B. Rosen; R. George
Status
PROPOSED STANDARD
Stream
IETF
Area
rai
Pages
21
Also known as

Topics

Related documents

Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.

Also filed under

About this page

The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.

Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.

Data sources · Editorial policy · Report a correction · What is an RFC?

canonical URL: /rfc/6848-specifying-civic-address-extensions-in-the-presence-information-data-format-loca