A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol
updates
Extracted elements (20)
LoST server deployment is not ubiquitous and several countries have expressed reluctance to deploy public LoST servers. No public forest guides have been deployed, threatening both device-centric and softswitch-centric emergency calling models. This extension allows a LIS to supply PSAP routing information directly, bypassing the need for LoST or forest guides.
Reusing the LoST <mapping> element for routing URIs was rejected because the mandatory 'source' attribute requires an authoritative LoST application-unique string, but there may be no authoritative LoST server in this scenario, making any value misleading. Additionally, routing information returned via HELD should not be cached, making the expiry and last-updated fields of <mapping> irrelevant.
A LIS that does not understand the routing request element ignores it and returns location information in the normal manner, providing backward compatibility with legacy HELD implementations.
This document amends RFC 6881 SP-26 such that a LoST mapping need not be requested if non-default routing information is already provided in the HELD locationResponse, avoiding a redundant LoST query.
A LIS that does support the routing request element MUST support returning URIs for urn:service:sos and any regionally defined sub-services, following the URN traversal rules in RFC 5031.
A LIS that receives a routing request it understands MUST return the correct emergency routing information if it has or is able to acquire routing information for the target device's location.
A LIS that understands the routing request but cannot obtain routing information for the end-device's location MUST set the defaultRoute attribute to 'true' and return a default PSAP or gateway URI along with the location information in the locationResponse.
If a requestor includes a specific service URN in the routing request, that service MUST exist in the IANA 'Service URN Labels' repository created by RFC 5031. If the LIS does not understand the requested service, it MUST follow the URN traversal rules defined in RFC 5031 and return URIs for urn:service:sos.
New RFC 6881 requirement ED-51a: Endpoints MUST support the HELD requestRoutingInformation element and be able to interpret and use any routing information returned in the locationResponse.
New RFC 6881 requirement ED-52a: Endpoints that acquire routing information in a HELD locationResponse SHOULD use this routing information but MAY perform a LoST findService request if they have a location value.
New RFC 6881 requirement ED-52b: Endpoints that receive routing information with defaultRoute='true' MUST perform a LoST findService request if they have a location value. If LoST provides a route it MUST be used; otherwise the HELD default routing SHOULD be used.
Routing URIs returned in the locationResponse are intended for immediate use and MUST NOT be cached by the receiving entity, to avoid the risk of stale routing information being used.
Updates to RFC 6881 (ED-23/INT-18/SP-14): when HELD is used as the Location Configuration Protocol, the request MUST include the requestRoutingInformation element. Devices and intermediaries using HELD must always include this extension.
The HELD routing extension returns URIs representing specific emergency services operating in the Target's vicinity, constituting additional information about the Target. It is therefore recommended that this option only be used when the LIS returns a location URI rather than a location value, consistent with the privacy constraints described in RFC 6155 Section 4.
The <requestRoutingInformation> element is added to the HELD <locationRequest> to signal that the requester wants the LIS to include emergency routing information in its response. It carries an optional 'service' attribute (a URN) defaulting to urn:service:sos.
The <routingInformation> element is returned in the HELD <locationResponse> when the LIS has routing information for the device's location. It contains a <service> element identified by a serviceUri URN, with one or more <dest> URIs representing PSAP or gateway destinations.
IANA registered a new XML namespace 'urn:ietf:params:xml:ns:geopriv:held:ri' for the HELD routing information extension, following the guidelines in RFC 3688.
IANA registered a new XML schema 'urn:ietf:params:xml:schema:geopriv:held:ri' for the HELD routing extension, whose content is defined in Section 6 of this document.
This document imposes no additional security considerations beyond those already described in RFC 5985 (HELD) and RFC 6155 (HELD identity extensions). Implementors should consult those documents for the applicable security requirements.
The <requestRoutingInformation> element is defined in namespace urn:ietf:params:xml:ns:geopriv:held:ri with a single optional attribute 'service' of type xs:anyUri, defaulting to urn:service:sos. The <routingInformation> element contains a <service> complex type with unbounded <dest> (xs:anyURI) children, a required 'serviceUri' (xs:anyURI) attribute, and an optional boolean 'defaultRoute' attribute (default false).