RFC 6739
Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol
RFC 6739 🦋 Experimental, October 2012
Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol ✨
Okay bestie, the title block first 💅 It's an Experimental doc (ISSN 2070-1721), so it's not a Standards Track spec, and it's dated October 2012. The authors are H. Schulzrinne from Columbia University and H. Tschofenig from Nokia Siemens Networks. The header doesn't list anything it obsoletes or updates, so no other RFCs get replaced or amended here 🌸
Abstract
Okay so the LoST protocol is XML-based, and its whole job is mapping service identifiers plus geodetic or civic location info to service URIs and service boundaries 🗺️ One super useful thing it can do is figure out the right Public Safety Answering Point (PSAP) for emergency services 🚨
The <mapping> element in the LoST spec holds the info about service boundaries. It draws the region where every location maps to the same service URI (or set of URIs) for a given service 💜
This doc defines an XML protocol that lets two nodes swap these mappings. It's built for trading authoritative <mapping> elements between two entities. Passing around cached ones (the non-authoritative kind) is possible, but it's not the vibe they had in mind 🙈 And even though the <mapping> format is borrowed straight from LoST, this mechanism works without the LoST protocol too ✨
Status of This Memo
Real talk, this doc is not an Internet Standards Track spec. It's out there for people to look at, try out in experimental implementations, and evaluate 🧚
It defines an Experimental Protocol for the Internet community 🔬 It's a product of the IETF and reflects the consensus of the IETF community. It went through public review and got the green light from the Internet Engineering Steering Group (IESG). Heads up, though: not every IESG-approved document is eligible for any level of Internet Standard. Check Section 2 of RFC 5741 for the details 💀
If you want the current status, errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc6739 🍓
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 🎀
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this document 👑 Any Code Components pulled out of this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License 🫶
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. A Motivating Example . . . . . . . . . . . . . . . . . . . . . 4
4. Querying for Mappings with a
<getMappingsRequest>/<getMappingsResponse> Exchange . . . . . 9
4.1. Behavior of the LoST Sync Destination . . . . . . . . . . 9
4.2. Behavior of the LoST Sync Source . . . . . . . . . . . . . 10
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Pushing Mappings via <pushMappings> and
<pushMappingsResponse> . . . . . . . . . . . . . . . . . . . . 12
5.1. Behavior of the LoST Sync Source . . . . . . . . . . . . . 12
5.2. Behavior of the LoST Sync Destination . . . . . . . . . . 13
5.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. RELAX NG . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Operational Considerations . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10.1. Media Type Registration . . . . . . . . . . . . . . . . . 21
10.2. LoST Sync RELAX NG Schema Registration . . . . . . . . . . 22
10.3. LoST Synchronization Namespace Registration . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 241. Introduction ✨
Since forever, emergency services have wanted to route emergency calls to the Public Safety Answering Points (PSAPs) closest to the person calling 🚨 So each PSAP shares one or more service boundaries, and that info is used to pick the right PSAP and send the call there 💖 RFC 5222 [RFC5222] defines this data structure like so:
A service boundary circumscribes the region within which all locations map to the same service URI or set of URIs for a given service. A service boundary may consist of several non-contiguous geometric shapes.
RFC 5222 [RFC5222] also names the data structure itself: the <mapping> element 🧚
This doc reuses that existing data structure and defines an XML-based protocol for two entities, the LoST Sync source and the LoST Sync destination, to exchange authoritative service boundaries 🦋 It works whether or not you're using the LoST protocol to query for service boundary info. Iconic flexibility 👑
Here's the layout: Section 3 kicks off with an example of using LoST. Sections 4, 5, 6, and 7 cover the protocol semantics, transport considerations, and the schema. Then we wrap up with operational, security, and IANA considerations in Sections 8, 9, and 10 🌈
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 RFC 2119 [RFC2119] 💅
This doc borrows terms from the mapping architecture doc [RFC5582], like 'coverage region', 'forest guide', 'mapping', and 'authoritative mapping server' 🍓 It also uses 'ESRP', which is defined in [RFC5012] 🔥
Throughout the doc, 'LoST Sync source' and 'LoST Sync destination' are the names for the two protocol endpoints in the exchange. In the text, the protocol itself is called 'LoST Sync' ✨
3. A Motivating Example ✨
okay bestie, let's talk about a real-life vibe for how LoST Sync can slot into the LoST architecture from [RFC5582] 💅 there, LoST servers team up to give us a ubiquitous, globally scalable, and resilient mapping service 🌈 in the LoST mapping architecture, LoST servers can peer (aka have an ongoing data exchange relationship) 🦋 peering relationships get set up manually, based on local policies, and a LoST server may peer with any number of other LoST servers 💜 forest guides peer with other forest guides 🌸 and authoritative mapping servers peer with forest guides and other authoritative servers, either in the same cluster or above or below them in the tree 🧚 the authoritative servers push coverage regions "up" the tree, from child nodes to parent nodes 🔥 so the child tells the parent the geospatial or civic region it covers for a specific service, and that's the whole glow-up 💖
let's imagine a hypothetical deployment of LoST in two countries, Austria and Finland 🇦🇹🇫🇮 Austria runs three authoritative mapping servers labeled 'East', 'West', and 'Vienna' 🎀 the first two cover the entire country except for Vienna, which gets its own separate LoST server 👑 there may be other caching LoST servers run by ISPs, universities, and Voice Service Providers (VSPs), but they're not relevant for this illustration 🙈 Finland, on the other hand, decided to only deploy a single LoST server that also acts as a forest guide 🍓 for this simplistic illustration, we assume only one service is available, namely 'urn:service:sos', since otherwise the number of stored mappings would have to be multiplied by the number of used services 😭
here's the example deployment in Figure 1 💜
+---LoST-Sync-->\\ //<--LoST-Sync----+
| ----- |
| |
\/ \/
----- -----
// \\ // \\
/ \ / \
| Forest | | Forest |
| Guide | | Guide |
| Austria | | Finland
\ / \ /
+--------->\\ //<--------+ \\ //
| ----- | -----
| /\ | |
LoST | LoST //------\\
Sync LoST Sync |Co-Located|
| Sync | | LoST |
\/ | \/ | Server |
//----\\ \/ //----\\ \\------//
| LoST | //----\\ | LoST |
| Server | | LoST | | Server |
| 'East' | | Server | |'Vienna'|
\\----// | 'West' | \\----//
\\----//Figure 1: LoST Deployment Example
the nodes are configured like this 🎀
Forest Guide Austria: this forest guide holds mappings for the three authoritative mapping servers (East, West, and Vienna) describing the area each one is responsible for 🗺️ note that each mapping contains a service URN, and these mappings point to LoST servers rather than to PSAPs or Emergency Services Routing Proxies (ESRPs) 🌸
LoST Server 'East': this LoST server holds all the mappings to PSAPs covering the eastern part of the country 💖 on top of that, it aggregates everything it has and gives the forest guide an abstracted view saying it's responsible for a certain area (for a given service and for a given location profile) ✨ here's what that mapping looks like:
<mapping
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml"
expires="2009-01-01T01:44:33Z"
lastUpdated="2009-12-01T01:00:00Z"
source="east-austria.lost-example.com"
sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
<displayName xml:lang="en">LoST Server 'East'</displayName>
<service>urn:service:sos</service>
<serviceBoundary profile="geodetic-2d">
<gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos> ... </gml:pos>
..... list of coordinates for
boundary of LoST server 'East'
<gml:pos> ... </gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</serviceBoundary>
<uri/>
</mapping>Figure 2: Forest Guide Austria Mapping XML Snippet
note that the XML snippet in Figure 2 is for illustrative purposes only and does not validate 🙈 as you can see, the <uri> element is absent, and the 'source' attribute identifies the LoST server, namely "east-austria.lost-example.com" 🦋
the mapping shown above is what the LoST server "east-austria.lost-example.com" provides to the Austrian forest guide 💅
LoST Server 'West': this LoST server holds all the mappings to PSAPs covering the western half of the country 🌈
LoST Server 'Vienna': this LoST server holds all the mappings to PSAPs for the city of Vienna 👑
Forest Guide Finland: in our example, Finland deploys a single ESRP for the entire country as their IP-based emergency services solution 🇫🇮 there's only one LoST server, and it's co-located with the forest guide, as shown in Figure 1 🧚 the mapping data this forest guide (FG) distributes via LoST Sync is shown in Figure 3 🔥
<mapping xmlns="urn:ietf:params:xml:ns:lost1"
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="finland.lost-example.com"
sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="en">Finland ESRP</displayName>
<service>urn:service:sos</service>
<serviceBoundary profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>FI</country>
</civicAddress>
</serviceBoundary>
<uri/>
</mapping>Figure 3: Forest Guide Finland Mapping XML Snippet
an example mapping stored at the co-located LoST server is shown in Figure 4 💖
<mapping xmlns="urn:ietf:params:xml:ns:lost1"
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="finland.lost-example.com"
sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="en">Finland ESRP</displayName>
<service>urn:service:sos</service>
<serviceBoundary profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>FI</country>
</civicAddress>
</serviceBoundary>
<uri>sip:esrp@finland-example.com</uri>
<uri>xmpp:esrp@finland-example.com</uri>
<serviceNumber>112</serviceNumber>
</mapping>Figure 4: Forest Guide Finland / Co-Located LoST Server Mapping XML Snippet
the LoST Sync mechanism described in this document can run between the two forest guides 🫶 that way, the three mappings stored in FG Austria get sent to FG Finland, and a single mapping in FG Finland gets sent to FG Austria 🌸 on top of that, the three Austrian LoST servers could use LoST Sync to tell the Austrian FG about their boundaries 🦋 those three authoritative mapping servers in Austria would be responsible for maintaining their own mapping information 💅 since the amount of data being exchanged is small and the expected rate of change is low, the nodes are configured to always exchange all their mapping information whenever a change happens 😭
this document defines two types of exchanges, best described by the exchange between two nodes in Figures 5 and 6 🌈 the protocol exchange always runs between a LoST Sync source and a LoST Sync destination 💜 Node A in the examples of Figures 5 and 6 has mappings that Node B is going to retrieve 🧚 Node A acts as the source for the data and Node B is the destination 🎀
the <getMappingsRequest> request lets a LoST Sync source request mappings from a LoST Sync destination 🔥
+---------+ +---------+
| Node B | | Node A |
| acting | | acting |
| as | | as |
| LoST | | LoST |
| Sync | | Sync |
| Dest. | | Source |
+---------+ +---------+
| |
| |
| |
| <getMappingsRequest> |
|----------------------------->|
| |
| <getMappingsResponse> |
|<-----------------------------|
| |
| |
| |Figure 5: Querying for Mappings with a <getMappingsRequest> Message
note that in the exchange in Figure 5, Node B issues the first request and plays the role of the HTTPS client, while Node A plays the role of the HTTPS server 🙌
in Figure 6, the <pushMappingsRequest> exchange lets a LoST Sync source push mappings to a LoST Sync destination 🦋 in this example, we assume Node A has been configured to maintain state about the mappings it pushed to Node B 💜
this document does not define a publish/subscribe mechanism 🙈 such a mechanism would let Node B tell Node A which mappings it's interested in 😭 this document also doesn't define a mechanism for nodes to find out which other entities mappings have to be pushed to 💀
+---------+ +---------+
| Node A | | Node B |
| acting | | acting |
| as | | as |
| LoST | | LoST |
| Sync | | Sync |
| Source | | Dest. |
+---------+ +---------+
| |
| |
| |
| <pushMappingsRequest> |
|----------------------------->|
| |
| <pushMappingsResponse> |
|<-----------------------------|
| |
| |
| |Figure 6: Pushing Mappings with a <pushMappingsRequest> Message
Node A, issuing the first request in Figure 6, plays the role of the HTTPS client, and Node B plays the role of the HTTPS server 🎀
4. Querying for Mappings with a <getMappingsRequest>/<getMappingsResponse> Exchange ✨
4.1. Behavior of the LoST Sync Destination ✨
Okay so a LoST Sync destination has two ways to grab <mapping> elements from a LoST Sync source 💖
- If the LoST Sync destination doesn't have any mappings yet, it sends an empty
<getMappingsRequest>message, as shown in Figure 7 🧚. This basically says "gimme everything you've got." Note that the request does not propagate further to other nodes 🫶. - If a LoST Sync destination node already got mappings in earlier exchanges, it might want to check whether any of them have been updated since 👀. The policy for when to poll for updated mapping information is outside the scope of this document 🙈. A
<getMappingsRequest>message with one or more<exists>child element(s) lets the source return only the mappings that are missing at the destination or have been updated. Main character efficiency 💅.
After sending the <getMappingsRequest> message, the LoST Sync destination waits for the <getMappingsResponse> message 🎀. If the response is successful, the LoST Sync destination stores the mappings it received and figures out which ones need updating 🌸.
4.2. Behavior of the LoST Sync Source 👑
When a LoST Sync source gets an empty <getMappingsRequest> message, then all locally available mappings MUST be returned. No cap, it has to give everything 🍓.
When a LoST Sync source gets a <getMappingsRequest> message with one or more <exists> child element(s), then it MUST consult with the local mapping database 📚. It checks two things: whether any of the client's mappings are stale, and whether there are mappings locally that the client doesn't have yet 🔍. The first one is figured out by finding mappings that match the 'source' and 'sourceID' attributes where there's a mapping with a more recent 'lastUpdated' date ⏰. Iconic detective work, honestly ✨.
Processing a <getMappingsRequest> message MAY lead to a successful response in the form of a <getMappingsResponse> or an <errors> message 🦋. Only the <badRequest>, <forbidden>, <internalError>, and <serverTimeout> errors, defined in [RFC5222], are used by this specification 💜. The <redirect> and <warnings> messages are not reused by this message, so don't even bring them 🙅♀️.
4.3. Examples 🎀
Let's look at the first example 💖. It's an empty <getMappingsRequest> message that would retrieve all locally stored mappings at the LoST Sync source 🌈.
<?xml version="1.0" encoding="UTF-8"?>
<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1"/>Figure 7: Example of Empty <getMappingsRequest> Message
Next up is Figure 8, with the response in Figure 9 ✨. Here the <getMappingsRequest> element holds info about a mapping the client already has, inside the <mapping-fingerprint> element. That mapping has source="authoritative.bar.example", sourceId="7e3f40b098c711dbb6060800200c9a66", and lastUpdated="2006-11-01T01:00:00Z" 🫶. The query asks for anything more recent than that one, plus any mapping that's missing entirely 🔥.
<?xml version="1.0" encoding="UTF-8"?>
<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1">
<exists>
<mapping-fingerprint source="authoritative.bar.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2006-11-01T01:00:00Z">
</mapping-fingerprint>
</exists>
</getMappingsRequest>Figure 8: Example <getMappingsRequest> Message
And here's the response in Figure 9 😭. A newer mapping showed up with source="authoritative.bar.example" and sourceId="7e3f40b098c711dbb6060800200c9a66". Only one missing mapping was found, the one with source "authoritative.foo.example", so that got returned too 💅.
<?xml version="1.0" encoding="UTF-8"?>
<sync:getMappingsResponse
xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml">
<mapping source="authoritative.bar.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2008-11-26T01:00:00Z"
expires="2009-12-26T01:00:00Z">
<displayName xml:lang="en">Leonia Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>NJ</A1>
<A3>Leonia</A3>
<PC>07605</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:police@leonianj2.example.org</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping expires="2009-01-01T01:44:33Z"
lastUpdated="2008-11-01T01:00:00Z"
source="authoritative.foo.example"
sourceId="7e3f40b098c711dbb606011111111111">
<displayName xml:lang="en">New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>37.775 -122.4194</gml:pos>
<gml:pos>37.555 -122.4194</gml:pos>
<gml:pos>37.555 -122.4264</gml:pos>
<gml:pos>37.775 -122.4264</gml:pos>
<gml:pos>37.775 -122.4194</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
</sync:getMappingsResponse>Figure 9: Example <getMappingsResponse> Message
5. Pushing Mappings via <pushMappings> and <pushMappingsResponse> 🦋
5.1. Behavior of the LoST Sync Source 💌
When a LoST Sync source gets new info that its peers would care about, it may push the new mappings to them 💕. Configuration settings at both peers decide whether this is used at all and which mappings get pushed to which peers ⚙️. New mappings can show up in different ways, like a manual addition to the local mapping database or through interaction with other entities 📥. Deleting mappings can also kick off a protocol interaction 🗑️.
The LoST Sync source SHOULD keep track of which LoST Sync destination it has pushed <mapping> elements to 📝. If it doesn't keep state information, then it always has to push the complete data set 😬. As discussed in Section 5.1 of [RFC5222], <mapping> elements are identified by the 'source', 'sourceID', and 'lastUpdated' attributes 🪪. A mapping counts as the same mapping only if all three attributes match ✨.
A <pushMappings> request sent by a LoST Sync source MUST contain one or more <mapping> elements 💜.
To delete a mapping, you leave the content of the mapping empty, so the <mapping> element only has the 'source', 'sourceID', 'lastUpdated', and 'expires' attributes 🧹. Figure 10 shows an example request where the mapping with source="nj.us.example", sourceId="123", lastUpdated="2008-11-01T01:00:00Z", and expires="2008-11-01T01:00:00Z" is requested to be deleted 🙈. Heads up: the 'expires' attribute is required per the schema definition, but it gets ignored when the receiving side processes the request 🤓. A sync source might want to delete the mapping from its internal mapping database, but it has to remember which peers it distributed this update to, unless it has other ways to make sure the databases don't get out of sync 🫠.
5.2. Behavior of the LoST Sync Destination 🌸
When a LoST Sync destination receives a <pushMappingsRequest> message, it inspects the cache of existing mappings to decide whether the received mapping should update an already existing mapping, should create a new mapping in the cache, or should be discarded 🗂️.
If a newly received mapping has a more recent time in its 'lastUpdated' attribute, it MUST update an existing mapping that has matching 'source' and 'sourceID' attributes 🔄.
If the received mapping doesn't match any existing mapping based on the 'source' and 'sourceId', then it MUST be added to the local cache as an independent mapping 🌟.
If a <pushMappingsRequest> message with an empty <mapping> element is received, then a corresponding mapping has to be determined based on the 'source' and the 'sourceID' 🔍.
If no mapping can be identified, then an <errors> response MUST be returned that contains the <notDeleted> child element 🚨. The <notDeleted> element MAY contain a 'message' attribute with an error description used for debugging purposes 🐛. The <notDeleted> element MUST contain the <mapping> element(s) that caused the error 🎯.
The response to a <pushMappingsRequest> request is a <pushMappingsResponse> message 💬. With this specification, a successful response message returns no additional elements, whereas an <errors> response comes back in the response message if the request failed 🥲. Only the <badRequest>, <forbidden>, <internalError>, or <serverTimeout> errors defined in Section 13.1 of [RFC5222] are used 💅. The <redirect> and <warnings> messages are not used for this query/response 🙅♀️.
If the set of nodes that are synchronizing their data doesn't form a tree, the same information can arrive through several other nodes 🌐. This is unavoidable, but it generally only adds a modest overhead 🫶. (It would be possible to create a spanning tree in the same fashion as IP multicast, but the complexity doesn't seem warranted, given the relatively low volume of data 🧠.)
5.3. Example 🎀
okay so the example lives in Figure 10 🧚 imagine a LoST node that just got two new mappings, identified like this:
source="authoritative.example",sourceId="7e3f40b098c711dbb6060800200c9a66",lastUpdated="2008-11-26T01:00:00Z"source="authoritative.example",sourceId="7e3f40b098c711dbb606011111111111",lastUpdated="2008-11-01T01:00:00Z"
Both of these have to be added to the peer's mapping database 💅
Then there's one more: a mapping that has to be deleted 💀
source="nj.us.example",sourceId="123",lastUpdated="2008-11-01T01:00:00Z"
Here's the whole <pushMappings> message, Figure 10 🔥
<?xml version="1.0" encoding="UTF-8"?>
<sync:pushMappings
xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml">
<mapping source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2008-11-26T01:00:00Z"
expires="2009-12-26T01:00:00Z">
<displayName xml:lang="en">Leonia Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>NJ</A1>
<A3>Leonia</A3>
<PC>07605</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:police@leonianj.example.org</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping expires="2009-01-01T01:44:33Z"
lastUpdated="2008-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb606011111111111">
<displayName xml:lang="en">New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>37.775 -122.4194</gml:pos>
<gml:pos>37.555 -122.4194</gml:pos>
<gml:pos>37.555 -122.4264</gml:pos>
<gml:pos>37.775 -122.4264</gml:pos>
<gml:pos>37.775 -122.4194</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping source="nj.us.example"
sourceId="123"
lastUpdated="2008-11-01T01:00:00Z"
expires="2008-11-01T01:00:00Z"/>
</sync:pushMappings>Figure 10: Example <pushMappingsRequest> Message 🎀
In response, the peer does the necessary operations and updates its mapping database. The big checks are whether the other peer is authorized to make the update and whether the elements and attributes contain values it understands 👑 In our example, the response is a positive one, as shown in Figure 11 ✨
<?xml version="1.0" encoding="UTF-8"?>
<pushMappingsResponse xmlns="urn:ietf:params:xml:ns:lostsync1" />Figure 11: Example <pushMappingsResponse> 🦋
If a mapping couldn't be deleted as requested, an error response like this one might come back instead 😭
<?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
source="nodeA.example.com">
<sync:notDeleted
message="Could not delete the indicated mapping."
xml:lang="en">
<mapping source="nj.us.example"
sourceId="123"
lastUpdated="2008-11-01T01:00:00Z"
expires="2008-11-01T01:00:00Z"/>
</sync:notDeleted>
</errors>Figure 12: Example <errors> Message 🌸
6. Transport ✨
okay transport time 🚚 LoST Sync needs an underlying protocol transport to carry its requests and responses. This document uses HTTPS as the transport to swap XML documents, and there's no fallback to HTTP 🔒
When it's HTTP over Transport Layer Security (TLS) [RFC2818], LoST Sync messages use the POST method. Requests MUST use the Cache-Control response directive "no-cache". no skipping this one bestie 🫶
All LoST Sync responses, including the ones that signal a LoST warning or error, are carried in 2xx responses, usually 200 (OK). 3xx, 4xx, and 5xx HTTP response codes mean the request itself failed or got redirected, and those responses don't contain any LoST Sync XML elements 🙈
7. RELAX NG 🧚
Note: so we don't have to copy pattern definitions from the LoST Regular Language for XML Next Generation (RELAX NG) schema [RFC5222] into this doc, we include it as "lost.rng" (XML syntax) in the RELAX NG schema below 💜
<?xml version="1.0" encoding="utf-8"?>
<grammar ns="urn:ietf:params:xml:ns:lostsync1"
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<include href="lost.rng"/>
<start combine="choice">
<a:documentation> Location-to-Service Translation (LoST)
Synchronization Protocol</a:documentation>
<choice>
<ref name="pushMappings"/>
<ref name="pushMappingsResponse"/>
<ref name="getMappingsRequest"/>
<ref name="getMappingsResponse"/>
</choice>
</start>
<define name="pushMappings">
<element name="pushMappings">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
<ref name="extensionPoint"/>
</element>
</define>
<define name="pushMappingsResponse">
<element name="pushMappingsResponse">
<ref name="extensionPoint"/>
</element>
</define>
<define name="getMappingsRequest">
<element name="getMappingsRequest">
<choice>
<ref name="exists"></ref>
<ref name="extensionPoint"/>
</choice>
</element>
</define>
<define name="exists">
<element name="exists">
<oneOrMore>
<element name="mapping-fingerprint">
<attribute name="source">
<data type="token"/>
</attribute>
<attribute name="sourceId">
<data type="token"/>
</attribute>
<attribute name="lastUpdated">
<data type="dateTime"/>
</attribute>
<ref name="extensionPoint"/>
</element>
</oneOrMore>
</element>
</define>
<define name="getMappingsResponse">
<element name="getMappingsResponse">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
<ref name="extensionPoint"/>
</element>
</define>
<!-- error messages -->
<define name="notDeleted">
<element name="notDeleted">
<ref name="basicException"/>
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
</element>
</define>
</grammar>8. Operational Considerations 🧠
bestie this section is SO important 🚨 It's really important to avoid loops when more than two LoST servers use the mechanism in this document. Figure 13 shows three LoST servers, A, B, and C (each one is a sync source and a sync destination), and it's the best way to see the challenge 👀 A and B sync data with each other, same for A and C, and B and C 🔁
A -------- B
\ /
\ /
\ /
\ /
CFigure 13: Synchronization Configuration Example 🦋
Now imagine server A adds a new mapping. It's uniquely identified by the combo of "source", "sourceid", and "last updated". Say A wants to push this new mapping to B and C. When B gets it, B works out that it has to pass it along to its peer C. C also needs to pass the mapping to its peer B. If the original mapping with that "source", "sourceid", and "last updated" isn't modified by either B or C, then those two servers will recognize they already have the mapping and can ignore the update ✨
Implementations MUST NOT modify mappings they receive. The problem is that an entity acting maliciously would intentionally modify mappings or inject bogus mappings 💀 To avoid an untrustworthy member claiming a coverage region it isn't authorized for, authoritative mapping servers MUST sign mappings they distribute using an XML digital signature [W3C.REC-xmldsig-core-20020212]. A recipient MUST verify that the signing entity is indeed authorized to speak for that region. In a lot of cases this needs an out-of-band agreement in place to pick the specific entities that take on this role 🤝 Figuring out who can speak for a particular region is inherently difficult, unless there's a small set of authorizing entities that participants in the mapping architecture can trust 🫣
Receiving systems should be particularly suspicious if an existing coverage region gets replaced by a new one that has a different value in the <uri> element. 🚩
When mappings are digitally signed, intermediate LoST servers can't modify them 🔐
9. Security Considerations 🔐
okay bestie, this section is seriously important 😭 This document defines a protocol for exchanging authoritative mapping information between two entities, so the protocol operations here need authentication of neighboring nodes 🫶
The LoST Sync client and servers MUST implement TLS and use TLS 🔒 Which versions should be implemented will change over time and depend on how widely they're deployed and what security vulnerabilities are known when you're building it 💅 When this was written, TLS version 1.2 [RFC5246] was the newest version, but it had very limited real-world deployment and might not be easy to find in implementation toolkits 🙈 TLS version 1.0 [RFC2246] is the most widely deployed version and gives the broadest interoperability ✨
Mutual authentication between the LoST Sync source and the LoST Sync destination isn't necessarily required in every deployment 🤷♀️ The exception is when an emergency service authority wants to enforce access control before its <mapping> elements get distributed. That might happen, for example, when certain emergency services networks distribute internal mappings that aren't meant for public distribution 🚨
Now the spicy part 🌶️ An additional threat comes from compromised or misconfigured LoST servers. A denial of service could be the result of an injected mapping 💀 If the mapping data contains a URL that doesn't exist, then emergency services for the indicated area can't be reached. If all of the mapping data contains URLs that point to a single PSAP (rather than a large number of PSAPs), that PSAP is likely to experience overload conditions 📞 And if the mapping data contains a URL that points to a server controlled by the adversary itself, the adversary might impersonate PSAPs 😱
Section 8 discusses this security threat and mandates signed mappings. For unusual changes to the mapping database, approval by a system administrator of the emergency services infrastructure (or a similar expert) may be required before any mappings are installed. 🛑
10. IANA Considerations 📋
10.1. Media Type Registration 🎀
This specification requests the registration of a new media type according to the procedures of RFC 4288 [RFC4288] and guidelines in RFC 3023 [RFC3023] 💖 Here's the registration template, verbatim:
Type name: application
Subtype name: lostsync+xml
Required parameters: none
Optional parameters: charset
Same as charset parameter of application/xml as specified in RFC
3023 [RFC3023].
Encoding considerations: Identical to those of "application/xml" as
described in [RFC3023], Section 3.2.
Security considerations: This content type is designed to carry LoST
Synchronization protocol payloads, and the security considerations
section of RFC 6739 is applicable. In addition, as this media
type uses the "+xml" convention, it shares the same security
considerations as described in [RFC3023], Section 10.
Interoperability considerations: None
Published specification: RFC 6739
Applications that use this media type: Emergency and Location-based
Systems
Additional information:
Magic number(s): None
File extension(s): .lostsyncxml
Macintosh file type code(s): 'TEXT'
Person & email address to contact for further information:
Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Intended usage: LIMITED USE
Restrictions on usage: None
Author: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Change controller:
This specification is a work item of the IETF ECRIT working group,
with mailing list address <ecrit@ietf.org>.
Change controller:
The IESG <iesg@ietf.org>10.2. LoST Sync RELAX NG Schema Registration 🌸
The schema defined in this document has been registered under the XML schema registry at http://www.iana.org/assignments/xml-registry/schema.html ✨ Here's the entry:
URI: urn:ietf:params:xml:schema:lostsync1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
(Hannes.Tschofenig@gmx.net).
RELAX NG Schema: The RELAX NG schema that has been registered is
contained in Section 7.10.3. LoST Synchronization Namespace Registration 🧚
The namespace defined in this document has been registered under the XML namespace registry at http://www.iana.org/assignments/xml-registry/ns.html 🦋 The entry looks like this:
URI: urn:ietf:ns:xml:ns:lostsync1Wait, correcting that to match the original exactly:
URI: urn:ietf:params:xml:ns:lostsync1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
(Hannes.Tschofenig@gmx.net).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>LoST Synchronization Namespace</title>
</head>
<body>
<h1>Namespace for LoST server synchronization</h1>
<h2>urn:ietf:params:xml:ns:lostsync1</h2>
<p>See <a href="[URL of published RFC]">RFC 6739
</a>.</p>
</body>
</html>
END11. Acknowledgments 🫶
Robins George, Cullen Jennings, Karl Heinz Wolf, Richard Barnes, Mayutan Arumaithurai, Alexander Mayrhofer, and Andrew Newton provided helpful input 💜 Jari Urpalainen assisted with the RELAX NG schema 🎀 We would also like to thank our document shepherd Roger Marshall for his help with the document 🌈
We would like to particularly thank Andrew Newton for his timely and valuable review of the XML-related content ⭐
We would like to thank Robert Sparks, Barry Leiba, Stephen Farrell, Brian Haberman, Pete Resnick, and Sean Turner for their AD reviews 👑 We would also like to thank Bjoern Hoehrmann for his media type review, Julian Reschke and Martin Duerst for their applications area reviews, and Wassim Haddad for his Gen-ART review 💅
12. References 📚
12.1. Normative References 🔥
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[W3C.REC-xmldsig-core-20020212]
Eastlake, D., Reagle, J., Solo, D., Hirsch, F., and T.
Roessler, "XML-Signature Syntax and Processing", World
Wide Web Consortium, Second Edition, REC-xmldsig-core-
20020212, June 2008.12.2. Informative References 🦋
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008.
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", RFC 5582, September 2009.Authors' Addresses 🌟
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at📦 where this page comes from
- ietf: rfc6739 2012-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms