idnits 2.17.1 draft-ietf-ecrit-lost-servicelistboundary-01.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 (November 9, 2009) is 5281 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: May 13, 2010 November 9, 2009 6 Location-to-Service Translation Protocol (LoST) Extension: 7 ServiceListBoundary 8 draft-ietf-ecrit-lost-servicelistboundary-01 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 response from the LoST server 16 does not provide information about the geographical region for which 17 the returned service list is valid. Therefore, this document 18 proposes a ServiceListBoundary to assist the client to not miss a 19 change in available services when moving. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on May 13, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Extensions to . . . . . . . . . . 4 67 3.2. Retrieving the serviceList Boundary via 68 getServiceListBoundary . . . . . . . . . . . . . . . . . . 6 69 3.3. Service List Boundary . . . . . . . . . . . . . . . . . . 7 70 3.4. Implementation Considerations . . . . . . . . . . . . . . 8 71 3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . 8 72 3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . 8 74 4. Security & Privacy Considerations . . . . . . . . . . . . . . 9 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 5.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 9 78 5.2. Namespace Registration . . . . . . . . . . . . . . . . . . 11 80 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 82 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 Location based service providers as well as Public Safety Answering 89 Points (PSAPs) only serve a specific geographic region. Therefore 90 the LoST protocol [RFC5222] defines the ServiceBoundary, which 91 indicates the service region for a specific service URL. However, 92 not all services are available everywhere. Clients can discover 93 available services for a particular location by the 94 query in LoST. The LoST server returns a 95 list of services that are available at this particular location. But 96 the server does not inform the client for which geographical region 97 the returned service list is valid. This may lead to the situation 98 where a client initially discoveres all available services by the 99 query, and then moves to a different 100 location (while refreshing the service mappings), but without 101 noticing the availability of other services. The following imaginary 102 example illustrates the problem for emergency calling: 104 The client is powered-up, does location determination (resulting in 105 location A) and performs an initial query 106 with location A requesting urn:services:sos. 108 The LoST server returns the following services list: 110 urn:service:sos.police 111 urn:service:sos.ambulance 112 urn:service:sos.fire 114 The client does the initial LoST mapping and discovers the 115 dialstrings for each service. Then the client moves, refreshing the 116 individual service mappings when necessary as told by the 117 ServiceBoundary. However, when arriving in location B (close to a 118 mountain), service sos.mountainrescue is available, which was not 119 available in location A. Nevertheless, the client does not detect 120 this, because only the mapping of the initially discovered services 121 (police, ambulance, fire) are refreshed. Consequently, the 122 dialstring for the mountain rescue is not known by the client, and 123 the emergency call to the mountain rescue service will certainly 124 fail. 126 Note that the ServiceBoundary (service region for an individual 127 service) cannot be considered as an indicator for the region a 128 specific service list is valid for. The service list may even change 129 within the ServiceBoundary of another service. For example, the 130 ambulance mapping is valid for a whole state, but for a part of the 131 state there is an additional mountain rescue service. 133 Consequently, there are two ways to tackle this issue: 135 o clients continuously ask for the service list, although it may not 136 have changed 137 o a boundary information (telling the client that the service list 138 does not change inside this area) 140 Since the LoST protocol has the ServiceBoundary concept in order to 141 avoid that clients continuously try to refresh the mapping of a 142 specific service, a ServiceListBoundary would provide a similar 143 mechanism for service lists. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 3. LoST Extensions 153 This chapter describes the necessary modifications to the LoST 154 protocol in order to support the proposed ServiceListBoundary in a 155 similar way as the ServiceBoundary. 157 3.1. Extensions to 159 The query may contain an additional 160 serviceListBoundary element to request the boundary for the service 161 list, either by value or by reference. In the example below the 162 value of the serviceListBoundary element ist set to "value": 164 165 170 171 173 AT 174 Lower Austria 175 Wolfsthal 176 Hauptplatz 177 1 178 2412 179 180 181 urn:service:sos 182 value 183 185 A possible response is shown below: 187 188 190 xmlns:slb="urn:ietf:params:xml:schema:lost1:slb" 191 192 urn:service:sos.ambulance 193 urn:service:sos.fire 194 urn:service:sos.gas 195 urn:service:sos.mountain 196 urn:service:sos.poison 197 urn:service:sos.police 198 199 200 201 202 203 204 205 207 AT 208 Lower Austria 209 210 211 213 This response above indicates that the service list is valid for 214 Lower Austria. The request has to be 215 repeated by the client only when moving out of Lower Austria. 216 However, the mappings of the services itself may have other service 217 boundaries. Additionally, the expires attribute indicates the 218 absolute time when this service list becomes invalid. 220 The boundary can also be requested by reference when setting the 221 attribute serviceListBoundary to "reference". Then the response 222 contains a serviceListBoundaryReference element, as shown below. 224 225 227 xmlns:slb="urn:ietf:params:xml:schema:lost1:slb" 228 229 urn:service:sos.ambulance 230 urn:service:sos.fire 231 urn:service:sos.gas 232 urn:service:sos.mountain 233 urn:service:sos.poison 234 urn:service:sos.police 235 236 237 238 239 240 241 244 246 3.2. Retrieving the serviceList Boundary via getServiceListBoundary 248 In order to retrieve the boundary corresponding a specific 249 serviceListKey, the client issues a request, 250 similar to the request. 252 An example is shown below: 254 255 258 The LoST server response is shown below: 260 261 262 263 265 AT 266 Lower Austria 267 268 269 270 271 272 273 275 The serviceListKey uniquely identifies a serviceListBoundary as the 276 key does for the service boundary (see Section 5.6 in RFC 5222). 277 Therefore the serviceListKey is a random token with at least 128 bits 278 of entropy and can be assumed globally unique. Whenever the boundary 279 changes, a new serviceListKey MUST be assigned. 281 Note: since LoST does not define an attribute to indicate which 282 profile the clients understands in a 283 request, this document also does not define one for the 284 request. 286 3.3. Service List Boundary 288 The service list boundary indicates a region within which all 289 queries with the same service identifiers 290 result in the same serviceList. A service list boundary may consist 291 of geometric shapes (both in civic and geodetic location format), and 292 may be non-contiguous, like the service boundary. 294 The mapping of the specific services within the service list boundary 295 may be different at different locations. 297 The server may return the boundary information in multiple profiles, 298 but has to use at least one profile that the client used in the 299 request in order to ensure that the client is able to process the 300 boundary information. 302 There is no need to include boundary information to a 303 . requests are purely for 304 diagnostic purposes and do not contain location information at all, 305 so no boundary information is reasonable. 307 Also note that the serviceListBoundary is optional and the LoST 308 server may return it or not based on its local policy - like it is 309 the case with the service boundary. However, especially for 310 emergency services, the serviceListBoundary might be crucial to 311 ensure that moving clients do not miss changes in the available 312 services. 314 3.4. Implementation Considerations 316 The subsections below discuss implementations issues for the LoST 317 server and client for the serviceListBoundary support. 319 3.4.1. Server Side 321 The mapping architecture and framework [RFC5582] describes that each 322 tree announces its coverage region (for one type of service, e.g. 323 sos.police) to one or more forest guides. Forest guides peer with 324 each other and synchronize their data. Hence, a forest guide has 325 sufficient knowledge (it knows all the services and their coverage 326 regions) to answer a listServicesByLocation query and additionally 327 add the serviceListBoundary as well. 329 The calculation of the largest possible area for which the service 330 list stays the same might be a complex task. An alternative would be 331 to return smaller areas that are easier to compute. In such a case 332 some unneeded queries to the LoST server are the consequence, but 333 still the main purpose of the serviceListBoundary is achieved: Never 334 miss a change of available services. So a reasonable trade-off 335 between the effort to generate the boundary information and the saved 336 queries to the LoST server has to be considered. 338 Probably for some countries the county (or disrict, canton, state, 339 ...) borders would be suitable as serviceListBoundary. Some 340 neighbouring counties may have implemented different services while a 341 listServicesByLocation query in other neighbouring counties still 342 results in the same serviceList. So when moving across a county 343 border, it is at least ensured, that every device fetches a new 344 service list from the LoST server. 346 Other countries might have different structures and the generation of 347 the serviceListBoundary might follow other rules as long as it is 348 ensured that a client is able to notice any change in the service 349 list when moving. 351 3.4.2. Client Side 353 A mobile client that already implements LoST and evaluates the 354 serviceBoundary has almost everything that is needed to make use of 355 the serviceListBoundary. Since the integration into LoST follows the 356 concept of the serviceBoundary (and also makes use of the same 357 location profiles), just the additional serviceListBoundary has to be 358 evaluated. Whenever moving outside a serviceListBoundary, the client 359 must perform a new listServicesByLocation query with the new location 360 information in order to determine a change in available services. 362 4. Security & Privacy Considerations 364 Security considerations are discussed in [RFC5222]. 366 5. IANA Considerations 368 This document requests two actions by IANA: a XML schema registration 369 and namespace registration, according to the description in the 370 following sections. 372 5.1. Relax NG Schema Registration 374 This document requests registration of the following Relax NG Schema 375 to the IETF XML Registry [RFC3688]: 377 URI: urn:ietf:params:xml:schema:lost1:slb 379 Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf 380 (karlheinz.wolf@nic.at) 382 Relax NG Schema: 384 BEGIN 386 387 393
394 395 ... 396 ... 397 398 Allows requesting the serviceListBoundary by reference or by value 399 400 401 402 403 404 value 405 reference 406 407 408 409 410
412
413 414 ... 415 ... 416 417 Returns the serviceListBoundary by Reference 418 420 421 422 423 424 425 426 427 428
430
431 432 ... 433 ... 434 435 Returns the serviceListBoundary by Value 436 438 439 440 441 442 443 444 445 447
449
451 452 Request for the serviceListBoundary 453 455 456 457 458 459 460 462
464
466 467 Response to getServiceListBoundary 468 470 471 472 473 474 475 476 477 479
480 482 END 484 5.2. Namespace Registration 486 This document requests registration of the following namespace (below 487 the LoST namespace defined in [RFC5222]) to the IETF XML Registry 488 [RFC3688]: 490 URI: urn:ietf:params:xml:ns:lost1:slb 492 Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf 493 (karlheinz.wolf@nic.at) 495 XML: 497 BEGIN 499 500 502 503 504 506 LoST serviceListBoundary Namespace 507 508 509

Namespace for the LoST serviceListBoundary

510

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

511

See 512 RFCXXXX.

513 514 516 END 518 6. Acknowledgement 520 The author would like to thank Henning Schulzrinne for the discussion 521 on the draft. 523 7. Normative References 525 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 526 Tschofenig, "LoST: A Location-to-Service Translation 527 Protocol", RFC 5222, August 2008. 529 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 530 Framework", RFC 5582, September 2009. 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 536 January 2004. 538 Author's Address 540 Karl Heinz Wolf 541 nic.at GmbH 542 Karlsplatz 1/2/9 543 Wien A-1010 544 Austria 546 Phone: +43 1 5056416 37 547 Email: karlheinz.wolf@nic.at 548 URI: http://www.nic.at/