idnits 2.17.1 draft-ietf-ecrit-lost-servicelistboundary-02.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 9, 2010) is 5161 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5582 Summary: 3 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 Expires: August 13, 2010 February 9, 2010 6 Location-to-Service Translation Protocol (LoST) Extension: 7 8 draft-ietf-ecrit-lost-servicelistboundary-02 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 13, 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 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Extensions to . . . . . . . . . . 4 69 3.2. Retrieving the via 70 . . . . . . . . . . . . . . . . . 6 71 3.3. . . . . . . . . . . . . . . . . . . 7 72 3.4. Implementation Considerations . . . . . . . . . . . . . . 8 73 3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . 8 74 3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . 9 76 4. Security & Privacy Considerations . . . . . . . . . . . . . . 9 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 5.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 9 80 5.2. Namespace Registration . . . . . . . . . . . . . . . . . . 12 82 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 84 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 Location based service providers as well as Public Safety Answering 91 Points (PSAPs) only serve a specific geographic region. Therefore 92 the LoST protocol [RFC5222] defines the Service Boundary, which 93 indicates the service region for a specific service URL. However, 94 not all services are available everywhere. Clients can discover 95 available services for a particular location by the 96 query in LoST. The LoST server returns a 97 list of services that are available at this particular location. But 98 the server does not inform the client as to the extent of coverage 99 for which geographical region the returned Service List is valid. 100 This may lead to the situation where a client initially discovers all 101 available services by the query, and then 102 moves to a different location (while refreshing the service 103 mappings), but without noticing the availability of other services. 104 The following imaginary example illustrates the problem for emergency 105 calling: 107 The client is powered-up, does location determination (resulting in 108 location A) and performs an initial query 109 with location A requesting urn:services:sos. 111 The LoST server returns the following list of services: 113 urn:service:sos.police 114 urn:service:sos.ambulance 115 urn:service:sos.fire 117 The client does the initial LoST mapping and discovers the 118 dialstrings for each service. Then the client moves, refreshing the 119 individual service mappings when necessary as told by the Service 120 Boundary. However, when arriving in location B (close to a 121 mountain), service sos.mountainrescue is available, which was not 122 available in location A. Nevertheless, the client does not detect 123 this, because only the mapping of the initially discovered services 124 (police, ambulance, fire) are refreshed. Consequently, the 125 dialstring for the mountain rescue is not known by the client. 126 Hence, the client is unable to recognize an emergency call when the 127 user enters the dialstring of the mountain rescue and thus the 128 emergency call may fail altogether. 130 Note that the Service Boundary (service region for an individual 131 service) cannot be considered as an indicator for the region a 132 specific Service List is valid for. The Service List may even change 133 within the Service Boundary of another service. For example, the 134 ambulance mapping is valid for a whole state, but for a part of the 135 state there is an additional mountain rescue service. 137 Consequently, there are two ways to tackle this issue: 138 o clients continuously ask for the Service List, although it may not 139 have changed 140 o a boundary information (telling the client that the Service List 141 does not change inside this area) 143 Since the LoST protocol employs the Service Boundary concept in order 144 to avoid having clients continuously trying to refresh the mapping of 145 a specific service, a Service List Boundary mechanism would provide 146 similar advantages for Service Lists. 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 3. LoST Extensions 156 This chapter describes the necessary modifications to the LoST 157 protocol in order to support the proposed in a 158 similar way as the . 160 3.1. Extensions to 162 The query may contain an additional 163 element to additionally request the 164 boundary for the service list based on the location provided, with 165 the resulting location for the list to be presented either in a by 166 value or by reference form. In the example below the value of the 167 element is set to "value": 169 170 175 176 178 AT 179 Lower Austria 180 Bruck an der Leitha 181 Wolfsthal 182 Hauptplatz 183 1 184 2412 185 186 187 urn:service:sos 188 value 189 191 A possible response is shown below: 193 194 196 xmlns:slb="urn:ietf:params:xml:schema:lost1:slb" 197 198 urn:service:sos.ambulance 199 urn:service:sos.fire 200 urn:service:sos.gas 201 urn:service:sos.mountain 202 urn:service:sos.poison 203 urn:service:sos.police 204 205 206 207 208 209 210 211 213 AT 214 Lower Austria 215 216 218 220 This response above indicates that the Service List is valid for 221 Lower Austria. The request has to be 222 repeated by the client only when moving out of Lower Austria. 223 However, the mappings of the services itself may have other service 224 boundaries. Additionally, the expires attribute indicates the 225 absolute time when this Service List becomes invalid. 227 The boundary can also be requested by reference when setting the 228 value of the element to "reference". 229 Then the response contains a element, 230 as shown below. 232 233 235 xmlns:slb="urn:ietf:params:xml:schema:lost1:slb" 236 237 urn:service:sos.ambulance 238 urn:service:sos.fire 239 urn:service:sos.gas 240 urn:service:sos.mountain 241 urn:service:sos.poison 242 urn:service:sos.police 243 244 245 246 247 248 249 252 254 3.2. Retrieving the via 256 In order to retrieve the boundary corresponding a specific 257 'serviceListKey', the client issues a 258 request to the server identified in the 'source' attribute of the 259 element, similar to the 260 request. 262 An example is shown below: 264 265 268 The LoST server response is shown below: 270 271 272 273 275 AT 276 Lower Austria 277 278 279 280 281 282 283 285 The 'serviceListKey' uniquely identifies a Service List Boundary as 286 the 'key' does for the service boundary (see Section 5.6 in RFC 287 5222). Therefore the 'serviceListKey' is a random token with at 288 least 128 bits of entropy and can be assumed globally unique. 289 Whenever the boundary changes, a new 'serviceListKey' MUST be 290 assigned. 292 Note: since LoST does not define an attribute to indicate which 293 profile the clients understands in a 294 request, this document also does not define one for the 295 request. 297 3.3. 299 The information that gets returned, indicates 300 the geographic region in which all the service identifiers returned 301 from a element are the same, within a 302 query. A may consist 303 of geometric shapes (both in civic and geodetic location format), and 304 may be non-contiguous, like the Service Boundary. 306 The mapping of the specific services within the Service List Boundary 307 may be different at different locations. 309 The server may return the boundary information in multiple profiles, 310 but has to use at least one profile that the client used in the 311 request in order to ensure that the client is able to process the 312 boundary information. 314 There is no need to include boundary information to a 315 . requests are purely for 316 diagnostic purposes and do not contain location information at all, 317 so no boundary information is reasonable. 319 Also note that the is optional and the LoST 320 server may return it or not based on its local policy - like it is 321 the case with the Service Boundary. However, especially for 322 emergency services, the might be crucial to 323 ensure that moving clients do not miss changes in the available 324 services. 326 3.4. Implementation Considerations 328 The subsections below discuss implementation issues for the LoST 329 server and client for the serviceListBoundary support. 331 3.4.1. Server Side 333 The mapping architecture and framework [RFC5582] describes that each 334 tree announces its coverage region (for one type of service, e.g. 335 sos.police) to one or more forest guides. Forest guides peer with 336 each other and synchronize their data. Hence, a forest guide has 337 sufficient knowledge (it knows all the services and their coverage 338 regions) to answer a query and additionally 339 add the as well. 341 The calculation of the largest possible area for which the Service 342 List stays the same might be a complex task. An alternative would be 343 to return smaller areas that are easier to compute. In such a case 344 some unneeded queries to the LoST server are the consequence, but 345 still the main purpose of the is achieved: 346 Never miss a change of available services. So a reasonable trade-off 347 between the effort to generate the boundary information and the saved 348 queries to the LoST server has to be considered. 350 Probably for some countries the county (or disrict, canton, state, 351 ...) borders would be suitable as . Some 352 neighbouring counties may have implemented different services while a 353 query in other neighbouring counties still 354 results in the same Service List. So when moving across a county 355 border, it is at least ensured, that every device fetches a new 356 Service List from the LoST server. 358 Other countries might have different structures and the generation of 359 the might follow other rules as long as it is 360 ensured that a client is able to notice any change in the Service 361 List when moving. 363 3.4.2. Client Side 365 A mobile client that already implements LoST and evaluates the 366 has almost everything that is needed to make use of 367 the . Since the integration into LoST follows 368 the concept of the (and also makes use of the same 369 location profiles), just the additional has to 370 be evaluated. Whenever moving outside a , the 371 client must perform a new query with the new 372 location information in order to determine a change in available 373 services. 375 4. Security & Privacy Considerations 377 Security considerations for LoST are discussed in RFC5222. This 378 document extends LoST to also carry Service List Boundaries (and 379 requests for them). These Service List Boundaries are calculated by 380 the server based on the individual Service Boundaries and sent to 381 clients in case the local policy allows this. Therefore it is 382 generally considered to have the same level of sensitivity as for the 383 Service Boundary and thus the same access control and confidentiality 384 requirements as the base LoST protocol. As a result, the security 385 measures incorporated in the base LoST specification provide 386 sufficient protection for LoST messages that use the Service List 387 Boundary extension. 389 5. IANA Considerations 391 This document requests two actions by IANA: a XML schema registration 392 and namespace registration, according to the description in the 393 following sections. 395 5.1. Relax NG Schema Registration 397 This document requests registration of the following Relax NG Schema 398 to the IETF XML Registry [RFC3688]: 400 URI: urn:ietf:params:xml:schema:lost1:slb 402 Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf 403 (karlheinz.wolf@nic.at) 404 Relax NG Schema: 406 BEGIN 408 409 412 413 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 432 433 434 435 436 437 439 440 441 442 443 444 445 446 447 448 449 451 452 453 454 455 456 value 457 reference 458 459 460 462 463 464 465 466 467 468 470 471 472 473 474 475 476 478 479 480 481 482 483 485 486 487 488 489 490 491 492 494 495 END 497 5.2. Namespace Registration 499 This document requests registration of the following namespace (below 500 the LoST namespace defined in [RFC5222]) to the IETF XML Registry 501 [RFC3688]: 503 URI: urn:ietf:params:xml:ns:lost1:slb 505 Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf 506 (karlheinz.wolf@nic.at) 508 XML: 510 BEGIN 512 513 515 516 517 519 LoST serviceListBoundary Namespace 520 521 522

Namespace for the LoST Service List Boundary

523

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

524

See 525 RFCXXXX.

526 527 529 END 531 6. Acknowledgement 533 The author would like to thank Henning Schulzrinne for the discussion 534 on the draft and Martin Thomson, Richard Barnes and Roger Marshall 535 for their valuable input and text suggestions during the WGLC. 537 7. Normative References 539 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 540 Tschofenig, "LoST: A Location-to-Service Translation 541 Protocol", RFC 5222, August 2008. 543 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 544 Framework", RFC 5582, September 2009. 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, March 1997. 549 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 550 January 2004. 552 Author's Address 554 Karl Heinz Wolf 555 nic.at GmbH 556 Karlsplatz 1/2/9 557 Wien A-1010 558 Austria 560 Phone: +43 1 5056416 37 561 Email: karlheinz.wolf@nic.at 562 URI: http://www.nic.at/