idnits 2.17.1 draft-ietf-ecrit-lost-servicelistboundary-05.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 (December 16, 2010) is 4877 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 December 16, 2010 5 Expires: June 19, 2011 7 LoST Service List Boundary Extension 8 draft-ietf-ecrit-lost-servicelistboundary-05 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 June 19, 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 Since the LoST protocol employs the Service Boundary concept in order 99 to avoid having clients continuously trying to refresh the mapping of 100 a specific service, a Service List Boundary mechanism provides 101 similar advantages for Service Lists. 103 Location based service providers as well as Public Safety Answering 104 Points (PSAPs) only serve a specific geographic region. Therefore 105 the LoST protocol [RFC5222] defines the Service Boundary, which 106 indicates the service region for a specific service URL. However, 107 not all services are available everywhere. Clients can discover 108 available services for a particular location by the 109 query in LoST. The LoST server returns a 110 list of services that are available at this particular location. But 111 the server does not inform the client as to the extent of coverage 112 for which geographical region the returned Service List is valid. 113 This may lead to the situation where a client initially discovers all 114 available services by the query, and then 115 moves to a different location (while refreshing the service 116 mappings), but without noticing the availability of other services. 117 The following imaginary example illustrates the problem for emergency 118 calling: 120 The client is powered-up, does location determination (resulting in 121 location A) and performs an initial query 122 with location A requesting urn:services:sos. 124 The LoST server returns the following list of services: 126 urn:service:sos.police 127 urn:service:sos.ambulance 128 urn:service:sos.fire 130 The client does the initial LoST mapping and discovers the 131 dialstrings for each service. Then the client moves, refreshing the 132 individual service mappings when necessary as told by the Service 133 Boundary. However, when arriving in location B (close to a 134 mountain), service sos.mountainrescue is available, which was not 135 available in location A. Since the client is only required to refresh 136 the mappings for the initially discovered services, the new service 137 is not detected. Consequently, the dialstring for the mountain 138 rescue is not known by the client. Hence, the client is unable to 139 recognize an emergency call when the user enters the dialstring of 140 the mountain rescue and thus the emergency call may fail altogether. 142 Note that the Service Boundary (service region for an individual 143 service) cannot be considered as an indicator for the region a 144 specific Service List is valid for. The Service List may even change 145 within the Service Boundary of another service. For example, the 146 ambulance mapping is valid for a whole state, but for a part of the 147 state there is an additional mountain rescue service. 149 Consequently, there are two ways to tackle this issue: 150 o clients continuously poll for the Service List, although it may 151 not have changed 152 o a boundary information (telling the client that the Service List 153 does not change inside this area) 155 2. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 3. LoST Extensions 163 This chapter describes the necessary extensions to the LoST protocol 164 in order to support the proposed Service List Boundary in a similar 165 way as the . Extensions defined in this document 166 are declared in the new XML namespace 167 urn:ietf:params:xml:ns:lost1:slb. 169 3.1. Extensions to 171 The query may contain an additional 172 element to additionally request the 173 boundary for the Service List based on the location provided, with 174 the resulting location for the list presented either by value or by 175 reference. In the example below the value of 'type' attribute of the 176 element is set to "value": 178 179 184 185 187 AT 188 Lower Austria 189 Bruck an der Leitha 190 Wolfsthal 191 Hauptplatz 192 1 193 2412 194 195 196 urn:service:sos 197 198 200 A with the addition of one 201 elemenents is shown below: 203 204 207 208 urn:service:sos.ambulance 209 urn:service:sos.fire 210 urn:service:sos.gas 211 urn:service:sos.mountain 212 urn:service:sos.poison 213 urn:service:sos.police 214 215 216 217 218 219 220 222 224 AT 225 Lower Austria 226 227 228 230 This response above indicates that the Service List is valid for 231 Lower Austria. The request needs to be 232 repeated by the client only when moving out of Lower Austria. 233 However, the mappings of the services itself may have other service 234 boundaries. Additionally, the 'expires' attribute indicates the 235 absolute time when this Service List becomes invalid. 237 The response MAY contain multiple elements for 238 alternative representation, each representing the boundary in a 239 specific location profile. However, multiple locations inside a 240 serviceListBoundary element are considered to be additive. 242 The boundary can also be requested by reference when setting the 243 value of the 'type' attribute of the 244 element to "reference" (which is the default in case the attribute is 245 omitted). Then the response contains a 246 element with a 'serviceListKey' 247 attribute (described in Section 3.2), as shown below. 249 250 253 254 urn:service:sos.ambulance 255 urn:service:sos.fire 256 urn:service:sos.gas 257 urn:service:sos.mountain 258 urn:service:sos.poison 259 urn:service:sos.police 260 261 262 263 264 265 266 269 271 3.2. Retrieving the via 273 In order to retrieve the boundary corresponding a specific 274 'serviceListKey', the client issues a 275 request to the server identified in the 'source' attribute of the 276 element, similar to the 277 request. 279 An example is shown below: 281 282 286 The LoST server response is shown below: 288 289 291 292 294 AT 295 Lower Austria 296 297 298 299 300 301 302 304 The 'serviceListKey' uniquely identifies a Service List Boundary as 305 the 'key' does for the Service Boundary (see Section 5.6 in RFC 306 5222). Therefore the 'serviceListKey' is a random token with at 307 least 128 bits of entropy and can be assumed globally unique. 308 Whenever the boundary changes, a new 'serviceListKey' MUST be 309 assigned. 311 Note: since LoST does not define an attribute to indicate which 312 location profile the clients understands in a 313 request, this document also does not define 314 one for the request. 316 3.3. 318 The Service List Boundary information that gets returned indicates 319 the geographic region in which all the service identifiers returned 320 from a element are the same, within a 321 query. A Service List Boundary may consist 322 of geometric shapes (both in civic and geodetic location format), and 323 may be non-contiguous, like the Service Boundary. 325 The mapping of the specific services within the Service List Boundary 326 may be different at different locations. 328 The server MAY return the boundary information in multiple location 329 profiles, but MUST use at least one profile that the client used in 330 the request in order to ensure that the client is able to process the 331 boundary information. 333 There is no need to include boundary information to a 334 . The request is purely for 335 diagnostic purposes and does not contain location information at all, 336 so boundary information cannot be calculated. 338 Also note that the Service List Boundary is optional and the LoST 339 server may return it or not based on its local policy - like it is 340 the case with the Service Boundary. However, especially for 341 emergency services, the Service List Boundary might be crucial to 342 ensure that moving clients do not miss changes in the available 343 services. 345 3.4. Implementation Considerations 347 The subsections below discuss implementation issues for the LoST 348 server and client for the Service List Boundary support. 350 3.4.1. Server Side 352 The mapping architecture and framework [RFC5582] describes that each 353 tree announces its coverage region (for one type of service, e.g. 354 sos.police) to one or more forest guides. Forest guides peer with 355 each other and synchronize their data. Hence, a forest guide has 356 sufficient knowledge (it knows all the services and their coverage 357 regions) to answer a query and additionally 358 add the or as 359 well. 361 The calculation of the largest possible area for which the Service 362 List stays the same might be a complex task. An alternative would be 363 to return smaller areas that are easier to compute. In such a case 364 some unneeded queries to the LoST server are the consequence, but 365 still the main purpose of the Service List Boundary is achieved: 366 Never miss a change of available services. Thus, the server operator 367 may specify a reasonable trade-off between the effort to generate the 368 boundary information and the saved queries to the LoST server. 370 For example, in some countries the offered services may differ in 371 adjacent counties (or districts, cantons, states, ...). Their 372 borders may be suitable as Service List Boundary as well, even though 373 some adjacent counties offer the same services. 375 Other countries might have different structures and the generation of 376 the Service List Boundary 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 Service List Boundary. Since the integration into LoST follows 385 the concept of the (and also makes use of the same 386 location profiles), just the additional needs 387 to be evaluated. Whenever moving outside a Service List Boundary, 388 the client performs 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: an XML schema 409 registration and namespace registration, according to the description 410 in the 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 426 427 434 435 436 437 438 439 440 441 442 443 444 445 446 447 449 450 451 452 453 455 456 457 458 459 460 461 462 true 463 464 466 467 468 469 470 471 473 474 475 476 477 478 479 480 481 482 483 484 485 486 488 490 491 492 493 494 495 value 496 reference 497 498 reference 499 500 501 502 504 505 506 507 508 509 510 511 512 513 514 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 534 535 536 537 538 539 540 541 543 END 545 5.2. Namespace Registration 547 This document requests registration of the following namespace (below 548 the LoST namespace defined in [RFC5222]) to the IETF XML Registry 549 [RFC3688]: 551 URI: urn:ietf:params:xml:ns:lost1:slb 553 Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf 554 (karlheinz.wolf@nic.at) 556 XML: 558 BEGIN 560 561 563 564 565 567 LoST Service List Boundary Namespace 568 569 570

Namespace for the LoST Service List Boundary

571

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

572

See 573 RFCXXXX.

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