RFC 6197

Location-to-Service Translation (LoST) Service List Boundary Extension

📅 published April 2011, from ietf

Location-to-Service Translation (LoST) Service List Boundary Extension 🎀

bestie, this is RFC 6197 🦋 It's from the Internet Engineering Task Force (IETF), and here's the title-block tea ☕

Author: K. Wolf, from nic.at
Category: Experimental
Date: April 2011
ISSN: 2070-1721
Obsoletes / Updates: the title block doesn't list any RFCs that it obsoletes or updates

Abstract 💌

okay so LoST (Location-to-Service Translation) maps service identifiers and location info to service contact URIs 🗺️ If a LoST client wants to find out which services are available at a certain location, it sends a <listServicesByLocation> query to the LoST server. The problem? The server's response doesn't tell the client anything about the geographic region where that list is valid 🙈 So this document defines a Service List Boundary, which sends back a local context along with the list of services. That way the client doesn't miss a change in available services when it moves around 💖

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧪

This document defines an Experimental Protocol for the Internet community. It's a product of the IETF and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for more on that 💅

For the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6197 ✨

Copyright Notice ⚖️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as in effect on the date this document was published (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.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications of it outside the IETF Standards Process. Unless you get an adequate license from the person(s) controlling the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🌈

Table of Contents 🗂️

   1. Introduction ....................................................3
   2. Terminology .....................................................4
   3. LoST Extensions .................................................4
      3.1. Extensions to <listServicesByLocation> .....................4
      3.2. Retrieving the <serviceListBoundary> via
           <getServiceListBoundary> ...................................7
      3.3. <serviceListBoundary> ......................................8
      3.4. Implementation Considerations ..............................9
           3.4.1. Server Side .........................................9
           3.4.2. Client Side .........................................9
   4. Security and Privacy Considerations ............................10
   5. IANA Considerations ............................................10
      5.1. Relax NG Schema Registration ..............................10
      5.2. Namespace Registration ....................................13
   6. Acknowledgements ...............................................14
   7. References .....................................................14
      7.1. Normative References ......................................14
      7.2. Informative References ....................................15

1. Introduction 🌸

okay so the LoST protocol [RFC5222] already uses the Service Boundary idea so clients don't keep re-checking the mapping for one specific service. A Service List Boundary gives Service Lists the same perks ✨

Location-based service providers, and also Public Safety Answering Points (PSAPs), only serve a specific geographic region 📍 That's why LoST defines the Service Boundary, which tells you the service region for a specific service URL. The catch is that not every service is available everywhere 😬 Clients can find out which services are available for a particular location with the <listServicesByLocation> query in LoST. The server sends back a list of services available at that spot, but it doesn't say anything about the geographic region where that Service List is valid. So a client might grab every available service with <listServicesByLocation>, then move somewhere else (while refreshing the service mappings) and never notice that new services showed up 💀 Here's an imaginary emergency-calling example to show the problem:

The client powers up, does location determination (getting location A), and makes an initial <listServicesByLocation> query for location A, asking for urn:services:sos.

The LoST server sends back this list of services:

urn:service:sos.police
urn:service:sos.ambulance
urn:service:sos.fire

The client does the initial LoST mapping and gets the dialstrings for each service. Then it moves around, refreshing the individual service mappings when needed as the Service Boundary says to. But when it arrives at location B (close to a mountain), the service sos.mountainrescue, which wasn't available at location A, becomes available 🏔️ The client only has to refresh the mappings for the services it found at the start, so it never detects the new one. That means the client doesn't know the dialstring for mountain rescue. So when the user dials the mountain-rescue dialstring, the client can't recognize it as an emergency call, and the emergency call may fail altogether 😭

A quick note: the Service Boundary (the service region for one individual service) can't be treated as the region where a specific Service List is valid. The Service List can change even inside another service's Service Boundary. For example, the ambulance mapping is valid for a whole state, but in one part of that state there's an extra mountain-rescue service 🚑

So there are two ways to deal with this:

Clients keep polling for the Service List, even though it may not have changed.
The server sends a message containing boundary information that tells the client the Service List doesn't change inside this area.

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]. Those are the official rules-words, so read them carefully 📖

3. LoST Extensions 🧚

This section describes the extensions to the LoST protocol that are needed to support the Service List Boundary in a similar way to the Service Boundary 🦋 Extensions defined in this document are declared in the new XML namespace urn:ietf:params:xml:ns:lost1:slb.

3.1. Extensions to `<listServicesByLocation>` ✨

okay so the <listServicesByLocation> query can carry an extra <serviceListBoundaryRequest> element 🎀. that's how you ask for the boundary of the Service List for whatever location you sent, and you can get it back either by value or by reference 💅. in this example the type attribute of <serviceListBoundaryRequest> is set to "value" 🦋:

   <?xml version="1.0" encoding="UTF-8"?>
   <listServicesByLocation
        xmlns="urn:ietf:params:xml:ns:lost1"
        xmlns:gml="http://www.opengis.net/gml"
        xmlns:slb="urn:ietf:params:xml:ns:lost1:slb"
        recursive="true">
     <location id="5415203asdf548" profile="civic">
       <civicAddress xml:lang="en"
          xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
         <country>AT</country>
         <A1>Lower Austria</A1>
         <A2>Bruck an der Leitha</A2>
         <A3>Wolfsthal</A3>
         <RD>Hauptplatz</RD>
         <HNO>1</HNO>
         <PC>2412</PC>
       </civicAddress>
     </location>
     <service>urn:service:sos</service>
     <slb:serviceListBoundaryRequest type="value"/>
   </listServicesByLocation>

the response then has one extra <serviceListBoundary> element tucked in 🌸. look at this glow-up:

  <?xml version="1.0" encoding="UTF-8"?>
  <listServicesByLocationResponse
        xmlns="urn:ietf:params:xml:ns:lost1"
        xmlns:slb="urn:ietf:params:xml:ns:lost1:slb">
    <serviceList>
       urn:service:sos.ambulance
       urn:service:sos.fire
       urn:service:sos.gas
       urn:service:sos.mountain
       urn:service:sos.poison
       urn:service:sos.police
    </serviceList>
    <path>
      <via source="resolver.example"/>
      <via source="authoritative.example"/>
    </path>
      <locationUsed id="5415203asdf548"/>
      <slb:serviceListBoundary profile="civic"
         expires="2012-01-01T00:00:00Z">
        <civicAddress xml:lang="en"
           xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
          <country>AT</country>
          <A1>Lower Austria</A1>
        </civicAddress>
      </slb:serviceListBoundary>
  </listServicesByLocationResponse>

so this response is saying the Service List is valid for Lower Austria 🏞️. the client only needs to send that <listServicesByLocation> request again when it leaves Lower Austria 🚗💨. the actual services can still have their own service boundaries though, so don't get too comfy 👀. and the expires attribute tells you the exact absolute time when this Service List stops being valid ⏰.

the response MAY contain multiple <serviceListBoundary> elements for alternative representation 🌈, each one describing the boundary in a specific location profile. just know that multiple locations inside a single <serviceListBoundary> element are considered to be additive ➕.

you can also ask for the boundary by reference, by setting the type attribute of <serviceListBoundaryRequest> to "reference" 🔗. that's the default if you leave the attribute out, btw 🙈. the response then carries a <serviceListBoundaryReference> element with a serviceListKey attribute (more on that in Section 3.2), like this:

   <?xml version="1.0" encoding="UTF-8"?>
   <listServicesByLocationResponse
         xmlns="urn:ietf:params:xml:ns:lost1"
         xmlns:slb="urn:ietf:params:xml:ns:lost1:slb">
     <serviceList>
        urn:service:sos.ambulance
        urn:service:sos.fire
        urn:service:sos.gas
        urn:service:sos.mountain
        urn:service:sos.poison
        urn:service:sos.police
      </serviceList>
      <path>
        <via source="resolver.example"/>
        <via source="authoritative.example"/>
      </path>
      <locationUsed id="5415203asdf548"/>
      <slb:serviceListBoundaryReference
         source="authoritative.example"
         serviceListKey="123567890123567890123567890" />
   </listServicesByLocationResponse>

3.2. Retrieving the `<serviceListBoundary>` via `<getServiceListBoundary>` 🧚

to get the boundary that goes with a specific serviceListKey, the client sends a <getServiceListBoundary> request to the server named in the source attribute of the <serviceListBoundaryReference> element 📮. it works a lot like the <getServiceBoundary> request, so if you know that one you're already halfway there 💖.

here's what it looks like:

   <?xml version="1.0" encoding="UTF-8"?>
   <getServiceListBoundary
         xmlns="urn:ietf:params:xml:ns:lost1:slb"
           serviceListKey="123567890123567890123567890"/>

and this is the LoST server's answer 💌:

 <?xml version="1.0" encoding="UTF-8"?>
 <getServiceListBoundaryResponse
       xmlns="urn:ietf:params:xml:ns:lost1:slb">
   <serviceListBoundary profile="civic" expires="2012-01-01T00:00:00Z">
     <civicAddress xml:lang="en"
         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
       <country>AT</country>
       <A1>Lower Austria</A1>
     </civicAddress>
   </serviceListBoundary>
   <path xmlns="urn:ietf:params:xml:ns:lost1">
     <via source="resolver.example"/>
     <via source="authoritative.example"/>
   </path>
 </getServiceListBoundaryResponse>

so the serviceListKey uniquely identifies a Service List Boundary, the same way the key does for a Service Boundary (see Section 5.6 of RFC 5222) 🔑. the serviceListKey is a random token with at least 128 bits of entropy [RFC4086], and it can be assumed to be globally unique 🌍. but here's the important bit: whenever the boundary changes, a new serviceListKey MUST be assigned 🚨.

Note: Since LoST does not define an attribute to indicate which location profile the client understands in a <getServiceBoundary> request, this document also does not define one for the <getServiceListBoundary> request. 🙃

3.3. `<serviceListBoundary>` 🗺️

for a particular <listServicesByLocation> query, the Service List Boundary info that comes back tells you that every service identifier in the <serviceList> element is the same inside this geographic region 💜. a Service List Boundary can be made of geometric shapes (in civic and geodetic location format both), and it can be non-contiguous, just like the Service Boundary 🧩.

the mapping of the specific services inside the Service List Boundary may still be different at different locations 👀.

the server MAY return the boundary information in multiple location profiles, but it MUST use at least one profile that the client used in the request 🫶. that's how the client can be sure it can actually process the boundary info.

there's no need to put boundary information in a <listServicesResponse> 🙅‍♀️. the <listServices> request is purely for diagnostic purposes and doesn't contain any location information at all, so there's no boundary to calculate.

also, the Service List Boundary is OPTIONAL 🤷‍♀️, and the LoST server may or may not return it, based on its local policy, the same as with the Service Boundary. but honestly, especially for emergency services, the Service List Boundary might be crucial so that moving clients don't miss changes in the available services 🚑🚒.

3.4. Implementation Considerations 🛠️

the subsections below talk about implementation issues for the LoST server and client when it comes to Service List Boundary support 🎀.

3.4.1. Server Side 🖥️

the mapping architecture and framework [RFC5582] says that each tree announces its coverage region (for one type of service, e.g., sos.police) to one or more forest guides 🌳. forest guides peer with each other and sync their data. so a forest guide knows everything (all the services and their coverage regions), which means it has enough info to answer a <listServicesByLocation> query and to add the <serviceListBoundary> or <serviceListBoundaryReference> too 💅.

working out the largest possible area where the Service List stays the same might be a seriously complex task 😵‍💫. an alternative is to return smaller areas that are easier to compute. the downside is that some unnecessary queries to the LoST server will happen, but the main purpose of the Service List Boundary is still achieved: never missing a change of available services ✅. so the server operator can pick a reasonable trade-off between the effort to generate the boundary info and the queries saved on the LoST server ⚖️.

for example, in some countries the offered services may differ in adjacent counties (or districts, cantons, states, etc.) 🏘️. their borders may be suitable as a Service List Boundary too, even though some adjacent counties offer the same services.

other countries might have different structures, and the Service List Boundary can be generated by other rules too, as long as the client can notice any change in the Service List when it moves 🧭.

3.4.2. Client Side 📱

a mobile client that already implements LoST and evaluates the <serviceBoundary> has almost everything it needs to use the Service List Boundary 🥹. because the integration into LoST follows the concept of the <serviceBoundary> (and uses the same location profiles too), only the extra <serviceListBoundary> needs to be evaluated. whenever the client moves outside a Service List Boundary, it does a new <listServicesByLocation> query with the new location information to figure out whether the available services changed 🔄.

4. Security and Privacy Considerations 🔐

security considerations for LoST are covered in [RFC5222] 🛡️. this document extends LoST to also carry Service List Boundaries (and requests for them). these boundaries are calculated by the server from the individual Service Boundaries and sent to clients when local policy allows it 📍. so they're generally treated as having the same level of sensitivity as Service Boundaries, and therefore the same access control and confidentiality requirements as the base LoST protocol 🔒. as a result, the security measures built into the base LoST specification [RFC5222] are considered to provide sufficient protection for LoST messages that use the Service List Boundary extension 💀✨.

5. IANA Considerations 📋

IANA has taken two actions: an XML schema registration and a namespace registration, according to the description in the following sections 🦋.

5.1. Relax NG Schema Registration 📜✨

IANA registered this Relax NG Schema in the IETF XML Registry [RFC3688], and the registrant is the IETF ECRIT Working Group plus Karl Heinz Wolf (karlheinz.wolf@nic.at). It's giving "schema drop" 💅

The URI for it is urn:ietf:params:xml:schema:lost1:slb.

BEGIN

<?xml version="1.0" encoding="UTF-8"?>
<grammar
    xmlns="http://relaxng.org/ns/structure/1.0"
    xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
    xmlns:slb="urn:ietf:params:xml:ns:lost1:slb"
    ns="urn:ietf:params:xml:ns:lost1"
    datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
  <include href="lost.rng">
  <!-- redefinition of LoST elements -->
    <start>
      <choice>
        <ref name="findService"/>
        <ref name="listServices"/>
        <ref name="listServicesByLocation"/>
        <ref name="getServiceBoundary"/>
        <ref name="findServiceResponse"/>
        <ref name="listServicesResponse"/>
        <ref name="listServicesByLocationResponse"/>
        <ref name="getServiceBoundaryResponse"/>
        <ref name="errors"/>
        <ref name="redirect"/>

        <!-- New in RFC 6197 -->
        <ref name="getServiceListBoundary"/>
        <ref name="getServiceListBoundaryResponse"/>
      </choice>
    </start>

    <define name="listServicesByLocation">
      <element name="listServicesByLocation">
        <ref name="requestLocation"/>
        <ref name="commonRequestPattern"/>
        <optional>
          <attribute name="recursive">
            <data type="boolean"/>
            <a:defaultValue>true</a:defaultValue>
          </attribute>
        </optional>

        <!-- New in RFC 6197 -->
        <optional>
          <ref name="serviceListBoundaryRequest"/>
        </optional>
      </element>
    </define>

    <define name="listServicesByLocationResponse">
      <element name="listServicesByLocationResponse">
        <ref name="serviceList"/>
        <ref name="commonResponsePattern"/>
        <ref name="locationUsed"/>
        <!-- New in RFC 6197 -->
        <optional>
          <choice>
            <ref name="serviceListBoundary"/>
            <ref name="serviceListBoundaryReference"/>
          </choice>
        </optional>
      </element>
    </define>
  </include>

  <define name="serviceListBoundaryRequest">
    <element name="slb:serviceListBoundaryRequest">
      <optional>
        <attribute name="type">
          <choice>
            <value>value</value>
            <value>reference</value>
          </choice>
          <a:defaultValue>reference</a:defaultValue>
        </attribute>
      </optional>
    </element>
  </define>

  <define name="serviceListBoundary">
   <oneOrMore>
    <element name="slb:serviceListBoundary">
      <optional>
        <ref name="expires"/>
      </optional>
      <ref name="locationInformation"/>
      <ref name="extensionPoint"/>
    </element>
   </oneOrMore>
  </define>

  <define name="serviceListBoundaryReference">
    <element name="slb:serviceListBoundaryReference">
      <ref name="source"/>
      <attribute name="serviceListKey">
        <data type="token"/>
      </attribute>
    <ref name="extensionPoint"/>
    </element>
  </define>
  <define name="getServiceListBoundary">
    <element name="slb:getServiceListBoundary">
      <attribute name="serviceListKey">
        <data type="token"/>
      </attribute>
    <ref name="extensionPoint"/>
    </element>
  </define>

  <define name="getServiceListBoundaryResponse">
    <element name="slb:getServiceListBoundaryResponse">
     <ref name="serviceListBoundary"/>
     <ref name="path"/>
     <ref name="extensionPoint"/>
    </element>
  </define>
</grammar>

END

5.2. Namespace Registration 🎀

IANA also registered a namespace under the LoST namespace defined in [RFC5222], again in the IETF XML Registry [RFC3688]. The URI is urn:ietf:params:xml:ns:lost1:slb, and the registrant is, you guessed it, the IETF ECRIT Working Group plus Karl Heinz Wolf (karlheinz.wolf@nic.at). 🦋

Here's the XML for it: