doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc4776.txt b/doc/rfc/rfc4776.txt
new file mode 100644
index 0000000..34d52a5
--- /dev/null
+++ b/doc/rfc/rfc4776.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                     H. Schulzrinne
+Request for Comments: 4776                                   Columbia U.
+Obsoletes: 4676                                            November 2006
+Category: Standards Track
+
+
+    Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option
+             for Civic Addresses Configuration Information
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2006).
+
+RFC Editor Note
+
+   RFC 4776 is being published to correct an error in the assignment of
+   the numeric value of the DHCPv6 option-code in RFC 4676 (Section
+   3.2).  This document obsoletes RFC 4676.
+
+Abstract
+
+   This document specifies a Dynamic Host Configuration Protocol (DHCPv4
+   and DHCPv6) option containing the civic location of the client or the
+   DHCP server.  The Location Configuration Information (LCI) includes
+   information about the country, administrative units such as states,
+   provinces, and cities, as well as street addresses, postal community
+   names, and building information.  The option allows multiple
+   renditions of the same address in different scripts and languages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                     [Page 1]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................5
+   3. Format of the DHCP Civic Location Option ........................5
+      3.1. Overall Format for DHCPv4 ..................................5
+      3.2. Overall Format for DHCPv6 ..................................6
+      3.3. Element Format .............................................7
+      3.4. Civic Address Components ...................................7
+   4. Postal Addresses ...............................................13
+   5. Example ........................................................14
+   6. Security Considerations ........................................15
+   7. IANA Considerations ............................................15
+   8. References .....................................................16
+      8.1. Normative References ......................................16
+      8.2. Informative References ....................................17
+   Acknowledgements ..................................................17
+
+1.  Introduction
+
+   Many end system services can benefit by knowing the approximate
+   location of the end device.  In particular, IP telephony devices need
+   to know their location to contact the appropriate emergency response
+   agency and to be found by emergency responders.
+
+   There are two common ways to identify the location of an object,
+   either through geospatial coordinates or by so-called civic
+   addresses.  Geospatial coordinates indicate longitude, latitude, and
+   altitude, while civic addresses indicate a street address.
+
+   The civic address is commonly, but not necessarily, closely related
+   to the postal address, used by the local postal service to deliver
+   mail.  However, not all postal addresses correspond to street
+   addresses.  For example, the author's address is a postal address
+   that does not appear on any street or building sign.  Naturally, post
+   office boxes would be unsuitable for the purposes described here.
+   The term 'civil address' or 'jurisdictional address' is also
+   sometimes used instead of civic address.  This document mainly
+   supports civic addresses, but allows the postal community name to be
+   indicated if it differs from the civic name.
+
+   A related document [15] describes a DHCPv4 [2] option for conveying
+   geospatial information to a device.  This document describes how
+   DHCPv4 and DHCPv6 [6] can be used to convey the civic and postal
+   address to devices.  Both geospatial and civic formats can be used
+   simultaneously, increasing the chance to deliver accurate and timely
+
+
+
+
+
+Schulzrinne                 Standards Track                     [Page 2]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+   location information to emergency responders.  The reader should also
+   be familiar with the concepts in [11], as many of the protocol
+   elements below are designed to dovetail with PIDF-LO elements.
+
+   This document only defines the delivery of location information from
+   the DHCP server to the client, due to security concerns related to
+   using DHCP to update the database.  Within the GEOPRIV architecture
+   as defined by RFC 3693 [9], the defined mechanism in this document
+   for conveying initial location information is known as a "sighting"
+   function.  Sighting functions are not required to have security
+   capabilities and are only intended to be configured in trusted and
+   controlled environments.  (A classic example of the sighting function
+   is a Global Positioning System wired directly to a network node.)
+   Further discussion of the protections that must be provided according
+   to RFC 3694 [10] are in the Security Considerations (Section 6).
+
+   End systems that obtain location information via the mechanism
+   described here then use other protocol mechanisms to communicate this
+   information to an emergency call center or to convey it as part of
+   presence information.
+
+   Civic information is useful since it often provides additional,
+   human-usable information, particularly within buildings.  Also,
+   compared to geospatial information, it is readily obtained for most
+   occupied structures and can often be interpreted even if incomplete.
+   For example, for many large university or corporate campuses,
+   geocoding information to building and room granularity may not be
+   readily available.
+
+   Unlike geospatial information, the format for civic and postal
+   information differs from country to country.  The initial set of data
+   fields is derived from standards published by the United States
+   National Emergency Number Association (NENA) [18] and takes into
+   account addressing conventions for a number of countries in different
+   areas of the world.  It is anticipated that other countries can reuse
+   many of the data elements, but the document also establishes an IANA
+   registry for defining additional civic location data fields.
+
+   The same civic and postal address information can often be rendered
+   in multiple languages and scripts.  For example, Korean addresses are
+   often shown in Hangul, Latin, and Kanji, while some older cities have
+   multiple language variants (e.g., Munich, Muenchen, and Monaco).
+   Since DHCPv4 and DHCPv6 do not currently support a mechanism to query
+   for a specific script or language, the DHCP server SHOULD provide all
+   common renderings to the client and MUST provide at least the
+   rendering in the language and script appropriate to the location
+   indicated.  For example, for use in presence information, the target
+   may be visiting from a foreign country and want to convey the
+
+
+
+Schulzrinne                 Standards Track                     [Page 3]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+   information in a format suitable for watchers in its home country.
+   For emergency services, the rendering in the local language is likely
+   to be most appropriate.  To provide multiple renderings, the server
+   repeats sequences of address elements, prefixing each with a
+   'language' and/or 'script' element (see Section 3.3).  The language
+   and script remain in effect for subsequent elements until overridden
+   by another language or script element.  Since the DHCP client is
+   unlikely to be the final consumer of the location information, the
+   DHCP server has to provide all appropriate language and script
+   versions, which the client then passes on via some other GEOPRIV
+   using protocol, typically encoded in a presence-based GEOPRIV
+   location object format [16].
+
+   The DHCP server MAY provide location information for multiple
+   locations related to the target, for example, both the network
+   element and the network jack itself.  This is likely to help in
+   debugging network problems, for example.
+
+   This document calls for various operational decisions.  For example,
+   an administrator has to decide when to provide the location of the
+   DHCP server or other network elements even if these may be a good
+   distance away from the client.  The administrator must also consider
+   whether to include both civic and geospatial information if these may
+   differ.  The document does not specify the criteria to be used in
+   making these choices, as these choices are likely to depend strongly
+   on local circumstances and need to be based on local, human
+   knowledge.
+
+   A system that works with location information configured by DHCP is
+   dependent that the administrators of the DHCP systems are careful
+   enough on a number of fronts, such as:
+
+   -  if information about one location is provided in multiple forms
+      (e.g., in multiple languages), is it consistent?
+
+   -  is the administrator certain that location information is
+      configured only to systems to which it applies (e.g., not to
+      systems topologically near, but geographically far)?
+
+   -  if the location configured is not that of the target but that of a
+      'nearby' network node or the DHCP server, despite the
+      recommendation against this practice in Section 3.1, is the
+      administrator certain that this configuration is geographically
+      valid?
+
+   There are many other considerations in ensuring that location
+   information is handled safely and promptly for an emergency service
+   in particular.  Those are in the province of the applications which
+
+
+
+Schulzrinne                 Standards Track                     [Page 4]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+   make use of the configured location information, and they are beyond
+   the scope of this document.  DHCP configuration SHOULD NOT be used
+   for emergency services without guidelines on these considerations.
+   Work on these is under way in the IETF ECRIT working group at the
+   time of publication of this document.
+
+   In addition, if a network provides civic location information via
+   both DHCPv4 and DHCPv6, the information conveyed by the two protocols
+   MUST be the same.
+
+   As discussed in the Security Considerations (Section 6), the
+   GEOCONF_CIVIC option SHOULD be returned by DHCPv4 servers only when
+   the DHCPv4 client has included this option in its 'parameter request
+   list' (RFC 2131 [2], Section 3.5).  Similarly, the
+   OPTION_GEOCONF_CIVIC option SHOULD be returned by DHCPv6 servers only
+   when the DHCPv6 client has included this option in its OPTION_ORO.
+
+   The DHCPv4 long-options mechanism described in RFC 3396 [8] MUST be
+   used if the civic address option exceeds the maximum DHCPv4 option
+   size of 255 octets.
+
+2.  Terminology
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
+   indicate requirement levels for compliant implementations.
+
+3.  Format of the DHCP Civic Location Option
+
+3.1.  Overall Format for DHCPv4
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | GEOCONF_CIVIC |       N       |      what     |    country    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    code       |        civic address elements                ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Code GEOCONF_CIVIC:  The code for this DHCP option is 99.
+
+   N:  The length of this option is variable.  The minimum length is 3
+      octets.
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                     [Page 5]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+   what:  The 'what' element describes to which location the DHCP entry
+      refers.  Currently, three options are defined: the location of the
+      DHCP server (a value of 0), the location of the network element
+      believed to be closest to the client (a value of 1), or the
+      location of the client (a value of 2).  Option (2) SHOULD be used,
+      but may not be known.  Options (0) and (1) SHOULD NOT be used
+      unless it is known that the DHCP client is in close physical
+      proximity to the server or network element.
+
+   country code:  The two-letter ISO 3166 country code in capital ASCII
+      letters, e.g., DE or US.  (Civic addresses always contain country
+      designations, suggesting the use of a fixed-format field to save
+      space.)
+
+   civic address elements:  Zero or more elements comprising the civic
+      and/or postal address, with the format described below
+      (Section 3.3).
+
+3.2.  Overall Format for DHCPv6
+
+   The DHCPv6 [6] civic address option refers generally to the client as
+   a whole.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      OPTION_GEOCONF_CIVIC     |           option-len          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      what     |        country code           |               .
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               .
+   .                     civic address elements                    .
+   .                              ...                              .
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   option-code:  OPTION_GEOCONF_CIVIC (36)
+
+   option-len:  Length of the Countrycode, 'what' and civic address
+      elements in octets.
+
+   what:  See above (Section 3.1).
+
+   country code:  See above (Section 3.1).
+
+   civic address elements:  See above (Section 3.1).
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                     [Page 6]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+3.3.  Element Format
+
+   For both DHCPv4 and DHCPv6, each civic address element has the
+   following format:
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   CAtype      |   CAlength    |      CAvalue                 ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   CAtype:  A one-octet descriptor of the data civic address value.
+
+   CAlength:  The length, in octets, of the CAvalue, not including the
+      CAlength field itself.
+
+   CAvalue:  The civic address value, as described in detail below.
+
+3.4.  Civic Address Components
+
+   Since each country has different administrative hierarchies, with
+   often the same (English) names, this specification adopts a simple
+   hierarchical notation that is then instantiated for each country.  We
+   assume that five levels are sufficient for sub-national divisions
+   above the street level.
+
+   All elements are OPTIONAL and can appear in any order.
+
+   Component values MUST be encoded as UTF-8 [7].  They SHOULD be
+   written in mixed case, following the customary spelling.  The script
+   indication (CAtype 128) MUST be written in mixed case, with the first
+   letter a capital letter.
+
+   Abbreviations MUST NOT be used unless indicated for each element.
+   Abbreviations do not need a trailing period.
+
+   It is RECOMMENDED that all elements in a particular script (CAtype
+   128) and language (CAtype 0) be grouped together, as that reduces the
+   number of script and language identifiers needed.
+
+   For each script and language, elements SHOULD be included in numeric
+   order from lowest to highest of their CAtype.  In general, an element
+   is labeled in its language and script by the most recent 'language
+   tag' (CAtype ) element preceding it.  Since not all elements depend
+   on the script and language, a client accumulates the elements by
+   CAtype and then selects the most desirable language and script
+   rendition if there are multiple elements for the same CAtype.
+
+
+
+
+Schulzrinne                 Standards Track                     [Page 7]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+   +--------+-------+--------------------------------------------------+
+   | CAtype | label | description                                      |
+   +--------+-------+--------------------------------------------------+
+   | 1      | A1    | national subdivisions (state, canton, region,    |
+   |        |       | province, prefecture)                            |
+   |        |       |                                                  |
+   | 2      | A2    | county, parish, gun (JP), district (IN)          |
+   |        |       |                                                  |
+   | 3      | A3    | city, township, shi (JP)                         |
+   |        |       |                                                  |
+   | 4      | A4    | city division, borough, city district, ward,     |
+   |        |       | chou (JP)                                        |
+   |        |       |                                                  |
+   | 5      | A5    | neighborhood, block                              |
+   |        |       |                                                  |
+   | 6      | A6    | group of streets below the neighborhood level    |
+   +--------+-------+--------------------------------------------------+
+                                  Table 1
+
+   For specific countries, the administrative sub-divisions are
+   described below.
+
+   CA (Canada):  The mapping to NENA designations is shown in
+      parentheses.  A1 designates the province (STA), A2 the county
+      (CNA), A3 the city, town, or MSAG community name (MCN).
+
+   DE (Germany):  A1 represents the state (Bundesstaat), A2 the county
+      (Regierungsbezirk), A3 the city (Stadt, Gemeinde), A4 the district
+      (Bezirk).  Street suffixes (STS) are used only for designations
+      that are a separate word (e.g., Marienthaler Strasse).
+
+   JP (Japan):  A1 represents the metropolis (To, Fu) or prefecture
+      (Ken, Do), A2 the city (Shi) or rural area (Gun), A3 the ward (Ku)
+      or village (Mura), A4 the town (Chou or Machi), A5 the city
+      district (Choume), and A6 the block (Banchi or Ban).
+
+   KR (Korea):  A1 represents the province (Do), A2 the county (gun), A3
+      the city or village (ri), A4 the urban district (gu), A5 the
+      neighborhood (dong).
+
+   US (United States):  The mapping to NENA designations is shown in
+      parentheses.  A1 designates the state (STA), using the two-letter
+      state and possession abbreviations recommended by the United
+      States Postal Service Publication 28 [17], Appendix B.  A2
+      designates the county, parish (Louisiana), or borough (Alaska)
+      (CNA).  A3 designates the civic community name, e.g., city or
+      town.  It is also known as the municipal jurisdiction or MSAG
+      community name (MCN).  The civic community name (A3) reflects the
+
+
+
+Schulzrinne                 Standards Track                     [Page 8]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+      political boundaries.  These boundaries may differ from postal
+      delivery assignments, the postal community name (PCN), for
+      historical or practical reasons.  The optional element A4 contains
+      the community place name, such as "New Hope Community" or
+      "Urbanizacion" in Puerto Rico.
+
+   Mappings and considerations from additional countries may be
+   informally gathered from time to time in independent documents
+   published by the IETF.  These should be titled "Civic Address
+   Considerations for [Country]" and should contain similar information
+   to the examples given here.  As published by the IETF, they will be
+   non-normative and purely descriptive, like the examples here, and
+   will not purport to speak with authority for any country, but rather
+   be offered for information.  If authors choose to label the document
+   with a country code, this does not preclude its use for labeling a
+   future coexisting document.
+
+   Additional CA types appear in many countries and are simply omitted
+   where they are not needed or known:
+
+   +--------+------+------+---------------------------+----------------+
+   | CAtype | NENA | PIDF | Description               | Examples       |
+   +--------+------+------+---------------------------+----------------+
+   | 0      |      |      | language                  | i-default [3]  |
+   |        |      |      |                           |                |
+   | 16     | PRD  | PRD  | leading street direction  | N              |
+   |        |      |      |                           |                |
+   | 17     | POD  | POD  | trailing street suffix    | SW             |
+   |        |      |      |                           |                |
+   | 18     | STS  | STS  | street suffix or type     | Ave, Platz     |
+   |        |      |      |                           |                |
+   | 19     | HNO  | HNO  | house number              | 123            |
+   |        |      |      |                           |                |
+   | 20     | HNS  | HNS  | house number suffix       | A, 1/2         |
+   |        |      |      |                           |                |
+   | 21     | LMK  | LMK  | landmark or vanity        | Columbia       |
+   |        |      |      | address                   | University     |
+   |        |      |      |                           |                |
+   | 22     | LOC  | LOC  | additional location       | South Wing     |
+   |        |      |      | information               |                |
+   |        |      |      |                           |                |
+   | 23     | NAM  | NAM  | name (residence and       | Joe's          |
+   |        |      |      | office occupant)          | Barbershop     |
+   | 24     | ZIP  | PC   | postal/zip code           | 10027-1234     |
+   |        |      |      |                           |                |
+   | 25     |      |      | building (structure)      | Low Library    |
+   |        |      |      |                           |                |
+   +--------+------+------+---------------------------+----------------+
+
+
+
+Schulzrinne                 Standards Track                     [Page 9]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+   +--------+------+------+---------------------------+----------------+
+   | CAtype | NENA | PIDF | Description               | Examples       |
+   +--------+------+------+---------------------------+----------------+
+   | 26     |      |      | unit (apartment, suite)   | Apt 42         |
+   |        |      |      |                           |                |
+   | 27     |      | FLR  | floor                     | 4              |
+   |        |      |      |                           |                |
+   | 28     |      |      | room                      | 450F           |
+   |        |      |      |                           |                |
+   | 29     |      |      | type of place             | office         |
+   |        |      |      |                           |                |
+   | 30     | PCN  |      | postal community name     | Leonia         |
+   |        |      |      |                           |                |
+   | 31     |      |      | post office box (P.O.     | 12345          |
+   |        |      |      | Box)                      |                |
+   |        |      |      |                           |                |
+   | 32     |      |      | additional code           | 13203000003    |
+   |        |      |      |                           |                |
+   | 33     |      | SEAT | seat (desk, cubicle,      | WS 181         |
+   |        |      |      | workstation)              |                |
+   |        |      |      |                           |                |
+   | 34     |      |      | primary road name         | Broadway       |
+   |        |      |      |                           |                |
+   | 35     |      |      | road section              | 14             |
+   |        |      |      |                           |                |
+   | 36     |      |      | branch road name          | Lane 7         |
+   |        |      |      |                           |                |
+   | 37     |      |      | sub-branch road name      | Alley 8        |
+   |        |      |      |                           |                |
+   | 38     |      |      | street name pre-modifier  | Old            |
+   |        |      |      |                           |                |
+   | 39     |      |      | street name post-modifier | Service        |
+   |        |      |      |                           |                |
+   | 128    |      |      | script                    | Latn           |
+   |        |      |      |                           |                |
+   | 255    |      |      | reserved                  |                |
+   +--------+------+------+---------------------------+----------------+
+
+   The CA types labeled in the second column correspond to items from
+   the NENA "Recommended Formats and Protocols For ALI Data Exchange,
+   ALI Response and GIS Mapping" [18], but are applicable to most
+   countries.  The "NENA" column refers to the data dictionary name in
+   Exhibit 18 of [18].
+
+   The column labeled PIDF indicates the element name from [16].  (Some
+   elements were added to this document after the PIDF location object
+   definition had been completed.  These elements currently do not have
+   a PIDF-LO equivalent.)
+
+
+
+Schulzrinne                 Standards Track                    [Page 10]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+   Language:  The "language" item (CAtype 0) optionally identifies the
+      language used for presenting the address information, drawing from
+      the tags for identifying languages in [4], as discussed in [13].
+      If omitted, the default value for this tag is "i-default" [3].
+
+   Script:  The "script" item (CAtype 128) optionally identifies the
+      script used for presenting the address information, drawing from
+      the tags for identifying scripts described in [12] and elaborated
+      on in Section 2.2.3 of [13].  If omitted, the default value for
+      this tag is "Latn".
+
+   POD, PRD:  The abbreviations N, E, S, W, and NE, NW, SE, SW SHOULD be
+      used for POD (trailing street suffix) and PRD (leading street
+      direction) in English-speaking countries.
+
+   STS:  STS designates a street suffix or type.  In the United States
+      (US), the abbreviations recommended by the United States Postal
+      Service Publication 28 [17], Appendix C, SHOULD be used.
+
+   HNS:  HNS ("house number suffix") is a modifier to a street address;
+      it does not identify parts of a street address.
+
+   building:  While a landmark (LMK, CAtype 21) can indicate a complex
+      of buildings, 'building' (CAtype 25) conveys the name of a single
+      building if the street address includes more than one building or
+      if the building name is helpful in identifying the location.
+
+   LOC:  LOC ("location", CAtype 22) is an unstructured string
+      specifying additional information about the location, such as the
+      part of a building or other unstructured information.
+
+   PCN:  The postal community name (CAtype 30) and the post office box
+      (CAtype 31) allow the recipient to construct a postal address.
+      The post office box field should contain the words "P.O. Box" or
+      other locally appropriate postal designation.
+
+   NAM:  The NAM object is used to aid user location ("Joe Miller",
+      "Alice's Dry Cleaning").  It does not identify the person using a
+      communications device, but rather the person or organization
+      associated with the address.
+
+   LMK:  While a landmark (LMK, CAtype 21) can indicate a complex of
+      buildings, 'building' (CAtype 25) conveys the name of a single
+      building if the street address includes more than one building or
+      the building name is helpful in identifying the location.  (For
+      example, on university campuses, the house number is often not
+      displayed on buildings, whereas the building name is prominently
+      shown.)
+
+
+
+Schulzrinne                 Standards Track                    [Page 11]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+   Unit:  The "unit" object (CAtype 26) contains the name or number of a
+      part of a structure where there are separate administrative units,
+      owners, or tenants, such as separate companies or families that
+      occupy that structure.  Common examples include suite or apartment
+      designations.
+
+   Room:  A "room" (CAtype 28) is the smallest identifiable subdivision
+      of a structure.
+
+   Type of place:  The "type of place" item (CAtype 29) describes the
+      type of place described by the civic coordinates.  For example, it
+      describes whether it is a home, office, street, or other public
+      space.  The values are drawn from the items in the location types
+      registry [11].  This information makes it easy, for example, for
+      the DHCP client to then populate the presence information.  Since
+      this is an IANA-registered token, the language and script
+      designations do not apply for this element.
+
+   Additional code:  The "additional code" item (CAtype 32) provides an
+      additional, country-specific code identifying the location.  For
+      example, for Japan, it contains the Japan Industry Standard (JIS)
+      address code.  The JIS address code provides a unique address
+      inside of Japan, down to the level of indicating the floor of the
+      building.
+
+   SEAT:  The "seat" item (CAtype 33) designates a place where a person
+      might sit, such as a seat in a stadium or theater, or a cubicle in
+      an open-plan office or a booth in a trade show.
+
+   Primary road name:  The "primary road" item (CAtype 34) is given to
+      the road or street name associated with the address.  If CAtypes
+      35 through 37 are not specified, the building or designated
+      location is found on that street.  If some of CAtypes 35 through
+      37 are specified, this designates the main road, off of which the
+      smaller streets branch off and where the structure or building is
+      actually located.
+
+   Road section:  The "road section" item (CAtype 35) designates a
+      specific section or stretch of a primary road.  This is a new
+      thoroughfare element and is useful where a primary road is divided
+      into sections that re-use the same street number ranges.
+
+   Branch road name:  The "branch road name" item (CAtype 36) represents
+      the name or identifier of a road or street that intersects or is
+      associated with a primary road.  The branch road name is used only
+      in countries where side streets do not have unique names within a
+      municipality or other administrative unit, but rather must be
+
+
+
+
+Schulzrinne                 Standards Track                    [Page 12]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+      qualified by the name of the primary road name that they branch
+      off of.
+
+   Sub-Branch road name:  The "sub-branch road name" (CAtype 37) item
+      represents the name of a street that branches off a branch road
+      (CAtype 36).  The sub-branch road name is used only in countries
+      where such streets are named relative to the primary road name and
+      branch road that they connect with.
+
+   Street name pre-modifier:  The "street name pre-modifier" (CAtype 38)
+      is an optional element of the complete street name.  It is a word
+      or phrase that precedes all other elements of the street name and
+      modifies it, but is separated from the street name by a street
+      name pre-directional.  An example is "Old" in "Old North First
+      Street".
+
+   Street name post-modifier:  The "street name post-modifier" (CAtype
+      39) is an optional element of the complete street name.  It is a
+      word or phrase that follows all other elements of the street name
+      and modifies it, but is separated from the street name by a street
+      name post-directional and/or street suffix.  An example is
+      "Extended" in "East End Avenue Extended".
+
+4.  Postal Addresses
+
+   In general, a recipient can construct a postal address by using all
+   language-appropriate elements, including the postal code (ZIP, CAtype
+   24).  However, certain elements override the civic address components
+   to create a postal address.  If the elements include a post office
+   box (CAtype 31), the street address components (CAtype 34, PRD, POD,
+   STS, HNO, HNS) are replaced with the post office box element.  If a
+   postal community name is specified, the civic community name
+   (typically, A3) is replaced by the postal community name (PCN, CAtype
+   30).  Country-specific knowledge is required to create a valid postal
+   address.  The formating of such addresses is beyond the scope of this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                    [Page 13]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+5.  Example
+
+   Rather than showing the precise byte layout of a DHCP option, we show
+   a symbolic example below, representing the civic address of the
+   Munich city hall in Bavaria, Germany.  The city and state name are
+   also conveyed in English and Italian in addition to German; the other
+   items are assumed to be common across all languages.  All languages
+   use the latin script.
+
+                     +--------+---------------------+
+                     | CAtype | CAvalue             |
+                     +--------+---------------------+
+                     | 0      | de                  |
+                     |        |                     |
+                     | 128    | Latn                |
+                     |        |                     |
+                     | 1      | Bayern              |
+                     |        |                     |
+                     | 2      | Oberbayern          |
+                     |        |                     |
+                     | 3      | M=U+00FCnchen       |
+                     |        |                     |
+                     | 6      | Marienplatz         |
+                     |        |                     |
+                     | 19     | 8                   |
+                     |        |                     |
+                     | 21     | Rathaus             |
+                     |        |                     |
+                     | 24     | 80331               |
+                     |        |                     |
+                     | 29     | government-building |
+                     |        |                     |
+                     | 31     | Postfach 1000       |
+                     |        |                     |
+                     | 0      | en                  |
+                     |        |                     |
+                     | 1      | Bavaria             |
+                     |        |                     |
+                     | 3      | Munich              |
+                     |        |                     |
+                     | 0      | it                  |
+                     |        |                     |
+                     | 1      | Baviera             |
+                     |        |                     |
+                     | 3      | Monaco              |
+                     +--------+---------------------+
+
+
+
+
+
+Schulzrinne                 Standards Track                    [Page 14]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+6.  Security Considerations
+
+   The security considerations discussed in the GEOPRIV architecture
+   defined by RFC 3693 [9] apply.
+
+   Where critical decisions might be based on the value of this
+   GEOCONF_CIVIC option, DHCPv4 authentication in RFC 3118 [5] SHOULD be
+   used to protect the integrity of the DHCP options.
+
+   Since there is no privacy protection for DHCP messages, an
+   eavesdropper who can monitor the link between the DHCP server and
+   requesting client can discover the information contained in this
+   option.  Thus, usage of this option on networks without access
+   restrictions or network-layer or link-layer privacy mechanisms is NOT
+   RECOMMENDED.
+
+   To minimize the unintended exposure of location information, the
+   GEOCONF_CIVIC option SHOULD be returned by DHCPv4 servers only when
+   the DHCPv4 client has included this option in its 'parameter request
+   list' (RFC 2131 [2], Section 3.5).  Similarly, the
+   OPTION_GEOCONF_CIVIC option SHOULD be returned by DHCPv6 servers only
+   when the DHCPv6 client has included this option in its OPTION_ORO.
+
+   After initial location information has been introduced, it MUST be
+   afforded the protections defined in RFC 3694 [10].  Therefore,
+   location information SHOULD NOT be sent from a DHCP client to a DHCP
+   server.  If a client decides to send location information to the
+   server, it is implicitly granting that server unlimited retention and
+   distribution permissions.
+
+7.  IANA Considerations
+
+   The IANA has registered new DHCPv4 and DHCPv6 option codes for the
+   Civic Address (GEOCONF_CIVIC and OPTION_GEOCONF_CIVIC, respectively).
+
+   This document establishes a new IANA registry for CAtypes designating
+   civic address components.  Referring to RFC 2434 [14], this registry
+   operates under both "Expert Review" and "Specification Required"
+   rules.  The IESG will appoint an Expert Reviewer who will advise IANA
+   promptly on each request for a new or updated CAtype.
+
+   CAtype:  Numeric identifier, assigned by IANA.
+
+   Brief description:  Short description identifying the meaning of the
+      element.
+
+
+
+
+
+
+Schulzrinne                 Standards Track                    [Page 15]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+   Reference to published specification:  A stable reference to an RFC
+      or other permanent and readily available reference, in sufficient
+      detail so that interoperability between independent
+      implementations is possible.
+
+   Country-specific considerations:  If applicable, notes whether the
+      element is only applicable or defined for certain countries.
+
+   The initial list of registrations is contained in Section 3.4.
+
+   Updates to country-specific considerations for previously-defined
+   CAtypes are not defined by IANA registrations since they are purely
+   descriptive, not a registration of identifiers.  As noted earlier,
+   country-specific conventions may optionally be written up in
+   documents titled "Civic Addresses for [Country]".
+
+8.  References
+
+8.1.  Normative References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+         March 1997.
+
+   [3]   Alvestrand, H., "IETF Policy on Character Sets and Languages",
+         BCP 18, RFC 2277, January 1998.
+
+   [4]   Alvestrand, H., "Tags for the Identification of Languages", BCP
+         47, RFC 3066, January 2001.
+
+   [5]   Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
+         RFC 3118, June 2001.
+
+   [6]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
+         Carney, "Dynamic Host Configuration Protocol for IPv6
+         (DHCPv6)", RFC 3315, July 2003.
+
+   [7]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
+         63, RFC 3629, November 2003.
+
+   [8]   Lemon, T. and S. Cheshire, "Encoding Long Options in the
+         Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
+         November 2002.
+
+   [9]   Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
+         Polk, "Geopriv Requirements", RFC 3693, February 2004.
+
+
+
+Schulzrinne                 Standards Track                    [Page 16]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+   [10]  Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat
+         Analysis of the Geopriv Protocol", RFC 3694, February 2004.
+
+   [11]  Schulzrinne, H. and H. Tschofenig, "Location Types Registry",
+         RFC 4589, July 2006.
+
+   [12]  International Organization for Standardization, ISO., "ISO
+         15924:2004.  Information and documentation - Codes for the
+         representation of names of scripts", January 2004.
+
+8.2.  Informative References
+
+   [13]  Phillips, A. and M. Davis, "Tags for Identifying Languages",
+         Work in Progress, October 2005.
+
+   [14]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434, October
+         1998.
+
+   [15]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
+         Configuration Protocol Option for Coordinate-based Location
+         Configuration Information", RFC 3825, July 2004.
+
+   [16]  Peterson, J., "A Presence-based GEOPRIV Location Object
+         Format", RFC 4119, December 2005.
+
+   [17]  United States Postal Service, "Postal Addressing Standards",
+         November 2000.
+
+   [18]  National Emergency Number Assocation, "NENA Recommended Formats
+         and Protocols For ALI Data Exchange, ALI Response and GIS
+         Mapping", NENA NENA-02-010, January 2002.
+
+Acknowledgements
+
+   Harald Alvestrand, Stefan Berger, Peter Blatherwick, Joel M. Halpern,
+   David Kessens, Cheng-Hong Li, Rohan Mahy, James Polk, Martin Thomson
+   and Hannes Tschofenig provided helpful comments.  Examples and
+   inspiration were drawn from the Street Address Data Standard of the
+   Federal Geographic Data Committee.
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                    [Page 17]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+Author's Address
+
+   Henning Schulzrinne
+   Columbia University
+   Department of Computer Science
+   450 Computer Science Building
+   New York, NY  10027
+   US
+
+   Phone: +1 212 939 7004
+   EMail: hgs+geopriv@cs.columbia.edu
+   URI:   http://www.cs.columbia.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                    [Page 18]
+
+RFC 4776                       DHCP Civic                  November 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2006).
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+Schulzrinne                 Standards Track                    [Page 19]
+