From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5139.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc5139.txt (limited to 'doc/rfc/rfc5139.txt') diff --git a/doc/rfc/rfc5139.txt b/doc/rfc/rfc5139.txt new file mode 100644 index 0000000..27cc6df --- /dev/null +++ b/doc/rfc/rfc5139.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group M. Thomson +Request for Comments: 5139 J. Winterbottom +Updates: 4119 Andrew +Category: Standards Track February 2008 + + + Revised Civic Location Format for + Presence Information Data Format Location Object (PIDF-LO) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + 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. + + + + + + + + + + + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 1] + +RFC 5139 Revised Civic LO February 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Additional Civic Address Types . . . . . . . . . . . . . . 3 + 3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 4 + 3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 5 + 3.2.2. Directionals and Other Qualifiers . . . . . . . . . . 5 + 3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 6 + 3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 6 + 3.5.1. Converting from the DHCP Format . . . . . . . . . . . 7 + 3.5.2. Combining Multiple Elements Based on Language + Preferences . . . . . . . . . . . . . . . . . . . . . 7 + 3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 8 + 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. URN sub-namespace registration for + 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 10 + 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11 + 7.3. CAtype Registry Update . . . . . . . . . . . . . . . . . . 11 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 + + + + + + + + + + + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 2] + +RFC 5139 Revised Civic LO February 2008 + + +1. Introduction + + Since the publication of the original PIDF-LO civic specification, in + [RFC4119], it has been found that the specification is lacking a + number of additional parameters that can be used to more precisely + specify a civic location. These additional parameters have been + largely captured in [RFC4776]. + + This document revises the GEOPRIV civic form to include the + additional civic parameters captured in [RFC4776]. The document also + introduces a hierarchical structure for thoroughfare (road) + identification, which is employed in some countries. New elements + are defined to allow for even more precision in specifying a civic + location. + +2. Terminology + + 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 [RFC2119]. + + The term "thoroughfare" is used in this document to describe a road + or part of a road or other access route along which a final point is + identified. This is consistent with the definition used in + [UPU-S42]. + +3. Changes from PIDF-LO + +3.1. Additional Civic Address Types + + [RFC4776] provides a full set of parameters that may be used to + describe a civic location. Specifically, [RFC4776] lists several + civic address types (CAtypes) that require support in the formal + PIDF-LO definition that are not in [RFC4119]. + + These changes include new elements that are required to support more + complex structures for naming street addresses. This is described in + more detail in Section 3.2. + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 3] + +RFC 5139 Revised Civic LO February 2008 + + + +-----------+--------+-------------------------------+--------------+ + | New Field | CAtype | Description | Example | + +-----------+--------+-------------------------------+--------------+ + | BLD | 25 | Building (structure) | Hope Theatre | + | | | | | + | UNIT | 26 | Unit (apartment, suite) | 12a | + | | | | | + | ROOM | 28 | Room | 450F | + | | | | | + | PLC | 29 | Place-type | office | + | | | | | + | PCN | 30 | Postal community name | Leonia | + | | | | | + | POBOX | 31 | Post office box (P.O. box) | U40 | + | | | | | + | ADDCODE | 32 | Additional Code | 13203000003 | + | | | | | + | SEAT | 33 | Seat (desk, cubicle, | WS 181 | + | | | workstation) | | + | | | | | + | RD | 34 | Primary road or street | Broadway | + | | | | | + | RDSEC | 35 | Road section | 14 | + | | | | | + | RDBR | 36 | Road branch | Lane 7 | + | | | | | + | RDSUBBR | 37 | Road sub-branch | Alley 8 | + | | | | | + | PRM | 38 | Road pre-modifier | Old | + | | | | | + | POM | 39 | Road post-modifier | Extended | + +-----------+--------+-------------------------------+--------------+ + + Table 1: New Civic PIDF-LO Types + + A complete description of these types is included in [RFC4776]. + +3.2. New Thoroughfare Elements + + In some countries, a thoroughfare can be broken up into sections, and + it is not uncommon for street numbers to be repeated between + sections. A road section identifier is required to ensure that an + address is unique. For example, "West Alice Parade" in the figure + below has 5 sections, each numbered from 1; unless the section is + specified, "7 West Alice Parade" could exist in 5 different places. + The "RDSEC" element is used to specify the section. + + + + + +Thomson & Winterbottom Standards Track [Page 4] + +RFC 5139 Revised Civic LO February 2008 + + + Minor streets can share the same name, so that they can only be + distinguished by the major thoroughfare with which they intersect. + For example, both "West Alice Parade, Section 3" and "Bob Street" + could both be intersected by a "Carol Lane". The "RDBR" element is + used to specify a road branch where the name of the branch does not + uniquely identify the road. Road branches MAY also be used where a + major thoroughfare is split into sections. + + Similar to the way that a road branch is associated with a road, a + road sub-branch is associated with a road branch. The "RDSUBBR" + element is used to identify road sub-branches. + + The "A6" element is retained for use in those countries that require + this level of detail. Where "A6" was previously used for street + names in [RFC4119], it MUST NOT be used; the "RD" element MUST be + used for thoroughfare data. + + The following figure shows a fictional arrangement of roads where + these new thoroughfare elements are applicable. + + | || + | ---------------|| + | Carol La. Carol La. || Bob + | || St. + | West Alice Pde. || + ==========/=================/===============/==========||=========== + Sec.1 Sec.2 Sec.3 | Sec.4 || Sec.5 + | || + ----------| Carol || + Alley 2 | La. || + | || + +3.2.1. Street Numbering + + The introduction of new thoroughfare elements affects the + interpretation of several aspects of more specific civic address + data. In particular, street numbering (the "HNO" element) applies to + the most specific road element specified, that is, the first + specified element from "RDSUBBR", "RDBR", "RDSEC", or "RD". + +3.2.2. Directionals and Other Qualifiers + + The "PRM", "POM", "PRD", "POD", and "STS" elements always apply to + the value of the "RD" element only. If road branches or sub-branches + require street suffixes or qualifiers, they MUST be included in the + "RDBR" or "RDSUBBR" element text. + + + + + +Thomson & Winterbottom Standards Track [Page 5] + +RFC 5139 Revised Civic LO February 2008 + + +3.3. Country Element + + The "country" element differs from that defined in [RFC4119] in that + it now restricts the value space of the element to two uppercase + characters, which correspond to the alpha-2 codes in [ISO.3166-1]. + +3.4. A1 Element + + The "A1" element is used for the top-level subdivision within a + country. In the absence of a country-specific guide on how to use + the A-series of elements, the second part of the ISO 3166-2 code + [ISO.3166-2] for a country subdivision SHOULD be used. The ISO + 3166-2 code is formed of a country code and hyphen plus a code of + one, two, or three characters or numerals. For the "A1" element, the + leading country code and hyphen are omitted and only the subdivision + code is included. + + For example, the codes for Canada include CA-BC, CA-ON, CA-QC; + Luxembourg has just three single-character codes, LU-D, LU-G, and + LU-L; Australia uses both two- and three-character codes, AU-ACT, + AU-NSW, AU-NT; and France uses numerical codes for mainland France + and letters for territories, FR-75, FR-NC. This results in the + following fragments: + + CAON + + LUL + + AUACT + + FR75 + +3.5. Languages and Scripts + + The XML schema defined for civic addresses allows for the addition of + the "xml:lang" attribute to all elements except "country" and "PLC", + which both contain language-neutral values. The range of allowed + values for "country" is defined in [ISO.3166-1]; the range of allowed + values for "PLC" is described in the IANA registry defined by + [RFC4589]. + + The "script" field defined in [RFC4776] is omitted in favor of using + the "xml:lang" attribute with a script subtag [RFC4646]. + + It is RECOMMENDED that each "civicAddress" element use one language + only, or a combination of languages that is consistent. Where a + civic location is represented in multiple languages, multiple + "civicAddress" elements SHOULD be included in the PIDF-LO document. + + + +Thomson & Winterbottom Standards Track [Page 6] + +RFC 5139 Revised Civic LO February 2008 + + + For civic addresses that form a complex to describe the same + location, these SHOULD be inserted into the same tuple. + +3.5.1. Converting from the DHCP Format + + The DHCP format for civic addresses [RFC4776] permits the inclusion + of an element multiple times with different languages or scripts. + However, this XML form only permits a single instance of each + element. Multiple "civicAddress" elements are required if any + element is duplicated with different languages. If the same language + and script are used for all elements, or no elements are duplicated, + the format can be converted into a single civic address. + + Where there are duplicated elements in different languages, a + "civicAddress" element is created for each language that is present. + All elements that are in that language are included. Elements that + are language independent, like the "country" and "PLC" elements, are + added to all "civicAddress" elements. + +3.5.2. Combining Multiple Elements Based on Language Preferences + + If the receiver of the XML representation is known, and that receiver + has indicated language preferences, a single XML format can be + constructed using those preferences. For example, language + preferences can be indicated by the "Accept-Language" header in the + SIP or HTTP protocols. + + All elements that have only one value, irrespective of language, are + used. Where multiple values exist, each value is assigned a + weighting based on the language preferences. The value with the + highest weighting is selected. An arbitrary value is selected if two + values have the same preference, if there is no preference for the + available languages, or if there are conflicting values with the same + language. + +3.6. Whitespace + + The XML schema [W3C.REC-xmlschema-2-20041028] defined in Section 4 + uses a base type of "token" instead of "string" as used in [RFC4119]. + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 7] + +RFC 5139 Revised Civic LO February 2008 + + + The "token" type ensures that whitespace within instance documents is + normalized and collapsed before being passed to a processor. This + ensures that the following fragments are considered equivalent by XML + processors: + + North Wollongong + + North + Wollongong + + + North Wollongong + + + Whitespace may still be included in values by using character + references, such as " ". + +4. Civic Address Schema + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 8] + +RFC 5139 Revised Civic LO February 2008 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 9] + +RFC 5139 Revised Civic LO February 2008 + + +5. Example + + + AU + NSW + Wollongong + North Wollongong + + FlindersStreet + Campbell Street + + Gilligan's Island + Corner + Video Rental Store + 2500 + Westerns and Classics + store + Private Box 15 + + +6. Security Considerations + + The XML representation described in this document is designed for + inclusion in a PIDF-LO document. As such, it is subject to the same + security considerations as are described in [RFC4119]. + Considerations relating to the inclusion of this representation in + other XML documents are outside the scope of this document. + +7. IANA Considerations + +7.1. URN sub-namespace registration for + 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' + + This document defines a new XML namespace (as per the guidelines in + [RFC3688]) that has been registered with IANA. + + URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr + + Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), + Martin Thomson (martin.thomson@andrew.com). + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 10] + +RFC 5139 Revised Civic LO February 2008 + + + XML: + + BEGIN + + + + + GEOPRIV Civic Address + + +

Format for Distributing Civic Address in GEOPRIV

+

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

+

See + RFC5139.

+ + + END + +7.2. XML Schema Registration + + This section registers an XML schema as per the procedures in + [RFC3688]. + + URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr + + Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), + Martin Thomson (martin.thomson@andrew.com). + + The XML for this schema can be found as the entirety of Section 4 + of this document. + +7.3. CAtype Registry Update + + This document updates the civic address type registry established by + [RFC4776]. The "PIDF" column of the CAtypes table has been updated + to include the types shown in the first column of Table 1. + + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 11] + +RFC 5139 Revised Civic LO February 2008 + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [W3C.REC-xmlschema-2-20041028] + Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes + Second Edition", World Wide Web Consortium + Recommendation REC-xmlschema-2-20041028, October 2004, + . + + [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object + Format", RFC 4119, December 2005. + + [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types + Registry", RFC 4589, July 2006. + + [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying + Languages", BCP 47, RFC 4646, September 2006. + + [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol + (DHCPv4 and DHCPv6) Option for Civic Addresses + Configuration Information", RFC 4776, November 2006. + + [ISO.3166-1] International Organization for Standardization, "Codes + for the representation of names of countries and their + subdivisions - Part 1: Country codes", ISO Standard + 3166- 1:1997, 1997. + + [ISO.3166-2] International Organization for Standardization, "Codes + for the representation of names of countries and their + subdivisions - Part 2: Country subdivision code", + ISO Standard 3166-2:1998, 1998. + +8.2. Informative References + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + [UPU-S42] Universal Postal Union (UPU), "International Postal + Address Components and Templates", UPS SB42-4, + July 2004. + + + + + + + +Thomson & Winterbottom Standards Track [Page 12] + +RFC 5139 Revised Civic LO February 2008 + + +Appendix A. Acknowledgements + + The authors would like to thank Henning Schulzrinne for his + assistance in defining the additional civic address types, + particularly his research into different addressing schemes that led + to the introduction of the thoroughfare elements. Rohan Mahy + suggested the ISO 3166-2 recommendation for A1. In addition, we + would like to thank Jon Peterson for his work in defining the + PIDF-LO. + +Authors' Addresses + + Martin Thomson + Andrew + PO Box U40 + Wollongong University Campus, NSW 2500 + AU + + Phone: +61 2 4221 2915 + EMail: martin.thomson@andrew.com + URI: http://www.andrew.com/ + + + James Winterbottom + Andrew + PO Box U40 + Wollongong University Campus, NSW 2500 + AU + + Phone: +61 2 4221 2938 + EMail: james.winterbottom@andrew.com + URI: http://www.andrew.com/ + + + + + + + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 13] + +RFC 5139 Revised Civic LO February 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 14] + -- cgit v1.2.3