doc: Add RFC documents

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]
+