RFC 6848

Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO), January 2013

File formats:
icon for text file icon for PDF icon for HTML
Status:
PROPOSED STANDARD
Updates:
RFC 4776, RFC 5222
Authors:
J. Winterbottom
M. Thomson
R. Barnes
B. Rosen
R. George
Stream:
IETF
Source:
geopriv (rai)

Cite this RFC: TXT  |  XML  |   BibTeX

DOI:  https://doi.org/10.17487/RFC6848

Discuss this RFC: Send questions or comments to the mailing list geopriv@ietf.org

Other actions: Submit Errata  |  Find IPR Disclosures from the IETF  |  View History of RFC 6848


Abstract

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]


For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 8729.




Advanced Search