summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5139.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5139.txt')
-rw-r--r--doc/rfc/rfc5139.txt787
1 files changed, 787 insertions, 0 deletions
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:
+
+ <country>CA</country><A1>ON</A1>
+
+ <country>LU</country><A1>L</A1>
+
+ <country>AU</country><A1>ACT</A1>
+
+ <country>FR</country><A1>75</A1>
+
+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:
+
+ <A4>North Wollongong</A4>
+
+ <A1>North
+ Wollongong</A1>
+
+ <A1>
+ North Wollongong
+ </A1>
+
+ Whitespace may still be included in values by using character
+ references, such as "&#x20;".
+
+4. Civic Address Schema
+
+ <?xml version="1.0"?>
+ <xs:schema
+ targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
+ xmlns:xs="http://www.w3.org/2001/XMLSchema"
+ xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
+ xmlns:xml="http://www.w3.org/XML/1998/namespace"
+ elementFormDefault="qualified" attributeFormDefault="unqualified">
+
+ <xs:import namespace="http://www.w3.org/XML/1998/namespace"
+ schemaLocation="http://www.w3.org/2001/xml.xsd"/>
+
+ <xs:simpleType name="iso3166a2">
+ <xs:restriction base="xs:token">
+ <xs:pattern value="[A-Z]{2}"/>
+ </xs:restriction>
+ </xs:simpleType>
+
+ <xs:complexType name="caType">
+ <xs:simpleContent>
+ <xs:extension base="xs:token">
+ <xs:attribute ref="xml:lang" use="optional"/>
+ </xs:extension>
+ </xs:simpleContent>
+ </xs:complexType>
+
+
+
+
+
+
+
+
+Thomson & Winterbottom Standards Track [Page 8]
+
+RFC 5139 Revised Civic LO February 2008
+
+
+ <xs:element name="civicAddress" type="ca:civicAddress"/>
+ <xs:complexType name="civicAddress">
+ <xs:sequence>
+ <xs:element name="country" type="ca:iso3166a2" minOccurs="0"/>
+ <xs:element name="A1" type="ca:caType" minOccurs="0"/>
+ <xs:element name="A2" type="ca:caType" minOccurs="0"/>
+ <xs:element name="A3" type="ca:caType" minOccurs="0"/>
+ <xs:element name="A4" type="ca:caType" minOccurs="0"/>
+ <xs:element name="A5" type="ca:caType" minOccurs="0"/>
+ <xs:element name="A6" type="ca:caType" minOccurs="0"/>
+ <xs:element name="PRM" type="ca:caType" minOccurs="0"/>
+ <xs:element name="PRD" type="ca:caType" minOccurs="0"/>
+ <xs:element name="RD" type="ca:caType" minOccurs="0"/>
+ <xs:element name="STS" type="ca:caType" minOccurs="0"/>
+ <xs:element name="POD" type="ca:caType" minOccurs="0"/>
+ <xs:element name="POM" type="ca:caType" minOccurs="0"/>
+ <xs:element name="RDSEC" type="ca:caType" minOccurs="0"/>
+ <xs:element name="RDBR" type="ca:caType" minOccurs="0"/>
+ <xs:element name="RDSUBBR" type="ca:caType" minOccurs="0"/>
+ <xs:element name="HNO" type="ca:caType" minOccurs="0"/>
+ <xs:element name="HNS" type="ca:caType" minOccurs="0"/>
+ <xs:element name="LMK" type="ca:caType" minOccurs="0"/>
+ <xs:element name="LOC" type="ca:caType" minOccurs="0"/>
+ <xs:element name="FLR" type="ca:caType" minOccurs="0"/>
+ <xs:element name="NAM" type="ca:caType" minOccurs="0"/>
+ <xs:element name="PC" type="ca:caType" minOccurs="0"/>
+ <xs:element name="BLD" type="ca:caType" minOccurs="0"/>
+ <xs:element name="UNIT" type="ca:caType" minOccurs="0"/>
+ <xs:element name="ROOM" type="ca:caType" minOccurs="0"/>
+ <xs:element name="SEAT" type="ca:caType" minOccurs="0"/>
+ <xs:element name="PLC" type="xs:token" minOccurs="0"/>
+ <xs:element name="PCN" type="ca:caType" minOccurs="0"/>
+ <xs:element name="POBOX" type="ca:caType" minOccurs="0"/>
+ <xs:element name="ADDCODE" type="ca:caType" minOccurs="0"/>
+ <xs:any namespace="##other" processContents="lax"
+ minOccurs="0" maxOccurs="unbounded"/>
+ </xs:sequence>
+ <xs:anyAttribute namespace="##any" processContents="lax"/>
+ </xs:complexType>
+ </xs:schema>
+
+
+
+
+
+
+
+
+
+
+
+Thomson & Winterbottom Standards Track [Page 9]
+
+RFC 5139 Revised Civic LO February 2008
+
+
+5. Example
+
+ <civicAddress xml:lang="en-AU"
+ xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
+ <country>AU</country>
+ <A1>NSW</A1>
+ <A3> Wollongong
+ </A3><A4>North Wollongong
+ </A4>
+ <RD>Flinders</RD><STS>Street</STS>
+ <RDBR>Campbell Street</RDBR>
+ <LMK>
+ Gilligan's Island
+ </LMK> <LOC>Corner</LOC>
+ <NAM> Video Rental Store </NAM>
+ <PC>2500</PC>
+ <ROOM> Westerns and Classics </ROOM>
+ <PLC>store</PLC>
+ <POBOX>Private Box 15</POBOX>
+ </civicAddress>
+
+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
+ <?xml version="1.0"?>
+ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+ <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+ <head>
+ <title>GEOPRIV Civic Address</title>
+ </head>
+ <body>
+ <h1>Format for Distributing Civic Address in GEOPRIV</h1>
+ <h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr</h2>
+ <p>See <a href="http://www.rfc-editor.org/rfc/rfc5139.txt">
+ RFC5139</a>.</p>
+ </body>
+ </html>
+ 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,
+ <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
+
+ [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]
+