idnits 2.17.1 draft-ietf-ecrit-lost-servicelistboundary-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (February 26, 2010) is 5173 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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 February 26, 2010 5 Expires: August 30, 2010 7 LoST Service List Boundary Extension 8 draft-ietf-ecrit-lost-servicelistboundary-03 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 element that returns a 20 local context along with the list of services returned, in order to 21 assist the client to not miss a change in available services when 22 moving. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on August 30, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 80 3.1. Extensions to . . . . . . . . . . 5 81 3.2. Retrieving the via 82 . . . . . . . . . . . . . . . . . 8 83 3.3. . . . . . . . . . . . . . . . . . . 9 84 3.4. Implementation Considerations . . . . . . . . . . . . . . 10 85 3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . 10 86 3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . 11 88 4. Security & Privacy Considerations . . . . . . . . . . . . . . 11 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 91 5.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 11 92 5.2. Namespace Registration . . . . . . . . . . . . . . . . . . 13 94 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 97 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 98 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 102 1. Introduction 104 Location based service providers as well as Public Safety Answering 105 Points (PSAPs) only serve a specific geographic region. Therefore 106 the LoST protocol [RFC5222] defines the Service Boundary, which 107 indicates the service region for a specific service URL. However, 108 not all services are available everywhere. Clients can discover 109 available services for a particular location by the 110 query in LoST. The LoST server returns a 111 list of services that are available at this particular location. But 112 the server does not inform the client as to the extent of coverage 113 for which geographical region the returned Service List is valid. 114 This may lead to the situation where a client initially discovers all 115 available services by the query, and then 116 moves to a different location (while refreshing the service 117 mappings), but without noticing the availability of other services. 118 The following imaginary example illustrates the problem for emergency 119 calling: 121 The client is powered-up, does location determination (resulting in 122 location A) and performs an initial query 123 with location A requesting urn:services:sos. 125 The LoST server returns the following list of services: 127 urn:service:sos.police 128 urn:service:sos.ambulance 129 urn:service:sos.fire 131 The client does the initial LoST mapping and discovers the 132 dialstrings for each service. Then the client moves, refreshing the 133 individual service mappings when necessary as told by the Service 134 Boundary. However, when arriving in location B (close to a 135 mountain), service sos.mountainrescue is available, which was not 136 available in location A. Nevertheless, the client does not detect 137 this, because only the mapping of the initially discovered services 138 (police, ambulance, fire) are refreshed. Consequently, the 139 dialstring for the mountain rescue is not known by the client. 140 Hence, the client is unable to recognize an emergency call when the 141 user enters the dialstring of the mountain rescue and thus the 142 emergency call may fail altogether. 144 Note that the Service Boundary (service region for an individual 145 service) cannot be considered as an indicator for the region a 146 specific Service List is valid for. The Service List may even change 147 within the Service Boundary of another service. For example, the 148 ambulance mapping is valid for a whole state, but for a part of the 149 state there is an additional mountain rescue service. 151 Consequently, there are two ways to tackle this issue: 152 o clients continuously ask for the Service List, although it may not 153 have changed 154 o a boundary information (telling the client that the Service List 155 does not change inside this area) 157 Since the LoST protocol employs the Service Boundary concept in order 158 to avoid having clients continuously trying to refresh the mapping of 159 a specific service, a Service List Boundary mechanism would provide 160 similar advantages for Service Lists. 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 3. LoST Extensions 170 This chapter describes the necessary modifications to the LoST 171 protocol in order to support the proposed in a 172 similar way as the . 174 3.1. Extensions to 176 The query may contain an additional 177 element to additionally request the 178 boundary for the service list based on the location provided, with 179 the resulting location for the list to be presented either in a by 180 value or by reference form. In the example below the value of the 181 element is set to "value": 183 184 189 190 192 AT 193 Lower Austria 194 Bruck an der Leitha 195 Wolfsthal 196 Hauptplatz 197 1 198 2412 199 200 201 urn:service:sos 202 203 value 204 205 207 A possible response is shown below: 209 210 212 xmlns:slb="urn:ietf:params:xml:schema:lost1:slb" 213 214 urn:service:sos.ambulance 215 urn:service:sos.fire 216 urn:service:sos.gas 217 urn:service:sos.mountain 218 urn:service:sos.poison 219 urn:service:sos.police 220 221 222 223 224 225 226 227 229 AT 230 Lower Austria 231 232 233 235 This response above indicates that the Service List is valid for 236 Lower Austria. The request has to be 237 repeated by the client only when moving out of Lower Austria. 238 However, the mappings of the services itself may have other service 239 boundaries. Additionally, the expires attribute indicates the 240 absolute time when this Service List becomes invalid. 242 The boundary can also be requested by reference when setting the 243 value of the element to "reference". 244 Then the response contains a element, 245 as shown below. 247 248 250 xmlns:slb="urn:ietf:params:xml:schema:lost1:slb" 251 252 urn:service:sos.ambulance 253 urn:service:sos.fire 254 urn:service:sos.gas 255 urn:service:sos.mountain 256 urn:service:sos.poison 257 urn:service:sos.police 258 259 260 261 262 263 264 267 269 3.2. Retrieving the via 271 In order to retrieve the boundary corresponding a specific 272 'serviceListKey', the client issues a 273 request to the server identified in the 'source' attribute of the 274 element, similar to the 275 request. 277 An example is shown below: 279 280 283 The LoST server response is shown below: 285 286 288 290 292 AT 293 Lower Austria 294 295 296 297 298 299 300 302 The 'serviceListKey' uniquely identifies a Service List Boundary as 303 the 'key' does for the service boundary (see Section 5.6 in RFC 304 5222). Therefore the 'serviceListKey' is a random token with at 305 least 128 bits of entropy and can be assumed globally unique. 306 Whenever the boundary changes, a new 'serviceListKey' MUST be 307 assigned. 309 Note: since LoST does not define an attribute to indicate which 310 profile the clients understands in a 311 request, this document also does not define one for the 312 request. 314 3.3. 316 The information that gets returned, indicates 317 the geographic region in which all the service identifiers returned 318 from a element are the same, within a 319 query. A may consist 320 of geometric shapes (both in civic and geodetic location format), and 321 may be non-contiguous, like the Service Boundary. 323 The mapping of the specific services within the Service List Boundary 324 may be different at different locations. 326 The server may return the boundary information in multiple profiles, 327 but has to use at least one profile that the client used in the 328 request in order to ensure that the client is able to process the 329 boundary information. 331 There is no need to include boundary information to a 332 . requests are purely for 333 diagnostic purposes and do not contain location information at all, 334 so no boundary information is reasonable. 336 Also note that the is optional and the LoST 337 server may return it or not based on its local policy - like it is 338 the case with the Service Boundary. However, especially for 339 emergency services, the might be crucial to 340 ensure that moving clients do not miss changes in the available 341 services. 343 3.4. Implementation Considerations 345 The subsections below discuss implementation issues for the LoST 346 server and client for the serviceListBoundary support. 348 3.4.1. Server Side 350 The mapping architecture and framework [RFC5582] describes that each 351 tree announces its coverage region (for one type of service, e.g. 352 sos.police) to one or more forest guides. Forest guides peer with 353 each other and synchronize their data. Hence, a forest guide has 354 sufficient knowledge (it knows all the services and their coverage 355 regions) to answer a query and additionally 356 add the as well. 358 The calculation of the largest possible area for which the Service 359 List stays the same might be a complex task. An alternative would be 360 to return smaller areas that are easier to compute. In such a case 361 some unneeded queries to the LoST server are the consequence, but 362 still the main purpose of the is achieved: 363 Never miss a change of available services. So a reasonable trade-off 364 between the effort to generate the boundary information and the saved 365 queries to the LoST server has to be considered. 367 Probably for some countries the county (or disrict, canton, state, 368 ...) borders would be suitable as . Some 369 neighbouring counties may have implemented different services while a 370 query in other neighbouring counties still 371 results in the same Service List. So when moving across a county 372 border, it is at least ensured, that every device fetches a new 373 Service List from the LoST server. 375 Other countries might have different structures and the generation of 376 the might follow other rules as long as it is 377 ensured that a client is able to notice any change in the Service 378 List when moving. 380 3.4.2. Client Side 382 A mobile client that already implements LoST and evaluates the 383 has almost everything that is needed to make use of 384 the . Since the integration into LoST follows 385 the concept of the (and also makes use of the same 386 location profiles), just the additional has to 387 be evaluated. Whenever moving outside a , the 388 client must perform a new query with the new 389 location information in order to determine a change in available 390 services. 392 4. Security & Privacy Considerations 394 Security considerations for LoST are discussed in [RFC5222]. This 395 document extends LoST to also carry Service List Boundaries (and 396 requests for them). These Service List Boundaries are calculated by 397 the server based on the individual Service Boundaries and sent to 398 clients in case the local policy allows this. Therefore it is 399 generally considered to have the same level of sensitivity as for the 400 Service Boundary and thus the same access control and confidentiality 401 requirements as the base LoST protocol. As a result, the security 402 measures incorporated in the base LoST specification provide 403 sufficient protection for LoST messages that use the Service List 404 Boundary extension. 406 5. IANA Considerations 408 This document requests two actions by IANA: a XML schema registration 409 and namespace registration, according to the description in the 410 following sections. 412 5.1. Relax NG Schema Registration 414 This document requests registration of the following Relax NG Schema 415 to the IETF XML Registry [RFC3688]: 417 URI: urn:ietf:params:xml:schema:lost1:slb 419 Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf 420 (karlheinz.wolf@nic.at) 422 Relax NG Schema: 424 BEGIN 425 426 429 430 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 449 450 451 452 453 454 456 457 458 459 460 461 462 463 464 465 466 468 470 471 472 473 474 value 475 reference 476 477 478 480 481 482 483 484 485 486 488 489 490 491 492 493 494 496 497 498 499 500 501 503 504 505 506 507 508 509 510 512 513 END 515 5.2. Namespace Registration 517 This document requests registration of the following namespace (below 518 the LoST namespace defined in [RFC5222]) to the IETF XML Registry 519 [RFC3688]: 521 URI: urn:ietf:params:xml:ns:lost1:slb 523 Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf 524 (karlheinz.wolf@nic.at) 526 XML: 528 BEGIN 530 531 533 534 535 537 LoST serviceListBoundary Namespace 538 539 540

Namespace for the LoST Service List Boundary

541

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

542

See 543 RFCXXXX.

544 545 547 END 549 6. Acknowledgement 551 The author would like to thank Henning Schulzrinne for the discussion 552 on the draft and Martin Thomson, Richard Barnes and Roger Marshall 553 for their valuable input and text suggestions during the WGLC. 555 7. References 557 7.1. Normative References 559 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 560 Tschofenig, "LoST: A Location-to-Service Translation 561 Protocol", RFC 5222, August 2008. 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, March 1997. 566 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 567 January 2004. 569 7.2. Informative References 571 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 572 Framework", RFC 5582, September 2009. 574 Author's Address 576 Karl Heinz Wolf 577 nic.at GmbH 578 Karlsplatz 1/2/9 579 Wien A-1010 580 Austria 582 Phone: +43 1 5056416 37 583 Email: karlheinz.wolf@nic.at 584 URI: http://www.nic.at/