RFC 6848
Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)
RFC 6848 ✨ Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)
okay bestie, this one is about adding new fields to civic addresses 🏠💖 It's from the IETF, dated January 2013, and it's a Standards Track doc 🔥 Here's the title block tea:
- Authors: J. Winterbottom (CommScope), M. Thomson (Skype), R. Barnes (BBN Technologies), B. Rosen (NeuStar, Inc.), R. George (Huawei Technologies)
- Category: Standards Track
- ISSN: 2070-1721
- Updates: RFC 4776 and RFC 5222 (it updates both of them 👑)
Abstract
so new fields get added to civic addresses every now and then 🌸 This doc gives you a backward-compatible way to add civic address elements to the Geopriv civic address format. It also sets up a formal way to handle extensions that a translator doesn't support when converting between XML and DHCP civic address forms, for any entity that does that translation 🦋 It defines some initial extensions for new elements too ✨
The LoST protocol mechanism from RFC 5222, the one that returns civic address element names used for validating location info, gets clarified here. It's also normatively updated so that every civic address element returned during validation has to come with a qualifying namespace identifier 💅 Main character energy for namespaces, honestly.
Status of This Memo
this is an Internet Standards Track document 🔥 It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6848 🎀
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, as in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please read these carefully, because they spell out your rights and restrictions for 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 they're 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 . . . . . . . . . . . . . . . . . . 191. Introduction ✨
so the Geopriv civic location specs ([RFC4776], [RFC5139]) define XML and binary representations for civic addresses, which let you express them 🧚 Guidance on using these formats for civic addresses in different countries is in [RFC5774].
After those specs came out, people started wanting to extend the civic address format with new elements 💅 [RFC5774] describes a way to map long-standing address formats onto the civic address elements from [RFC4776] and [RFC5139]. But some of those existing address elements don't fit neatly into the ones defined in [RFC4776] and [RFC5139]. In those cases, making new civic address elements is a better move than overloading existing fields, because overloading can cause confusion 🙈
The XML format for civic addresses [RFC5139] has a mechanism for adding standardized or privately understood elements. The DHCP format [RFC4776] doesn't have a similar private extension facility, though new specs can define new CAtypes (civic address types) 🌈
Right now, a recipient of a civic address in either format has no option except to ignore elements it doesn't understand 😭 So if that recipient translates between the two formats, any elements it doesn't know get thrown away. For a new extension to survive translation by any recipient, the recipient has to understand the extension and know how to match an XML element with a CAtype.
This document explains how new civic address elements get added 🦋 Extensions always start by defining XML elements. It then describes how to carry the extension in the DHCP format. It also defines a new XML namespace with a small number of extra civic elements, which can serve as a template for showing how other extensions can be defined when needed.
These mechanisms make sure any translation between formats can happen consistently and without losing information. Translation can happen without knowing about every extension that's present 🫶
The registry of numeric CAtypes gets modified so that extension creators can advertise new namespaces and civic elements, which encourages maximum reuse 🍓
The additions in this document are backwardly compatible. Existing implementations may lose extension information, but the presence of extensions doesn't 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. The LoST schema doesn't need to change, but the example in the document is updated to show the namespaces in those lists 💜
1.1. Motivating Example
one place translation might be needed is when a device gets location configuration over DHCP [RFC4776] 🎀 If the device wants to use that DHCP-provided info in a range of applications, it needs to convert it to XML. That includes location-based presence services [RFC4079] and emergency calling [RFC5012] 🚨
+--------+ +--------+ +-----------+
| DHCP | DHCP | Device | XML | Recipient | e.g., Presence
| Server |--------->| |-------->| | Agent
+--------+ +--------+ +-----------+
Figure 1: Conversion ScenarioThe device doing the DHCP-to-XML translation might not know about some of the extensions in use 😬 Without knowing those extensions and how they're represented in XML, the device is forced to discard them.
These extensions could be useful, or even critical, to the final consumers of this info 👑 For example, an extension element might give a presence watcher important information for locating the device, or an extension might matter a lot when choosing a particular call route 🧚
1.2. Terminology
ok so 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] 🤓💖
2. Specifying Civic Address Extensions ✨
okay so the civic schema in [RFC5139] is basically an ordered line-up of elements you can mix and match to describe a civic address 📍. At the very end of that sequence there's an XML extension point 🎀, and that's where you tack on your own extra stuff.
New elements get their own brand new XML namespace [XMLNS] 💅. This is true whether the element only matters in a private or local setting or it's meant to work everywhere 🌍.
New elements SHOULD use the basic "caType" schema type defined in [RFC5139] 🦋. It comes with an optional xml:lang attribute, so you get language tagging for free ✨.
Let's say the (fictitious) Central Devon Canals Authority wants to add a brand new civic element called "bridge" 🌉. They make an XML namespace that includes a "bridge" element. The namespace has to be a unique URI, like http://devon.canals.example.com/civic 💜.
Here's a civic address that uses the new "bridge" element, see 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
Now, the receiving entity might not understand the extension element 🙈. As long as that added element can be safely ignored, the rest of the civic address is still usable 🫶. Is it as useful as it could be? Nah, not really 😭. But the extra element doesn't stop you from using the rest of the address, which is the important part.
The address can also be handed to other applications, like a LoST server [RFC5222], without any changes 🔥. If the app understands the added element(s), it can actually use that info. For example, if this civic address comes in through HTTP-Enabled Location Delivery (HELD) [RFC5985], it can go straight into a LoST request 🧚.
3. Translating Unsupported Elements 🔄
so unsupported civic address elements can ride along with no drama, as long as the address format doesn't change 💖. But once you start converting between formats, things get messier, and that's been shown to be necessary 😤.
Format conversion needs you to know the format of the address elements 🧠. Say an entity is converting between XML and DHCP address formats. It's basically forced to throw away any elements it doesn't recognize 💀, because it has no way of knowing the right element to use in the target format.
This document defines a single extension element for the DHCP format that means you don't need to know every extension during conversion ✨. That extension element leans on the extension mechanisms already defined for the XML format 🌸. New extensions to the civic address format MUST be defined only for the XML format 👑. Those extensions then get carried over in DHCP using the extension element 🎀.
Further extensions to the DHCP format are prohibited 🚫. They can't be safely carried in environments where conversion is possible, so that's a hard no 💅.
3.1. XML to DHCP Format Translation 🦋
Extensions to the XML format [RFC5139] are defined in a new XML namespace [XMLNS] 🌈. When that XML namespace shows up in DHCP, it's written as a URL. But here's the tea: it should not be dereferenced or treated as a source location for the actual schema, and doing that won't do anything useful 🙃.
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) has 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. All three go into the CAtype value, each one separated by a single whitespace character ✨.
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) is the code that identifies the extension CAtype 🆔.
Length is the number of octets used for the namespace URI, local name, and value 📏. It also counts the space between the namespace URI and local name, plus 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. Anything the namespace URI and local name use up is space you don't get for the value 🙈.
This conversion only works for elements with textual content and an optional xml:lang attribute 📝. Elements with complex content or other attributes (apart from namespace bindings) MUST be ignored if they are not understood 🚫. No exceptions, bestie 💅.
3.3. DHCP to XML Format Translation 🔁
Registering a new CAtype through the process in [RFC4776] has a catch 😬. A recipient that doesn't know the equivalent XML can't build a complete XML version of the DHCP civic address. That's why this document ends the registration of new numeric CAtypes 🛑. No new numeric CAtype registrations can be made, period.
Instead of making new numeric CAtype assignments, this document creates a new extensionCA type 🎉. It's defined so that new civic elements can be described in DHCP form, with the namespace and type name of the extension carried in the parameters of the extensionCA type 💜.
When converting to XML, the namespace prefix used for the extension element is picked by the entity doing the conversion 🧚.
3.4. Conversion Example 🍓
Here's an example civic address with 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
And here's how that gets converted to DHCP form 🔄:
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 36BFigure 5: Converted DHCP Example with Multiple Extensions
4. CAtypes Registry 📋
[RFC4776] created the CAtype registry 🎀. Among other things, the registry advertised the available civic elements. You've always been able to use an extension namespace to define civic elements that aren't in the CAtype registry, and this document doesn't change that 🙌. Still, the registry is valuable because it alerts implementors to commonly used civic elements and gives clients guidance on what they should support 💅.
This document changes the CAtype registry in a few ways 🔧. It closes the registry to new numeric CAtypes 🚪. It deletes the "NENA" column, since it isn't needed 🗑️. It adds columns for a namespace and contact, and it renames the column currently called "PIDF" to "Local Name" ✏️. It also adds a column called "Type" 🏷️. "Type" can have one of two values, "A" and "B" 🔤.
Type A elements are meant for wide use across many applications. They SHOULD be implemented by all clients, unless the client is certain the element will never be encountered 👑. Type B civic elements MAY be implemented by any client 🦋.
Type A civic elements need IETF review 🕵️, while Type B elements only need an expert review 🧑🏫.
5. Civic Extensions 🌍
We use this new extension method to define a few extra civic address elements that are needed to correctly encode civic locations in several countries 💖. These definitions also double as an example of how to define more elements with the mechanisms described in this document 🧁.
5.1. Pole Number 💡
In some areas, utility poles and lamp posts carry a unique identifier, which this document calls a pole number 🔦. In some countries, the label on the lamp post also shows the local emergency service number, like "110", which encourages callers to use the pole number to pinpoint where they are 🚨.
_.-----,===.
| | (''''')
| | `---'
| |
| | ,---------,
| | ,---, |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, you might find a post showing the distance in miles or kilometres from one end of the feature (a "milepost") 🚧. There are also other poles or markers with numeric labels that aren't the same as a "house number" or street address number 🔢.
5.3. Street Type Prefix 🎀
The civic schema defined in [RFC5139] lets you express the address "123 Colorado Boulevard" 🏙️, but it doesn't make it easy to express "123 Boulevard Colorado" 😩. Adding a street type prefix means a street named this way can be represented much more easily 🦋.
5.4. House Number Prefix 🎀
okay so the civic schema in [RFC5139] already has a house number suffix element, which is how you get something like "123A Main Street" 🏠. but there's no matching house number prefix element 😭. that's where this one comes in! it lets you write an address like "Z123 Main Street" and actually have it make sense 💅
5.5. XML Extension Schema 💜
here's the schema for the extension elements we've been talking about. it's giving very organized ✨
<?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 🌸
time for the fun part, bestie! here's a full address using the Milepost and Post Number elements 🛣️
<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 🧚
and this one shows the Street Type Prefix and House Number Prefix working together 🦋
<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 📞
okay this section is SO important, it's giving next-gen emergency services 🚨. one of the biggest uses of civic location info is call routing, where location gets handed to a location-based routing service using the LoST protocol [RFC5222]. LoST routes the call, but it also validates the location so that it can actually reach an emergency center when it needs to 🫶
LoST is XML-based, so the namespace extension mechanisms in this document don't mess with it at all ✨. when LoST does validation, it sends back a <locationValidation> element that holds a list of valid civic elements, a list of invalid ones, and a list of unchecked ones. Figure 9 is an extract of the validation response from Figure 6 in [RFC5222].
<locationValidation>
<valid>country A1 A3 A6</valid>
<invalid>PC</invalid>
<unchecked>HNO</unchecked>
</locationValidation>Figure 9: Location Validation Example from LoST (RFC5222) 📝
so here's the tea ☕. the RelaxNG schema in [RFC5222] says the elements in each of those lists have to be namespace qualified, which means the example in Figure 6 of [RFC5222] is wrong 😭. this matters a LOT with local-civic extensions, because the domain they're attributed to can change how the server or client interprets them. so to keep local-civic extensions from causing problems with LoST server and client implementations, every element listed in a <valid>, <invalid>, or <unchecked> element MUST be qualified with a namespace 🔥. here's the fixed version of that Figure 6 extract, which is 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 🦋
and if the validation request also included the extensions from Section 5, the 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 🔐
okay, security is where we get serious, bestie 💀. this document defines a formal way to extend the existing Geopriv civic address schema. no security threats are directly introduced by this document ✨, BUT if you're creating new civic address extensions, you SHOULD check out Sections 4.3.1 and 5.1 of [RFC3694] to understand the environments where your new elements will get used. hmm, wait, let me reword that so it's clear: 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. and new elements should only get registered if the person or organization doing the registration actually understands the risks that come with them 🙈
security threats for the civic address formats are described in [RFC4776] DHCP and [RFC5139] XML. go read those, periodt 📚
8. IANA Considerations 🍓
this section is about what IANA is doing with the registries, and it's giving very official 📋
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 💜
8.2. Changes to the CAtype Registry 🧁
here's what IANA changed in the CAtype registry, no cap:
- no new CAtype numbers can be registered in the Civic Address Types Registry, except by IESG Approval [RFC5226] under unusual circumstances 🚫
- this note got slapped in the header of the CAtypes registry, right 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.- the registration procedures changed to IETF Review (if Type=A), Expert Review (if Type=B). the designated expert stays the same ✨
- the reference for the table is now: [RFC4776], RFC 6848 📖
- the column called "NENA" is gone 👋
- the column called "PIDF" got renamed to "Local Name" 🏷️
- new columns were added called "Namespace URI", "Contact", "Schema" and "Type". all the existing entries get these values for the 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: A8.3. Registration Template 🌟
if you want to register something in the Civic Address Types Registry, you need to provide the following info, bestie 📝
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.
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. slay 💅
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: AMilepost (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: AStreet 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: AHouse 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: A8.5. Registration Policy and Expert Guidance 🔮
the "CAtypes" registry now runs on a registration policy of "Expert Review", and optionally "Specification Required" [RFC5226] if the element being registered has a Type value of "B" ✨
the "Specification Required" rules only get followed if a registration includes a reference to a specification. registrations can be made without one, so no stress 🫶
if the element being registered has a Type value of "A", then the registration policy is "IETF Review" [RFC5226] 🌸
every registration gets reviewed to spot possible duplicates between registered elements. duplicated semantics aren't prohibited in the registry, though it's preferred if existing elements get used. the expert review is advised to recommend using existing elements, following the guidance in [RFC5774] 👀. and any registration that's a duplicate or could be seen as a close match for the semantics of an existing element SHOULD include a discussion of why the existing element wasn't reused 📝
[RFC6280] gives a whole comprehensive framework about the privacy of location information as it's used in Internet applications 🔒. the expert reviewer is asked to keep the spirit of this document in mind when reviewing new CAtype registrations 🦋
8.6. URN Sub-Namespace Registration
okay so IANA registered a brand new XML namespace, following 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)the XML for it looks like this (it's giving very official xhtml vibes 🌸):
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>
END8.7. XML Schema Registration
this section registers an XML schema using 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 🫶😭
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>.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.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
Robins George
Huawei Technologies
Huawei Base, Bantian, Longgan District
Shenzhen, Guangdong 518129
P. R. China
Phone: +86 755 2878 8314
EMail: robinsgv@gmail.com📦 where this page comes from
- ietf: rfc6848 2013-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms