idnits 2.17.1 draft-ietf-ecrit-lost-servicelistboundary-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 6, 2010) is 5013 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT K. Wolf 3 Internet-Draft nic.at 4 Intended status: Experimental August 6, 2010 5 Expires: February 7, 2011 7 LoST Service List Boundary Extension 8 draft-ietf-ecrit-lost-servicelistboundary-04 10 Abstract 12 LoST maps service identifiers and location information to service 13 contact URIs. If a LoST client wants to discover available services 14 for a particular location, it will perform a 15 query to the LoST server. However, the LoST server, in its response, 16 does not provide context information, that is, it does not provide 17 any additional information about the geographical region for which 18 the returned list of services is considered valid within. Therefore, 19 this document proposes a Service List Boundary that returns a local 20 context along with the list of services returned, in order to assist 21 the client to not miss a change in available services when moving. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 7, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Extensions to . . . . . . . . . . 5 75 3.2. Retrieving the via 76 . . . . . . . . . . . . . . . . . 8 77 3.3. . . . . . . . . . . . . . . . . . . 9 78 3.4. Implementation Considerations . . . . . . . . . . . . . . 10 79 3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . 10 80 3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . 10 82 4. Security & Privacy Considerations . . . . . . . . . . . . . . 11 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 5.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 11 86 5.2. Namespace Registration . . . . . . . . . . . . . . . . . . 14 88 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 92 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 1. Introduction 98 Location based service providers as well as Public Safety Answering 99 Points (PSAPs) only serve a specific geographic region. Therefore 100 the LoST protocol [RFC5222] defines the Service Boundary, which 101 indicates the service region for a specific service URL. However, 102 not all services are available everywhere. Clients can discover 103 available services for a particular location by the 104 query in LoST. The LoST server returns a 105 list of services that are available at this particular location. But 106 the server does not inform the client as to the extent of coverage 107 for which geographical region the returned Service List is valid. 108 This may lead to the situation where a client initially discovers all 109 available services by the query, and then 110 moves to a different location (while refreshing the service 111 mappings), but without noticing the availability of other services. 112 The following imaginary example illustrates the problem for emergency 113 calling: 115 The client is powered-up, does location determination (resulting in 116 location A) and performs an initial query 117 with location A requesting urn:services:sos. 119 The LoST server returns the following list of services: 121 urn:service:sos.police 122 urn:service:sos.ambulance 123 urn:service:sos.fire 125 The client does the initial LoST mapping and discovers the 126 dialstrings for each service. Then the client moves, refreshing the 127 individual service mappings when necessary as told by the Service 128 Boundary. However, when arriving in location B (close to a 129 mountain), service sos.mountainrescue is available, which was not 130 available in location A. Nevertheless, the client does not detect 131 this, because only the mapping of the initially discovered services 132 (police, ambulance, fire) are refreshed. Consequently, the 133 dialstring for the mountain rescue is not known by the client. 134 Hence, the client is unable to recognize an emergency call when the 135 user enters the dialstring of the mountain rescue and thus the 136 emergency call may fail altogether. 138 Note that the Service Boundary (service region for an individual 139 service) cannot be considered as an indicator for the region a 140 specific Service List is valid for. The Service List may even change 141 within the Service Boundary of another service. For example, the 142 ambulance mapping is valid for a whole state, but for a part of the 143 state there is an additional mountain rescue service. 145 Consequently, there are two ways to tackle this issue: 146 o clients continuously poll for the Service List, although it may 147 not have changed 148 o a boundary information (telling the client that the Service List 149 does not change inside this area) 151 Since the LoST protocol employs the Service Boundary concept in order 152 to avoid having clients continuously trying to refresh the mapping of 153 a specific service, a Service List Boundary mechanism would provide 154 similar advantages for Service Lists. 156 2. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 3. LoST Extensions 164 This chapter describes the necessary extensions to the LoST protocol 165 in order to support the proposed Service List Boundary in a similar 166 way as the . Extensions defined in this document 167 are declared in the new XML namespace 168 urn:ietf:params:xml:ns:lost1:slb. 170 3.1. Extensions to 172 The query may contain an additional 173 element to additionally request the 174 boundary for the Service List based on the location provided, with 175 the resulting location for the list presented either by value or by 176 reference. In the example below the value of 'type' attribute of the 177 element is set to "value": 179 180 185 186 188 AT 189 Lower Austria 190 Bruck an der Leitha 191 Wolfsthal 192 Hauptplatz 193 1 194 2412 195 196 197 urn:service:sos 198 199 201 A with the addition of one 202 elemenents is shown below: 204 205 208 209 urn:service:sos.ambulance 210 urn:service:sos.fire 211 urn:service:sos.gas 212 urn:service:sos.mountain 213 urn:service:sos.poison 214 urn:service:sos.police 215 216 217 218 219 220 221 223 225 AT 226 Lower Austria 227 228 229 231 This response above indicates that the Service List is valid for 232 Lower Austria. The request needs to be 233 repeated by the client only when moving out of Lower Austria. 234 However, the mappings of the services itself may have other service 235 boundaries. Additionally, the 'expires' attribute indicates the 236 absolute time when this Service List becomes invalid. 238 The response MAY contain multiple elements for 239 alternative representation, each representing the boundary in a 240 specific location profile. However, multiple locations inside a 241 serviceListBoundary element are considered to be additive. 243 The boundary can also be requested by reference when setting the 244 value of the 'type' attribute of the 245 element to "reference" (which is the default in case the attribute is 246 omitted). Then the response contains a 247 element with a 'serviceListKey' 248 attribute (described in Section 3.2), as shown below. 250 251 254 255 urn:service:sos.ambulance 256 urn:service:sos.fire 257 urn:service:sos.gas 258 urn:service:sos.mountain 259 urn:service:sos.poison 260 urn:service:sos.police 261 262 263 264 265 266 267 270 272 3.2. Retrieving the via 274 In order to retrieve the boundary corresponding a specific 275 'serviceListKey', the client issues a 276 request to the server identified in the 'source' attribute of the 277 element, similar to the 278 request. 280 An example is shown below: 282 283 287 The LoST server response is shown below: 289 290 292 293 295 AT 296 Lower Austria 297 298 299 300 301 302 303 305 The 'serviceListKey' uniquely identifies a Service List Boundary as 306 the 'key' does for the Service Boundary (see Section 5.6 in RFC 307 5222). Therefore the 'serviceListKey' is a random token with at 308 least 128 bits of entropy and can be assumed globally unique. 309 Whenever the boundary changes, a new 'serviceListKey' MUST be 310 assigned. 312 Note: since LoST does not define an attribute to indicate which 313 location profile the clients understands in a 314 request, this document also does not define 315 one for the request. 317 3.3. 319 The Service List Boundary information that gets returned indicates 320 the geographic region in which all the service identifiers returned 321 from a element are the same, within a 322 query. A Service List Boundary may consist 323 of geometric shapes (both in civic and geodetic location format), and 324 may be non-contiguous, like the Service Boundary. 326 The mapping of the specific services within the Service List Boundary 327 may be different at different locations. 329 The server MAY return the boundary information in multiple location 330 profiles, but MUST use at least one profile that the client used in 331 the request in order to ensure that the client is able to process the 332 boundary information. 334 There is no need to include boundary information to a 335 . The request is purely for 336 diagnostic purposes and does not contain location information at all, 337 so no boundary information is reasonable. 339 Also note that the Service List Boundary is optional and the LoST 340 server may return it or not based on its local policy - like it is 341 the case with the Service Boundary. However, especially for 342 emergency services, the Service List Boundary might be crucial to 343 ensure that moving clients do not miss changes in the available 344 services. 346 3.4. Implementation Considerations 348 The subsections below discuss implementation issues for the LoST 349 server and client for the Service List Boundary support. 351 3.4.1. Server Side 353 The mapping architecture and framework [RFC5582] describes that each 354 tree announces its coverage region (for one type of service, e.g. 355 sos.police) to one or more forest guides. Forest guides peer with 356 each other and synchronize their data. Hence, a forest guide has 357 sufficient knowledge (it knows all the services and their coverage 358 regions) to answer a query and additionally 359 add the or as 360 well. 362 The calculation of the largest possible area for which the Service 363 List stays the same might be a complex task. An alternative would be 364 to return smaller areas that are easier to compute. In such a case 365 some unneeded queries to the LoST server are the consequence, but 366 still the main purpose of the Service List Boundary is achieved: 367 Never miss a change of available services. Thus, the server operator 368 may specify a reasonable trade-off between the effort to generate the 369 boundary information and the saved queries to the LoST server. 371 For example, in some countries the offered services may differ in 372 adjacent counties (or districts, cantons, states, ...). Their 373 borders may be suitable as Service List Boundary as well, even though 374 some adjacent counties offer the same services. 376 Other countries might have different structures and the generation of 377 the Service List Boundary might follow other rules as long as it is 378 ensured that a client is able to notice any change in the Service 379 List when moving. 381 3.4.2. Client Side 383 A mobile client that already implements LoST and evaluates the 384 has almost everything that is needed to make use of 385 the Service List Boundary. Since the integration into LoST follows 386 the concept of the (and also makes use of the same 387 location profiles), just the additional needs 388 to be evaluated. Whenever moving outside a Service List Boundary, 389 the client performs a new query with the new 390 location information in order to determine a change in available 391 services. 393 4. Security & Privacy Considerations 395 Security considerations for LoST are discussed in [RFC5222]. This 396 document extends LoST to also carry Service List Boundaries (and 397 requests for them). These Service List Boundaries are calculated by 398 the server based on the individual Service Boundaries and sent to 399 clients in case the local policy allows this. Therefore it is 400 generally considered to have the same level of sensitivity as for the 401 Service Boundary and thus the same access control and confidentiality 402 requirements as the base LoST protocol. As a result, the security 403 measures incorporated in the base LoST specification provide 404 sufficient protection for LoST messages that use the Service List 405 Boundary extension. 407 5. IANA Considerations 409 This document requests two actions by IANA: an XML schema 410 registration and namespace registration, according to the description 411 in the following sections. 413 5.1. Relax NG Schema Registration 415 This document requests registration of the following Relax NG Schema 416 to the IETF XML Registry [RFC3688]: 418 URI: urn:ietf:params:xml:schema:lost1:slb 420 Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf 421 (karlheinz.wolf@nic.at) 423 Relax NG Schema: 425 BEGIN 427 428 435 436 437 438 439 440 441 442 443 444 445 446 447 448 450 451 452 453 454 456 457 458 459 460 461 462 463 true 464 465 467 468 469 470 471 472 474 475 476 477 478 479 480 481 482 483 484 485 486 487 489 491 492 493 494 495 496 value 497 reference 498 499 reference 500 501 502 503 505 506 507 508 509 510 511 512 513 514 515 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 535 536 537 538 539 540 541 542 544 END 546 5.2. Namespace Registration 548 This document requests registration of the following namespace (below 549 the LoST namespace defined in [RFC5222]) to the IETF XML Registry 550 [RFC3688]: 552 URI: urn:ietf:params:xml:ns:lost1:slb 554 Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf 555 (karlheinz.wolf@nic.at) 557 XML: 559 BEGIN 561 562 564 565 566 568 LoST Service List Boundary Namespace 569 570 571

Namespace for the LoST Service List Boundary

572

urn:ietf:params:xml:ns:lost1:slb

573

See 574 RFCXXXX.

575 576 578 END 580 6. Acknowledgement 582 The author would like to thank Henning Schulzrinne for the discussion 583 on the draft and Martin Thomson, Richard Barnes and Roger Marshall 584 for their valuable input and text suggestions during the WGLC. 585 Further thanks go to Joshua Bell from the Applications Area Review 586 Team for his help with Relax NG. 588 7. References 590 7.1. Normative References 592 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 593 Tschofenig, "LoST: A Location-to-Service Translation 594 Protocol", RFC 5222, August 2008. 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 600 January 2004. 602 7.2. Informative References 604 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 605 Framework", RFC 5582, September 2009. 607 Author's Address 609 Karl Heinz Wolf 610 nic.at GmbH 611 Karlsplatz 1/2/9 612 Wien A-1010 613 Austria 615 Phone: +43 1 5056416 37 616 Email: karlheinz.wolf@nic.at 617 URI: http://www.nic.at/