1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 7840 Winterb Consulting Services
Updates: <a href="./rfc5985">5985</a>, <a href="./rfc6881">6881</a> H. Tschofenig
Category: Standards Track
ISSN: 2070-1721 L. Liess
Deutsche Telekom
May 2016
<span class="h1">A Routing Request Extension for</span>
<span class="h1">the HTTP-Enabled Location Delivery (HELD) Protocol</span>
Abstract
For cases where location servers have access to emergency routing
information, they are able to return routing information with the
location information if the location request includes a request for
the desired routing information. This document specifies an
extension to the HTTP-Enabled Location Delivery (HELD) protocol that
updates <a href="./rfc5985">RFC 5985</a> to support this function. Allowing location and
routing information to be acquired in a single request response
exchange updates <a href="./rfc6881">RFC 6881</a>, as current location acquisition and route
determination procedures are separate operations.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7840">http://www.rfc-editor.org/info/rfc7840</a>.
<span class="grey">Winterbottom, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. LoST Reuse Considerations . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Modification to Phone BCP . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7">7</a>. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-8">8</a>. Privacy Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-9">9</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10">10</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
10.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . <a href="#page-13">13</a>
<a href="#section-10.2">10.2</a>. XML Schema Registration . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-11">11</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-11.1">11.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-11.2">11.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<span class="grey">Winterbottom, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The general Emergency Context Resolution with Internet Technology
(ECRIT) calling models described in [<a href="./rfc6443" title=""Framework for Emergency Calling Using Internet Multimedia"">RFC6443</a>] and [<a href="./rfc6881" title=""Best Current Practice for Communications Services in Support of Emergency Calling"">RFC6881</a>] require a
local Location-to-Service Translation (LoST) server or network of
forest guides in order to determine the address of the Public Safety
Answering Point (PSAP) in the best position to handle a call.
Networks of forest guides have not materialized and while PSAPs are
moving towards IP networks, LoST server deployment is not ubiquitous.
Some regions and countries have expressed reluctance to deploy LoST
servers making aspects of the current ECRIT architecture hard to
realize.
To address regulatory requirements, such as [<a href="#ref-M493" title=""Functional architecture to support European requirements on emergency caller location determination and transport"">M493</a>], evolving
architectures in Europe couple location and routing information in
the access network while using a softswitch-centric approach to
emergency call processing. This document describes an extension to
the HELD protocol [<a href="./rfc5985" title=""HTTP-Enabled Location Delivery (HELD)"">RFC5985</a>], so that a location information server
can provide emergency routing information in the absence of a LoST
server or network of forest guides.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
The terms "Location Information Server (LIS)", "Emergency Services
Routing Proxy (ESRP)", "Voice Service Provider (VSP)", and "Public
Safety Answering Point (PSAP)" are used as defined in [<a href="./rfc6443" title=""Framework for Emergency Calling Using Internet Multimedia"">RFC6443</a>].
The term "Access Network Provider" is used as defined in [<a href="./rfc5687" title=""GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements"">RFC5687</a>]
and encompasses both the Internet Access Provider (IAP) and Internet
Service Provider (ISP).
The term "forest guide" is used as defined in [<a href="./rfc5582" title=""Location-to-URL Mapping Architecture and Framework"">RFC5582</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Motivation</span>
The Internet emergency calling architecture specified in [<a href="./rfc6881" title=""Best Current Practice for Communications Services in Support of Emergency Calling"">RFC6881</a>]
describes two main models for emergency call processing. The first
is a device-centric model, where a device obtains location
information using a location configuration protocol, such as HELD
[<a href="./rfc5985" title=""HTTP-Enabled Location Delivery (HELD)"">RFC5985</a>], and then proceeds to determine the address of the next hop
closer to the local PSAP using LoST [<a href="./rfc5222" title=""LoST: A Location-to-Service Translation Protocol"">RFC5222</a>]. Figure 1 shows this
model in a simplified form.
<span class="grey">Winterbottom, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
+---Location Request---+
| (1) |
+---+----+ +---V---+
| |<--Location--| LIS |
| Caller | (2) +-------+ +--------+
| | | ESRP/ |
| |----Find Service-------+ | PSAP |
+------^-+ (3) | +--------+
| | +--------V----+ ^
| +-----Service----| LoST Server | |
| (4) +-------------+ +---+---+
+-------------Call Initiation------------>| VSP |
(5) +-------+
Figure 1: Device-Centric Emergency Services Model
The second approach is a softswitch-centric model, where a device
initiates an emergency call, and the serving softswitch detects that
the call is an emergency and initiates retrieving the caller's
location from a LIS using HELD [<a href="./rfc5985" title=""HTTP-Enabled Location Delivery (HELD)"">RFC5985</a>] with identity extensions
[<a href="./rfc6155" title=""Use of Device Identity in HTTP-Enabled Location Delivery (HELD)"">RFC6155</a>] [<a href="./rfc6915" title=""Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)"">RFC6915</a>] and then determines the route to the local PSAP
using LoST [<a href="./rfc5222" title=""LoST: A Location-to-Service Translation Protocol"">RFC5222</a>]. Figure 2 shows the high-level protocol
interactions.
+---Location Request---+
| (2) |
+---V---+ |
| LIS | |
+----+--+ +----+----+
| | |
+----Location--->| Soft- |
+--------+ (3) | switch |
| Caller |------Call Initiation------------> | |
+--------+ (1) +-+-^---+-+
+-------------+ | | |
| LoST Server |<-Find Service--+ | |
+------+------+ (4) | |
| | |
+----------Service--------+ |
(5) |
+-----------+ |
| ESRP/PSAP |<------Call----+
+-----------+ (6)
Figure 2: Softswitch-Centric Calling Model
<span class="grey">Winterbottom, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
In the softswitch-centric model, when a VSP receives an emergency
call, it performs two tasks. The first task is to determine the
correct LIS to ask for location information; this is done using a
combination of reverse DNS lookup described in [<a href="./rfc7216" title=""Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS"">RFC7216</a>] to acquire
the serving domain name and then using [<a href="./rfc5986" title=""Discovering the Local Location Information Server (LIS)"">RFC5986</a>] to determine the LIS
URI. Once the location is obtained from the LIS, the VSP determines
the LoST server associated with the domain serving the caller and
queries it for the correct PSAP address.
LoST server discovery is a domain-based activity, similar to the LIS
discovery technique. However, unlike the LIS that is a domain-bound
service, a LoST server is a geographically bound service. This means
that for a domain that spans multiple geographic regions, the LoST
server determined may not be able to provide a route to the necessary
PSAP. When this occurs, the contacted LoST server invokes the help
of other LoST servers, and this requires the deployment of forest
guides.
At the time of writing, several countries have expressed a reluctance
to deploy public LoST servers. In countries amenable to the use of
LoST and forest guides, no public forest guides have been deployed.
There appears to be little interest from the public sector in
establishing a global forest-guide network. These issues pose
threats to the ability of both the device-centric and the softswitch-
centric calling approaches to operate everywhere.
The device-centric and softswitch-centric calling models both involve
the notion of a LIS bound to the serving access network. In many
cases, the LIS already knows the destination PSAP URI for any given
location. In [<a href="./rfc6881" title=""Best Current Practice for Communications Services in Support of Emergency Calling"">RFC6881</a>], for example, the LIS validates civic
locations using a location validation procedure based on the LoST
protocol [<a href="./rfc5222" title=""LoST: A Location-to-Service Translation Protocol"">RFC5222</a>]. The LoST validation request is similar to a LoST
routing request and provides the LIS with the same PSAP routing
information that a routing request would. In other cases, the LIS
knows the correct PSAP for a given location at provisioning time, or
the access network might always route to the same emergency provider.
Irrespective of the way in which the LIS learns the PSAP URI for a
location, the LIS will, in a great many cases, already have this
information.
This document specifies an extension to the HELD protocol, so that
emergency routing information can be requested from the LIS at the
same time that location information is requested. This document
updates [<a href="./rfc6881" title=""Best Current Practice for Communications Services in Support of Emergency Calling"">RFC6881</a>] by requiring devices and softswitches that
understand this specification to always request routing information
to avoid the risk of query failure where no LoST server or forest-
guide network is deployed.
<span class="grey">Winterbottom, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. LoST Reuse Considerations</span>
The LoST protocol [<a href="./rfc5222" title=""LoST: A Location-to-Service Translation Protocol"">RFC5222</a>] defines a <mapping> element that
describes a service region and associated service URLs. Reusing this
element from LoST to provide the routing URIs was considered.
However, this would have meant that several of the mandatory
components in the <mapping> element would have had to contain
ambiguous or misleading values. Specifically, the "source" attribute
is required to contain a LoST application-unique string for the
authoritative server. However, in the situations described in this
specification, there may not be an authoritative LoST server, so any
value put into this attribute would be misleading. In addition to
this, routing information received in the manner described in this
specification should not be cached by the receiver, so detailing when
the routing information expires or was last updated is irrelevant.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Mechanism</span>
The mechanism consists of adding an element to the HELD
locationRequest and an element to the locationResponse.
The request element indicates that the requestor wants the LIS to
provide routing information based on the location of the end device.
If the routing request is sent with no attribute, then URIs for
urn:service:sos are returned. If the requestor wants routing
information for a specific service, then they may include an optional
service URN. This service MUST exist in the IANA "Service URN
Labels" repository created by [<a href="./rfc5031" title=""A Uniform Resource Name (URN) for Emergency and Other Well-Known Services"">RFC5031</a>]. If a service is specified,
and the LIS does not understand the requested service, then URIs for
urn:service:sos are returned.
If the LIS understands the routing request and has routing
information for the location, then it includes the information in a
routingInformation element returned in the locationResponse. How the
LIS obtains this information is left to implementation.
Possibilities are described in <a href="#section-3">Section 3</a>.
A LIS that does not understand the routing request element ignores it
and returns the location information in the normal manner.
A LIS that does support the routing request element MUST support
returning URIs for urn:service:sos and any regionally defined sub-
services while following the URN traversal rules defined in
[<a href="./rfc5031" title=""A Uniform Resource Name (URN) for Emergency and Other Well-Known Services"">RFC5031</a>].
<span class="grey">Winterbottom, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
A LIS that does understand the routing request element but can't
obtain any 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 determined location information in the
locationResponse.
A LIS that understands the routing request element but not the
specified service URN MUST follow the URN traversal rules defined in
[<a href="./rfc5031" title=""A Uniform Resource Name (URN) for Emergency and Other Well-Known Services"">RFC5031</a>].
A LIS that receives a request for emergency routing information that
it understands MUST return the correct emergency routing information
if it has or is able to acquire the routing information for the
location of the target device.
The routing information in the location response consists of a
service element identified by a service name. The service name is a
URN and might contain a general emergency service URN such as
urn:service:sos or a specific service URN depending on what was
requested and what the LIS is able to provide. A list of one or more
service destinations is provided for the service name. Each
destination is expressed as a URI, and each URI scheme should only
appear once in this list. The routing URIs are intended to be used
at the time they are received. To avoid any risks of using stale
routing URIs, the values MUST NOT be cached by the receiving entity.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Modification to Phone BCP</span>
This section describes the normative updates to Phone BCP [<a href="./rfc6881" title=""Best Current Practice for Communications Services in Support of Emergency Calling"">RFC6881</a>].
It is important for devices and intermediaries to take all steps
possible to ensure that emergency calls are routed to the correct
PSAP. An alternative to providing routing information via global
forest guides or local LoST servers is for local networks to
configure the PSAP address information in the network location
server. This specification updates Phone BCP [<a href="./rfc6881" title=""Best Current Practice for Communications Services in Support of Emergency Calling"">RFC6881</a>] to provide
this option. The update requires devices and intermediaries using
the HELD protocol to always include the HELD routing extension. If
the LIS is configured with the routing information, it can provide
it; if it is not, then the device or intermediary tries LoST to
acquire the PSAP URI.
<a href="./rfc6881#section-6.5">Section 6.5 of [RFC6881]</a> defines "End System Location Configuration".
Requirement ED-23/INT-18/SP-14 is updated when HELD is used as the
Location Configuration Protocol (LCP) such that "the request MUST
include the requestRoutingInformation element." The remainder of the
requirement remains unchanged.
<span class="grey">Winterbottom, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
This document adds a new requirement to <a href="./rfc6881#section-7">Section 7 of [RFC6881]</a>.
"ED-51a : Endpoints MUST support the HELD requestRoutingInformation
element and be able to interpret and use any routing information
returned in the locationResponse."
This document adds two new requirements to <a href="./rfc6881#section-8">Section 8 of [RFC6881]</a>.
"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."
"ED-52b : Endpoints that acquire routing information in a HELD
locationResponse with a defaultRoute attribute of "true" MUST perform
a LoST findService request if they have a location value. If a route
is provided by the LoST server, then this route MUST be used,
otherwise the routing information provided in the HELD response
SHOULD be used."
This document amends SP-26 from <a href="./rfc6881#section-8">Section 8 of [RFC6881]</a> such that a
LoST mapping need not be requested if non-default routing information
is provided in the HELD locationResponse.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. HELD Schema Extension</span>
This section describes the schema extension to HELD.
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:ri"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ri="urn:ietf:params:xml:ns:geopriv:held:ri"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="requestRoutingInformation">
<xs:complexType name="empty">
<xs:attribute name="service" type="xs:anyUri"
use="optional" default="urn:service:sos"/>
</xs:complexType>
</xs:element>
<xs:complexType name="service">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<span class="grey">Winterbottom, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
<xs:sequence>
<xs:element name="dest" type="xs:anyURI"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="defaultRoute" type="xs:boolean"
use="optional" default="false"/>
<xs:attribute name="serviceUri" type="xs:anyURI"
use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="routingInformation" type="ri:riType"/>
<xs:complexType name="riType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="service" type="ri:service"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
<span class="grey">Winterbottom, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Examples</span>
Figure 3 illustrates a <locationRequest> example that contains IP
flow information in the request.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="emergencyRouting">
<requestRoutingInformation
xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"/>
<flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow"
layer4="tcp" layer3="ipv4">
<src>
<address>192.0.2.12</address>
<port>1024</port>
</src>
<dst>
<address>192.0.2.195</address>
<port>80</port>
</dst>
</flow>
</locationRequest>
Figure 3: Example Location Request
<span class="grey">Winterbottom, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
Figure 4 illustrates the <locationResponse> message containing two
location URIs: an HTTPS and a SIP URI. Additionally, the response
contains routing information.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI>
<a href="https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o">https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o</a>
</locationURI>
<locationURI>
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI>
</locationUriSet>
<routingInformation
xmlns="urn:ietf:params:xml:ns:geopriv:held:ri">
<service serviceUri="urn:service:sos">
<dest>sip:112@example.com</dest>
<dest>sips:112@example.com</dest>
<dest>xmpp:112@example.com</dest>
</service>
</routingInformation>
</locationResponse>
Figure 4: Example Location Response
<span class="grey">Winterbottom, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
Figure 5 illustrates the <locationResponse> message containing
default routing information and an HTTPS location URI.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2016-01-01T13:00:00.0Z">
<locationURI>
<a href="https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o">https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o</a>
</locationURI>
</locationUriSet>
<routingInformation
xmlns="urn:ietf:params:xml:ns:geopriv:held:ri">
<service defaultRoute="true" serviceUri="urn:service:sos">
<dest>sip:112@example.com</dest>
<dest>sips:112@example.com</dest>
<dest>xmpp:112@example.com</dest>
</service>
</routingInformation>
</locationResponse>
Figure 5: Example Location Response with Default Routing Information
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Privacy Considerations</span>
This document makes no changes that require privacy considerations
beyond those already described in [<a href="./rfc5985" title=""HTTP-Enabled Location Delivery (HELD)"">RFC5985</a>]. It does, however,
extend those described in [<a href="./rfc6155" title=""Use of Device Identity in HTTP-Enabled Location Delivery (HELD)"">RFC6155</a>].
[<a id="ref-RFC5985">RFC5985</a>] describes the privacy considerations surrounding the HELD
location configuration protocol, and this document makes no specific
changes to these considerations.
[<a id="ref-RFC6155">RFC6155</a>] extends HELD beyond a simple LCP by enabling authorized
third parties to acquire location information and describing the
issues in <a href="#section-4">Section 4</a>. The HELD routing extension supports returning
URIs that represent specific services operating in the Target's
vicinity. This represents additional information about the Target;
as a consequence, it is recommended that this option only be used
when the LIS returns a location URI, not a location value.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
This document imposes no additional security considerations beyond
those already described in [<a href="./rfc5985" title=""HTTP-Enabled Location Delivery (HELD)"">RFC5985</a>] and [<a href="./rfc6155" title=""Use of Device Identity in HTTP-Enabled Location Delivery (HELD)"">RFC6155</a>].
<span class="grey">Winterbottom, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. URN Sub-Namespace Registration for</span>
'urn:ietf:params:xml:ns:geopriv:held:ri'
Per this document, IANA has registered a new XML namespace, following
the guidelines in [<a href="./rfc3688" title=""The IETF XML Registry"">RFC3688</a>].
URI: urn:ietf:params:xml:ns:geopriv:held:ri
Registrant Contact: IETF ECRIT working group (ecrit@ietf.org),
James Winterbottom (a.james.winterbottom@gmail.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"<a href="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</a>">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Routing Information Extensions</title>
</head>
<body>
<h1>Additional Element for HELD Routing Information</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:ri</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7840.txt">
<a href="./rfc7840">RFC 7840</a></a>.</p>
</body>
</html>
END
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. XML Schema Registration</span>
This section registers an XML schema as per the procedures in
[<a href="./rfc3688" title=""The IETF XML Registry"">RFC3688</a>].
URI: urn:ietf:params:xml:schema:geopriv:held:ri
Registrant Contact: IETF ECRIT working group (ecrit@ietf.org),
James Winterbottom (a.james.winterbottom@gmail.com).
XML: The XML for this schema can be found as the entirety of
<a href="#section-6">Section 6</a> of this document.
<span class="grey">Winterbottom, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC5985">RFC5985</a>] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
<a href="./rfc5985">RFC 5985</a>, DOI 10.17487/RFC5985, September 2010,
<<a href="http://www.rfc-editor.org/info/rfc5985">http://www.rfc-editor.org/info/rfc5985</a>>.
[<a id="ref-RFC6881">RFC6881</a>] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling",
<a href="https://www.rfc-editor.org/bcp/bcp181">BCP 181</a>, <a href="./rfc6881">RFC 6881</a>, DOI 10.17487/RFC6881, March 2013,
<<a href="http://www.rfc-editor.org/info/rfc6881">http://www.rfc-editor.org/info/rfc6881</a>>.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-M493">M493</a>] European Telecommunications Standards Institute,
"Functional architecture to support European requirements
on emergency caller location determination and transport",
ES 203 178, V1.1.1, February 2015.
[<a id="ref-RFC3688">RFC3688</a>] Mealling, M., "The IETF XML Registry", <a href="https://www.rfc-editor.org/bcp/bcp81">BCP 81</a>, <a href="./rfc3688">RFC 3688</a>,
DOI 10.17487/RFC3688, January 2004,
<<a href="http://www.rfc-editor.org/info/rfc3688">http://www.rfc-editor.org/info/rfc3688</a>>.
[<a id="ref-RFC5031">RFC5031</a>] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", <a href="./rfc5031">RFC 5031</a>,
DOI 10.17487/RFC5031, January 2008,
<<a href="http://www.rfc-editor.org/info/rfc5031">http://www.rfc-editor.org/info/rfc5031</a>>.
[<a id="ref-RFC5222">RFC5222</a>] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", <a href="./rfc5222">RFC 5222</a>, DOI 10.17487/RFC5222, August 2008,
<<a href="http://www.rfc-editor.org/info/rfc5222">http://www.rfc-editor.org/info/rfc5222</a>>.
[<a id="ref-RFC5582">RFC5582</a>] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", <a href="./rfc5582">RFC 5582</a>, DOI 10.17487/RFC5582, September
2009, <<a href="http://www.rfc-editor.org/info/rfc5582">http://www.rfc-editor.org/info/rfc5582</a>>.
[<a id="ref-RFC5687">RFC5687</a>] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol: Problem Statement and
Requirements", <a href="./rfc5687">RFC 5687</a>, DOI 10.17487/RFC5687, March 2010,
<<a href="http://www.rfc-editor.org/info/rfc5687">http://www.rfc-editor.org/info/rfc5687</a>>.
<span class="grey">Winterbottom, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
[<a id="ref-RFC5986">RFC5986</a>] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", <a href="./rfc5986">RFC 5986</a>,
DOI 10.17487/RFC5986, September 2010,
<<a href="http://www.rfc-editor.org/info/rfc5986">http://www.rfc-editor.org/info/rfc5986</a>>.
[<a id="ref-RFC6155">RFC6155</a>] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)", <a href="./rfc6155">RFC 6155</a>, DOI 10.17487/RFC6155, March
2011, <<a href="http://www.rfc-editor.org/info/rfc6155">http://www.rfc-editor.org/info/rfc6155</a>>.
[<a id="ref-RFC6443">RFC6443</a>] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet
Multimedia", <a href="./rfc6443">RFC 6443</a>, DOI 10.17487/RFC6443, December
2011, <<a href="http://www.rfc-editor.org/info/rfc6443">http://www.rfc-editor.org/info/rfc6443</a>>.
[<a id="ref-RFC6915">RFC6915</a>] Bellis, R., "Flow Identity Extension for HTTP-Enabled
Location Delivery (HELD)", <a href="./rfc6915">RFC 6915</a>, DOI 10.17487/RFC6915,
April 2013, <<a href="http://www.rfc-editor.org/info/rfc6915">http://www.rfc-editor.org/info/rfc6915</a>>.
[<a id="ref-RFC7216">RFC7216</a>] Thomson, M. and R. Bellis, "Location Information Server
(LIS) Discovery Using IP Addresses and Reverse DNS",
<a href="./rfc7216">RFC 7216</a>, DOI 10.17487/RFC7216, April 2014,
<<a href="http://www.rfc-editor.org/info/rfc7216">http://www.rfc-editor.org/info/rfc7216</a>>.
Acknowledgements
We would like to thank Wilfried Lange for sharing his views with us.
We would also like to thank Bruno Chatras for his early review
comments and Keith Drage for his more detailed review. Thanks to
Roger Marshall and Randy Gellens for their helpful suggestions.
<span class="grey">Winterbottom, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7840">RFC 7840</a> HELD Routing May 2016</span>
Authors' Addresses
James Winterbottom
Winterb Consulting Services
Gwynneville, NSW 2500
Australia
Phone: +61 448 266004
Email: a.james.winterbottom@gmail.com
Hannes Tschofenig
Hall in Tirol 6060
Austria
Email: Hannes.Tschofenig@gmx.net
URI: <a href="http://www.tschofenig.priv.at">http://www.tschofenig.priv.at</a>
Laura Liess
Deutsche Telekom Networks
Deutsche Telekom Allee 7
Darmstadt, Hessen 64295
Germany
Email: L.Liess@telekom.de
URI: <a href="http://www.telekom.de">http://www.telekom.de</a>
Winterbottom, et al. Standards Track [Page 16]
</pre>
|
