diff options
Diffstat (limited to 'doc/rfc/rfc6848.txt')
| -rw-r--r-- | doc/rfc/rfc6848.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc6848.txt b/doc/rfc/rfc6848.txt new file mode 100644 index 0000000..bad7a91 --- /dev/null +++ b/doc/rfc/rfc6848.txt @@ -0,0 +1,1179 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Winterbottom +Request for Comments: 6848 CommScope +Updates: 4776, 5222 M. Thomson +Category: Standards Track Skype +ISSN: 2070-1721 R. Barnes + BBN Technologies + B. Rosen + NeuStar, Inc. + R. George + Huawei Technologies + January 2013 + + + Specifying Civic Address Extensions in + the Presence Information Data Format Location Object (PIDF-LO) + +Abstract + + New fields are occasionally added to civic addresses. A backward- + compatible mechanism for adding civic address elements to the Geopriv + civic address format is described. A formal mechanism for handling + unsupported extensions when translating between XML and DHCP civic + address forms is defined for entities that need to perform this + translation. Initial extensions for some new elements are also + defined. The Location-to-Service Translation (LoST) protocol + mechanism (defined in RFC 5222) that returns civic address element + names used for validation of location information is clarified and is + normatively updated to require a qualifying namespace identifier on + each civic address element returned as part of the validation + process. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6848. + + + + + + + +Winterbottom, et al. Standards Track [Page 1] + +RFC 6848 Civic Extensions January 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Specifying Civic Address Extensions . . . . . . . . . . . . . 5 + 3. Translating Unsupported Elements . . . . . . . . . . . . . . . 6 + 3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6 + 3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6 + 3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 7 + 3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 8 + 4. CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . . 9 + 5. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.2. Milepost . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 10 + 5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 10 + 5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 11 + 5.6. Extension Examples . . . . . . . . . . . . . . . . . . . . 11 + 6. Using Local Civic Extension with the LoST Protocol . . . . . . 12 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 8.1. CAtype Registration for Extensions . . . . . . . . . . . . 13 + 8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 14 + 8.3. Registration Template . . . . . . . . . . . . . . . . . . 14 + 8.4. Registration of the CAtypes Defined in this Document . . . 15 + 8.5. Registration Policy and Expert Guidance . . . . . . . . . 16 + 8.6. URN Sub-Namespace Registration . . . . . . . . . . . . . . 17 + 8.7. XML Schema Registration . . . . . . . . . . . . . . . . . 17 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 + + + +Winterbottom, et al. Standards Track [Page 2] + +RFC 6848 Civic Extensions January 2013 + + +1. Introduction + + The Geopriv civic location specifications ([RFC4776], [RFC5139]) + define an XML and binary representations for civic addresses that + allow for the expression of civic addresses. Guidance for the use of + these formats for the civic addresses in different countries is + included in [RFC5774]. + + Subsequent to these specifications being produced, use cases for + extending the civic address format with new elements have emerged. + [RFC5774] describes a mechanism for mapping long-standing address + formats into the civic address elements defined in [RFC4776] and + [RFC5139]. However, some of these existing address elements do not + readily fit into the civic address elements defined in [RFC4776] and + [RFC5139]. In these cases, creating new civic address elements + provides a better solution than overloading existing civic address + fields, which may cause confusion. + + The XML format for civic addresses [RFC5139] provides a mechanism + that allows for the addition of standardized or privately understood + elements. A similar facility for private extension is not provided + for the DHCP format [RFC4776], though new specifications are able to + define new CAtypes (civic address types). + + A recipient of a civic address in either format currently has no + option other than to ignore elements that it does not understand. + This results in any elements that are unknown to that recipient being + discarded if a recipient performs a translation between the two + formats. In order for a new extension to be preserved through + translation by any recipient, the recipient has to understand the + extension and know how to correlate an XML element with a CAtype. + + This document describes how new civic address elements are added. + Extensions always start with the definition of XML elements. A + mechanism for carrying the extension in the DHCP format is described. + A new XML namespace containing a small number of additional civic + elements is also defined and can be used as a template to illustrate + how other extensions can be defined as required. + + These mechanisms ensure that any translation between formats can be + performed consistently and without loss of information. Translation + between formats can occur without knowledge of every extension that + is present. + + The registry of numeric CAtypes is modified so that the creators of + extensions can advertise new namespaces and civic elements to + encourage maximum reuse. + + + + +Winterbottom, et al. Standards Track [Page 3] + +RFC 6848 Civic Extensions January 2013 + + + The additions described in this document are backwardly compatible. + Existing implementations may cause extension information to be lost, + but the presence of extensions does not affect an implementation that + conforms to either [RFC4776] or [RFC5139]. + + This document also normatively updates [RFC5222] to clarify that the + namespace must be included with the element name in the lists of + valid, invalid, and not checked elements in the <locationValidation> + part of a Location-to-Service Translation (LoST) response. While the + LoST schema does not need to be changed, the example in the document + is updated to show the namespaces in the lists. + +1.1. Motivating Example + + One instance where translation might be necessary is where a device + receives location configuration using DHCP [RFC4776]. Conversion of + DHCP information to an XML form is necessary if the device wishes to + use the DHCP-provided information in a range of applications, + including location-based presence services [RFC4079] and emergency + calling [RFC5012]. + + +--------+ +--------+ +-----------+ + | DHCP | DHCP | Device | XML | Recipient | e.g., Presence + | Server |--------->| |-------->| | Agent + +--------+ +--------+ +-----------+ + + Figure 1: Conversion Scenario + + The device that performs the translation between the DHCP and XML + formats might not be aware of some of the extensions that are in use. + Without knowledge of these extensions and how they are represented in + XML, the device is forced to discard them. + + These extensions could be useful, or may be critical, to the ultimate + consumers of this information. For instance, an extension element + might provide a presence watcher with important information in + locating the device, or an extension might be significant in choosing + a particular call route. + +1.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]. + + + + + + + +Winterbottom, et al. Standards Track [Page 4] + +RFC 6848 Civic Extensions January 2013 + + +2. Specifying Civic Address Extensions + + The civic schema in [RFC5139] defines an ordered structure of + elements that can be combined to describe a civic address. The XML + extension point at the end of this sequence is used to extend the + address. + + New elements are defined in a new XML namespace [XMLNS]. This is + true of address elements with significance within private or + localized domains as well as those that are intended for global + applicability. + + New elements SHOULD use the basic "caType" schema type defined in + [RFC5139]. This type provides an optional "xml:lang" attribute. + + For example, suppose the (fictitious) Central Devon Canals Authority + wishes to introduce a new civic element called "bridge". The + authority defines an XML namespace that includes a "bridge" element. + The namespace needs to be a unique URI, for example + "http://devon.canals.example.com/civic". + + A civic address that includes the new "bridge" element is shown in + Figure 2. + + <civicAddress xml:lang="en-GB" + xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" + xmlns:cdc="http://devon.canals.example.com/civic"> + <country>UK</country> + <A1>Devon</A1> + <A3>Monkokehampton</A3> + <RD>Deckport</RD> + <STS>Cross</STS> + + <cdc:bridge>21451338</cdc:bridge> + + </civicAddress> + + Figure 2: Extended Civic Address Example + + An entity that receives this location information might not + understand the extension address element. As long as the added + element is able to be safely ignored, the remainder of the civic + address can be used. The result is that the information is not as + useful as it could be, but the added element does not prevent the use + of the remainder of the address. + + The address can be passed to other applications, such as a LoST + server [RFC5222], without modification. If the application + + + +Winterbottom, et al. Standards Track [Page 5] + +RFC 6848 Civic Extensions January 2013 + + + understands the added element(s), it is able to make use of that + information. For example, if this civic address is acquired using + HTTP-Enabled Location Delivery (HELD) [RFC5985], it can be included + in a LoST request directly. + +3. Translating Unsupported Elements + + Unsupported civic address elements can be carried without consequence + as long as the format of the address does not change. However, + conversion between formats has been shown to be necessary. + + Format conversion requires knowledge of the format of the address + elements. An entity performing a conversion between XML and DHCP + address formats is forced to discard unrecognized elements. The + entity performing the conversion has no way to know the correct + element to use in the target format. + + This document defines a single extension element for the DHCP format + that makes knowledge of extensions unnecessary during conversion. + This extension element relies on the extension mechanisms defined for + the XML format. New extensions to the civic address format MUST be + defined only for the XML format; these extensions are then conveyed + in DHCP using the extension element. + + Further extensions to the DHCP format are prohibited; these + extensions cannot be safely conveyed in environments where conversion + is possible. + +3.1. XML to DHCP Format Translation + + Extensions to the XML format [RFC5139] are defined in a new XML + namespace [XMLNS]. The XML namespace received in DHCP is expressed + as a URL, however, it should not be dereferenced or treated as a + source location for the actual schema and doing so will serve no + useful purpose. + + Extensions in the XML format can be added to a DHCP format civic + address using an extension CAtype. + +3.2. Extension Civic Address Type (CAtype) + + The extension CAtype (CAtype code 40) includes three values that + uniquely identify the XML extension and its value: a namespace URI, + the local name of the XML element, and the text content of that + element. These three values are all included in the value of the + CAtype, each separated by a single whitespace character. + + + + + +Winterbottom, et al. Standards Track [Page 6] + +RFC 6848 Civic Extensions January 2013 + + + 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 (40) | Length | Namespace URI ... . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . Namespace URI (continued) . + . ... . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Space (U+20) | XML element local name . + +---------------+ . + . ... . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Space (U+20) | Extension type value . + +---------------+ . + . ... . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: XML Civic Address Extension CAtype + + CAtype (40) identifies the extension CAtype. + + Length is the number of octets used to represent the namespace URI, + local name, and value. The length includes the space between the + namespace URI and local name and the space between the local name and + value fields. + + The content of a CAtype (after the CAtype code and length) is UTF-8 + encoded Unicode text [RFC3629]. A maximum of 255 octets is allowed. + Octets consumed by the namespace URI and local name reduce the space + available for values. + + This conversion only works for elements that have textual content and + an optional "xml:lang" attribute. Elements with complex content or + other attributes -- aside from namespace bindings -- MUST be ignored + if they are not understood. + +3.3. DHCP to XML Format Translation + + The registration of a new CAtype following the process in [RFC4776] + means that a recipient that does not know the equivalent XML is + unable to produce a complete XML representation of the DHCP civic + address. For this reason, this document ends the registration of new + numeric CAtypes. No new registrations of numeric CAtypes can be + made. + + + + +Winterbottom, et al. Standards Track [Page 7] + +RFC 6848 Civic Extensions January 2013 + + + In lieu of making new numerical CAtype assignments, this document + creates a new extensionCA type that is defined in a manner that lets + new civic elements be described in DHCP form by carrying the + namespace and type name of the extension in parameters of the + extensionCA type. + + When converting to XML, the namespace prefix used for the extension + element is selected by the entity that performs the conversion. + +3.4. Conversion Example + + The following example civic address contains two extensions: + + <civicAddress xml:lang="en-US" + xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" + xmlns:post="http://postsoftheworld.example.com/ns" + xmlns:ap="http://example.com/airport/5.0"> + <country>US</country> + <A1>CA</A1> + + <post:lamp>2471</post:lamp> + <post:pylon>AQ-374-4(c)</post:pylon> + + <ap:airport>LAX</ap:airport> + <ap:terminal>Tom Bradley</ap:terminal> + <ap:concourse>G</ap:concourse> + <ap:gate>36B</ap:gate> + </civicAddress> + + Figure 4: XML Example with Multiple Extensions + + This is converted to a DHCP form as follows: + + country = US + CAtype[0] = en-US + CAtype[1] = CA + CAtype[40] = http://postsoftheworld.example.com/ns lamp 2471 + CAtype[40] = http://postsoftheworld.example.com/ns pylon AQ-374-4(c) + CAtype[40] = http://example.com/airport/5.0 airport LAX + CAtype[40] = http://example.com/airport/5.0 terminal Tom Bradley + CAtype[40] = http://example.com/airport/5.0 concourse G + CAtype[40] = http://example.com/airport/5.0 gate 36B + + Figure 5: Converted DHCP Example with Multiple Extensions + + + + + + + +Winterbottom, et al. Standards Track [Page 8] + +RFC 6848 Civic Extensions January 2013 + + +4. CAtypes Registry + + [RFC4776] created the CAtype registry. Among other things, this + registry advertised available civic elements. While it has always + been possible to use an extension namespace to define civic elements + that are not in the CAtype registry, and this document does not + change that, the registry is valuable to alert implementors of + commonly used civic elements and provides guidance to clients of what + elements they should support. + + This document alters the CAtype registry in several ways. It closes + the registry to new numeric CAtypes. It deletes the "NENA" column, + which is not needed. It adds columns for a namespace and contact, + and changes the name of the column currently called "PIDF" to "Local + Name". It also adds a column to the registry called "Type". "Type" + can have one of two values "A" and "B". Type A elements are intended + for wide use with many applications and SHOULD be implemented by all + clients unless the client is certain the element will not be + encountered. Type B civic elements MAY be implemented by any client. + + Type A civic elements require IETF review, while Type B elements only + require an expert review. + +5. Civic Extensions + + We use this new extension method to define some additional civic + address elements that are needed to correctly encode civic locations + in several countries. The definition of these new civic address + elements also serves as an example of how to define additional + elements using the mechanisms described in this document. + +5.1. Pole Number + + In some areas, utility and lamp posts carry a unique identifier, + which we call a pole number in this document. In some countries, the + label on the lamp post also carries the local emergency service + number, such as "110", encouraging callers to use the pole number to + identify their location. + + + + + + + + + + + + + +Winterbottom, et al. Standards Track [Page 9] + +RFC 6848 Civic Extensions January 2013 + + + _.-----,===. + | | (''''') + | | `---' + | | + | | ,---------, + | | ,---, |Emergency| + | | /|,-.|----->| Number | + | | / |110| '---------' + | | / |`-'| + |_|/ | 2 | ,---------, + | | | 1 | |Lamp Post| + | | | 2 |----->| Number | + |-| | 1 | '---------' + | |\ | 0 | + | | \ | 1 | + | | \ | 4 | + | | \|,,,| + _ | | + ``-..|.| + ``--.._ + `'--.._ + + Figure 6: Lamp Post with Emergency Number + +5.2. Milepost + + On some roads, trails, railroad rights of way, and other linear + features, a post with a mile or kilometer distance from one end of + the feature may be found (a "milepost"). There are other cases of + poles or markers with numeric indications that are not the same as a + "house number" or street address number. + +5.3. Street Type Prefix + + The civic schema defined in [RFC5139] allows the definition of + address "123 Colorado Boulevard", but it does not allow for the easy + expression of "123 Boulevard Colorado". Adding a street type prefix, + allows a street named in this manner to be more easily represented. + +5.4. House Number Prefix + + The civic schema defined in [RFC5139] provides a house number suffix + element, allowing one to express an address like "123A Main Street", + but it does not contain a corresponding house number prefix. The + house number prefix element allows the expression of address such as + "Z123 Main Street". + + + + + +Winterbottom, et al. Standards Track [Page 10] + +RFC 6848 Civic Extensions January 2013 + + +5.5. XML Extension Schema + + <?xml version="1.0"?> + <xs:schema + targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext" + xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext" + xmlns:xml="http://www.w3.org/XML/1998/namespace" + elementFormDefault="qualified" attributeFormDefault="unqualified"> + + <xs:import namespace="urn:ietf:params:xml:pidf:geopriv10:civicAddr"/> + + <!-- Post Number --> + <xs:element name="PN" type="ca:caType"/> + + <!-- Milepost --> + <xs:element name="MP" type="ca:caType"/> + + <!-- Street Type Prefix --> + <xs:element name="STP" type="ca:caType"/> + + <!-- House Number Prefix --> + <xs:element name="HNP" type="ca:caType"/> + + </xs:schema> + +5.6. Extension Examples + + <civicAddress xml:lang="en-US" + xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" + xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"> + <country>US</country> + <A1>CA</A1> + <A2>Sacramento</A2> + <RD>I5</RD> + <cae:MP>248</cae:MP> + <cae:PN>22-109-689</cae:PN> + </civicAddress> + + Figure 7: XML Example with Post Number and Milepost + + + + + + + + + + +Winterbottom, et al. Standards Track [Page 11] + +RFC 6848 Civic Extensions January 2013 + + + <civicAddress xml:lang="en-US" + xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" + xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"> + <country>US</country> + <A1>CA</A1> + <A2>Sacramento</A2> + <RD>Colorado</RD> + <HNO>223</HNO> + <cae:STP>Boulevard</cae:STP> + <cae:HNP>A</cae:HNP> + </civicAddress> + + Figure 8: XML Example with Street Type Prefix and House Number Prefix + +6. Using Local Civic Extension with the LoST Protocol + + One critical use of civic location information is in next generation + emergency services applications, in particular, call routing + applications. In such cases, location information is provided to a + location-based routing service using the LoST protocol [RFC5222]. + LoST is used to provide call routing information, but it is also used + to validate location information to ensure that it can route to an + emergency center when required. + + LoST is an XML-based protocol, and so the namespace extension + mechanisms described in this document do not impact LoST. When LoST + is used for validation, a <locationValidation> element is returned + containing a list of valid, a list of invalid, and a list of + unchecked civic elements. Figure 9 is an extract of the validation + response in Figure 6 from [RFC5222]. + + <locationValidation> + <valid>country A1 A3 A6</valid> + <invalid>PC</invalid> + <unchecked>HNO</unchecked> + </locationValidation> + + Figure 9: Location Validation Example from LoST (RFC5222) + + The RelaxNG schema in [RFC5222] requires the elements in each of + these lists to be namespace qualified, which makes the example in + Figure 6 of [RFC5222] erroneous. This issue is especially + significant when local-civic extensions are used as the domain to + which the extensions are attributed may impact their interpretation + by the server or client. To ensure that local-civic extensions do + not cause issues with the LoST server and client implementations, all + + + + + +Winterbottom, et al. Standards Track [Page 12] + +RFC 6848 Civic Extensions January 2013 + + + elements listed in a <valid>, <invalid>, or <unchecked> element MUST + be qualified with a namespace. To illustrate this, the extract above + from Figure 6 in [RFC5222] becomes Figure 10. + + <locationValidation + xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> + <valid>ca:country ca:A1 ca:A3 ca:A6</valid> + <invalid>ca:PC</invalid> + <unchecked>ca:HNO</unchecked> + </locationValidation> + + Figure 10: Corrected Location Validation Example + + If a validation request has also included the extensions defined in + Section 5, then the validation response would look like Figure 11. + + <locationValidation + xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" + xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"> + <valid>ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP</valid> + <invalid>ca:PC</invalid> + <unchecked>ca:HNO cae:MP cae:HNP</unchecked> + </locationValidation> + + Figure 11: Corrected Location Validation Example + +7. Security Considerations + + This document defines a formal way to extend the existing Geopriv + civic address schema. While no security threats are directly + introduced by this document, creators of new civic address extensions + should refer to Sections 4.3.1 and 5.1 of [RFC3694] to understand the + environments in which these new elements will be used. New elements + should only be registered if the person or organization performing + the registration understands any associated risks. + + Security threats applicable to the civic address formats are + described in [RFC4776] DHCP and [RFC5139] XML. + +8. IANA Considerations + + This document alters the "CAtypes" registry in the Civic Address + Types Registry established by [RFC4776]. + +8.1. CAtype Registration for Extensions + + IANA has allocated a CAtype code of 40 for the extension CAtype. + Registrations using this code will be made below, in Section 8.4. + + + +Winterbottom, et al. Standards Track [Page 13] + +RFC 6848 Civic Extensions January 2013 + + +8.2. Changes to the CAtype Registry + + IANA has made the following changes to the CAtype registry: + + o No registrations of new CAtype numbers in the Civic Address Types + Registry are permitted, except by IESG Approval [RFC5226] under + unusual circumstances. + + o The following note has been placed in the header of the CAtypes + registry, above the table: + + Note: As specified in RFC 6848, new registrations are only + accepted for CAtype 40, using the template specified in + Section 8.3. + + o The registration procedures are changed: IETF Review (if Type=A), + Expert Review (if Type=B). The designated expert is unchanged. + + o The reference for the table is changed: [RFC4776], RFC 6848 + + o The column called "NENA" is removed. + + o The column called "PIDF" is renamed to "Local Name". + + o New columns are added named "Namespace URI", "Contact", "Schema" + and "Type". All existing entries will have the following values + for those new columns: + + Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr + + Contact: The IESG (iesg@ietf.org); the GEOPRIV working group + (geopriv@ietf.org) + + Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr + + Type: A + +8.3. Registration Template + + New registrations in the Civic Address Types Registry require the + following information: + + CAtype: The assigned numeric CAtype. All new registrations will use + the value 40. + + Namespace URI: A unique identifier for the XML namespace used for + the extension element. + + + + +Winterbottom, et al. Standards Track [Page 14] + +RFC 6848 Civic Extensions January 2013 + + + Local Name: The local name of an XML element that carries the civic + address element. + + Description: A brief description of the semantics of the civic + address element. + + Example (optional): One or more simple examples of the element. + + Contact: Contact details for the person providing the extension. + + Specification (optional): A reference to a specification for the + civic address element. + + Schema (optional): A reference to a formal schema (XML schema, + RelaxNG, or other form) that defines the extension. + + Type: "A" or "B". + If Type is "A", all clients SHOULD implement this element. If + Type is "B", clients MAY implement this element. + +8.4. Registration of the CAtypes Defined in this Document + + This section registers the following four new CAtypes in the Civic + Address Types Registry. + + Post Number (see Section 5.1): + CAtype: 40 + Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext + Local Name: PN + Description: Post number that is attributed to a lamp post or + utility pole. + Contact: The IESG (iesg@ietf.org); the GEOPRIV working group + (geopriv@ietf.org) + Specification: RFC 6848, Section 5 + Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext + Type: A + + Milepost (see Section 5.2): + CAtype: 40 + Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext + Local Name: MP + Description: Milepost: a marker indicating distance to or from a + place (often a town). + Contact: The IESG (iesg@ietf.org); the GEOPRIV working group + (geopriv@ietf.org) + Specification: RFC 6848, Section 5 + Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext + Type: A + + + +Winterbottom, et al. Standards Track [Page 15] + +RFC 6848 Civic Extensions January 2013 + + + Street Type Prefix (see Section 5.3): + CAtype: 40 + Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext + Local Name: STP + Description: Street Type Prefix. + Contact: The IESG (iesg@ietf.org); the GEOPRIV working group + (geopriv@ietf.org) + Specification: RFC 6848, Section 5 + Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext + Type: A + + House Number Prefix (see Section 5.4): + CAtype: 40 + Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext + Local Name: HNP + Description: House Number Prefix. + Contact: The IESG (iesg@ietf.org); the GEOPRIV working group + (geopriv@ietf.org) + Specification: RFC 6848, Section 5 + Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext + Type: A + +8.5. Registration Policy and Expert Guidance + + The "CAtypes" registry is altered to operate on a registration policy + of "Expert Review", and optionally "Specification Required" [RFC5226] + if the element being registered has a Type value of "B". + + The registration rules for "Specification Required" are followed only + if a registration includes a reference to a specification. + Registrations can be made without a specification reference. + + If the element being registered has a Type value of "A", then the + registration policy is "IETF Review" [RFC5226]. + + All registrations are reviewed to identify potential duplication + between registered elements. Duplicated semantics are not prohibited + in the registry, though it is preferred if existing elements are + used. The expert review is advised to recommend the use of existing + elements following the guidance in [RFC5774]. Any registration that + is a duplicate or could be considered a close match for the semantics + of an existing element SHOULD include a discussion of the reasons + that the existing element was not reused. + + [RFC6280] provides a comprehensive framework concerning the privacy + of location information as pertaining to its use in Internet + applications. The expert reviewer is asked to keep the spirit of + this document in mind when reviewing new CAtype registrations. + + + +Winterbottom, et al. Standards Track [Page 16] + +RFC 6848 Civic Extensions January 2013 + + +8.6. URN Sub-Namespace Registration + + IANA has registered a new XML namespace, as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext + + Registrant Contact: IETF GEOPRIV working group (geopriv@ietf.org), + James Winterbottom (james.Winterbottom@commscope.com) + + 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 Extensions</title> + </head> + <body> + <h1>Additional Fields for GEOPRIV Civic Address</h1> + <h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc6848.txt"> + RFC 6848</a>.</p> + </body> + </html> + END + +8.7. XML Schema Registration + + This section registers an XML schema as per the procedures in + [RFC3688]. + + URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext + + Registrant Contact: IETF GEOPRIV working group (geopriv@ietf.org), + James Winterbottom (james.Winterbottom@commscope.com) + + XML: The XML for this schema can be found as the entirety of + Section 5.5 of this document. + +9. Acknowledgements + + Thanks to anyone who has tried to extend the civic schema and found + it a little less than intuitive. + + + + + +Winterbottom, et al. Standards Track [Page 17] + +RFC 6848 Civic Extensions January 2013 + + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + [RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, + "Threat Analysis of the Geopriv Protocol", RFC 3694, + February 2004. + + [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol + (DHCPv4 and DHCPv6) Option for Civic Addresses + Configuration Information", RFC 4776, November 2006. + + [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location + Format for Presence Information Data Format Location + Object (PIDF-LO)", RFC 5139, February 2008. + + [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. + Tschofenig, "LoST: A Location-to-Service Translation + Protocol", RFC 5222, August 2008. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., + Tschofenig, H., and H. Schulzrinne, "An Architecture for + Location and Location Privacy in Internet Applications", + BCP 160, RFC 6280, July 2011. + + [XMLNS] Hollander, D., Layman, A., Tobin, R., and T. Bray, + "Namespaces in XML 1.1 (Second Edition)", World Wide Web + Consortium Recommendation REC-xml-names11-20060816, + August 2006, + <http://www.w3.org/TR/2006/REC-xml-names11-20060816>. + + + + + + + + +Winterbottom, et al. Standards Track [Page 18] + +RFC 6848 Civic Extensions January 2013 + + +10.2. Informative References + + [RFC4079] Peterson, J., "A Presence Architecture for the + Distribution of GEOPRIV Location Objects", RFC 4079, + July 2005. + + [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for + Emergency Context Resolution with Internet Technologies", + RFC 5012, January 2008. + + [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic + Addresses in the Presence Information Data Format Location + Object (PIDF-LO): Guidelines and IANA Registry + Definition", BCP 154, RFC 5774, March 2010. + + [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", + RFC 5985, September 2010. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Winterbottom, et al. Standards Track [Page 19] + +RFC 6848 Civic Extensions January 2013 + + +Authors' Addresses + + James Winterbottom + CommScope + Suit 1, Level 2 + iC Enterprise 1, Innovation Campus + Squires Way + North Wollongong, NSW 2500 + AU + + Phone: +61 242 212938 + EMail: james.winterbottom@commscope.com + + + Martin Thomson + Skype + 3210 Porter Drive + Palo Alto, CA 94304 + US + + EMail: martin.thomson@gmail.com + + + Richard Barnes + BBN Technologies + 9861 Broken Land Parkway + Columbia, MD 21046 + US + + Phone: +1 410 290 6169 + EMail: rbarnes@bbn.com + + + Brian Rosen + NeuStar, Inc. + 470 Conrad Dr + Mars, PA 16046 + US + + EMail: br@brianrosen.net + + + + + + + + + + + +Winterbottom, et al. Standards Track [Page 20] + +RFC 6848 Civic Extensions January 2013 + + + Robins George + Huawei Technologies + Huawei Base, Bantian, Longgan District + Shenzhen, Guangdong 518129 + P. R. China + + Phone: +86 755 2878 8314 + EMail: robinsgv@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Winterbottom, et al. Standards Track [Page 21] + |