idnits 2.17.1 draft-ietf-ecrit-lost-servicelistboundary-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 is 1 instance of too long lines in the document, the longest one being 1 character 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 (October 6, 2009) is 5315 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: April 9, 2010 October 6, 2009 6 Location-to-Service Translation Protocol (LoST) Extension: 7 ServiceListBoundary 8 draft-ietf-ecrit-lost-servicelistboundary-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 9, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 LoST maps service identifiers and location information to service 47 contact URIs. If a LoST client wants to discover available services 48 for a particular location, it will perform a 49 query to the LoST server. However, the response from the LoST server 50 does not provide information about the geographical region for which 51 the returned service list is valid. Therefore, this document 52 proposes a ServiceListBoundary to assist the client to not miss a 53 change in available services when moving. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Extensions to . . . . . . . . . . . 4 63 3.2. Retrieving the serviceList Boundary via 64 getServiceListBoundary . . . . . . . . . . . . . . . . . . 6 65 3.3. Service List Boundary . . . . . . . . . . . . . . . . . . . 7 66 3.4. Implementation Considerations . . . . . . . . . . . . . . . 8 67 3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . . 8 68 3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Security & Privacy Considerations . . . . . . . . . . . . . . . 9 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 74 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 9 76 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 Location based service providers as well as Public Safety Answering 83 Points (PSAPs) only serve a specific geographic region. Therefore 84 the LoST protocol defines the ServiceBoundary, which indicates the 85 service region for a specific service URL. However, not all services 86 are available everywhere. Clients can discover available services 87 for a particular location by the query in 88 LoST [RFC5222]. The LoST server returns a list of services that are 89 available at this particular location. But the server does not 90 inform the client for which geographical region the returned service 91 list is valid. This may lead to the situation where a client 92 initially discovered all available services by the 93 query, and then moves to a different 94 location while refreshing the service mappings, but does not notice 95 the availability of another service. The following imaginary example 96 illustrates the problem for emergency calling: 98 The client is powered-up, does location determination (resulting in 99 location A) and performs an initial query 100 with location A requesting urn:services:sos. 102 The LoST server returns the following services list: 104 urn:service:sos.police 105 urn:service:sos.ambulance 106 urn:service:sos.fire 108 The client does the initial LoST mapping and discovers the 109 dialstrings for each service. Then the client moves, refreshing the 110 individual service mappings when necessary as told by the 111 ServiceBoundary. However, when arriving in location B (close to a 112 mountain), service sos.mountainrescue is available, which was not 113 available in location A. Nevertheless, the client does not detect 114 this, because only the mapping of the initially discovered services 115 (police, ambulance, fire) are refreshed. Consequently, the 116 dialstring for the mountain rescue is not known by the client, and 117 the emergency call to the mountain rescue service will certainly 118 fail. 120 Note that the ServiceBoundary (service region for an individual 121 service) cannot be considered as an indicator for the region a 122 specific service list is valid for. The service list may even change 123 within the ServiceBoundary of another service. For example, the 124 ambulance mapping is valid for a whole state, but for a part of the 125 state there is an additional mountain rescue service. 127 Consequently, there are two ways to tackle this issue: 129 o clients continuously ask for the service list, although it may not 130 have changed 131 o a boundary information (telling the client that the service list 132 does not change inside this area) 134 Since the LoST protocol has the ServiceBoundary concept in order to 135 avoid that clients continuously try to refresh the mapping of a 136 specific service, a ServiceListBoundary would provide a similar 137 mechanism for service lists. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 3. LoST Extensions 147 This chapter describes the necessary modifications to the LoST 148 protocol in order to support the proposed ServiceListBoundary in a 149 similar way as the ServiceBoundary. 151 3.1. Extensions to 153 The query may contain an additional 154 serviceListBoundary element to request the boundary for the service 155 list, either by value or by reference. In the example below the 156 value of the serviceListBoundary element ist set to "value": 158 159 164 165 167 AT 168 Lower Austria 169 Wolfsthal 170 Hauptplatz 171 1 172 2412 173 174 175 urn:service:sos 176 value 177 179 A possible response is shown below: 181 182 184 xmlns:slb="TBD" 185 186 urn:service:sos.ambulance 187 urn:service:sos.fire 188 urn:service:sos.gas 189 urn:service:sos.mountain 190 urn:service:sos.poison 191 urn:service:sos.police 192 193 194 195 196 197 198 199 201 AT 202 Lower Austria 203 204 205 207 This response above indicates that the service list is valid for 208 Lower Austria. The request has to be 209 repeated by the client only when moving out of Lower Austria. 210 However, the mappings of the services itself may have other service 211 boundaries. Additionally, the expires attribute indicates the 212 absolute time when this service list becomes invalid. 214 The boundary can also be requested by reference when setting the 215 attribute serviceListBoundary to "reference". Then the response 216 contains a serviceListBoundaryReference element, as shown below. 218 219 221 xmlns:slb="TBD" 222 223 urn:service:sos.ambulance 224 urn:service:sos.fire 225 urn:service:sos.gas 226 urn:service:sos.mountain 227 urn:service:sos.poison 228 urn:service:sos.police 229 230 231 232 233 234 235 238 240 3.2. Retrieving the serviceList Boundary via getServiceListBoundary 242 In order to retrieve the boundary corresponding a specific 243 serviceListKey, the client issues a request, 244 similar to the request. 246 An example is shown below: 248 249 252 The LoST server response is shown below: 254 255 256 257 259 AT 260 Lower Austria 261 262 263 264 265 266 267 269 The serviceListKey uniquely identifies a serviceListBoundary as the 270 key does for the service boundary (see Section 5.6 in RFC 5222). 271 Therefore the serviceListKey is a random token with at least 128 bits 272 of entropy and can be assumed globally unique. Whenever the boundary 273 changes, a new serviceListKey MUST be assigned. 275 3.3. Service List Boundary 277 The service list boundary indicates a region within which all 278 queries with the same service identifiers 279 result in the same serviceList. A service list boundary may consist 280 of geometric shapes (both in civic and geodetic location format), and 281 may be non-contiguous, like the service boundary. 283 The mapping of the specific services within the service list boundary 284 may be different at different locations. 286 The server may return the boundary information in multiple profiles, 287 but has to use at least one profile that the client used in the 288 request in order to ensure that the client is able to process the 289 boundary information. 291 TBD: For an attribute in the request could 292 be used to indicate which profile the client understands (e.g. 293 . requests are purely for 297 diagnostic purposes and do not contain location information at all, 298 so no boundary information is reasonable. 300 Also note that the serviceListBoundary is optional and the LoST 301 server may return it based on its local policy - like it is the case 302 with service boundary. However, especially for emergency services, 303 the serviceListBoundary might be crucial to ensure that moving 304 clients do not miss changes in the available services. 306 3.4. Implementation Considerations 308 The subsections below discuss implementations issues for the LoST 309 server and client for the serviceListBoundary support. 311 3.4.1. Server Side 313 The mapping architecture and framework [RFC5582] describes that each 314 tree announces its coverage region (for one type of service, e.g. 315 sos.police) to one or more forest guides. Forest guides peer with 316 each other and synchronize their data. Hence, a forest guide has 317 sufficient knowledge (it knows all the services and their coverage 318 regions) to answer a listServicesByLocation query and additionally 319 add the serviceListBoundary as well. 321 The calculation of the largest possible area for which the service 322 list stays the same might be a complex task. An alternative would be 323 to return smaller areas that are easier to compute. In such a case 324 some unneeded queries to the LoST server are the consequence, but 325 still the main purpose of the serviceListBoundary is achieved: Never 326 miss a change of available services. So a reasonable trade-off 327 between the effort to generate the boundary information and the saved 328 queries to the LoST server has to be considered. 330 Probably for some countries the county (or disrict, canton, state, 331 ...) borders would be suitable as serviceListBoundary. Some 332 neighbouring counties may have implemented different services while a 333 listServicesByLocation query in other neighbouring counties still 334 results in the same serviceList. So when moving across a county 335 border, it is at least ensured, that every device fetches a new 336 service list from the LoST server. 338 Other countries might have different structures and the generation of 339 the serviceListBoundary might follow other rules as long as it is 340 ensured that a client is able to notice any change in the service 341 list when moving. 343 3.4.2. Client Side 345 A mobile client that already implements LoST and evaluates the 346 serviceBoundary has almost everything that is needed to make use of 347 the serviceListBoundary. Since the integration into LoST follows the 348 concept of the serviceBoundary (and also makes use of the same 349 location profiles), just the additional serviceListBoundary has to be 350 evaluated. Whenever moving outside a serviceListBoundary, the client 351 must perform a new listServicesByLocation query with the new location 352 information in order to determine a change in available services. 354 4. Security & Privacy Considerations 356 Security considerations are discussed in [RFC5222]. 358 5. IANA Considerations 360 TODO. 362 6. Acknowledgement 364 The author would like to thank Henning Schulzrinne for the discussion 365 on the draft. 367 7. Normative References 369 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 370 Tschofenig, "LoST: A Location-to-Service Translation 371 Protocol", RFC 5222, August 2008. 373 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 374 Framework", RFC 5582, September 2009. 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 Author's Address 381 Karl Heinz Wolf 382 nic.at GmbH 383 Karlsplatz 1/2/9 384 Wien A-1010 385 Austria 387 Phone: +43 1 5056416 37 388 Email: karlheinz.wolf@nic.at 389 URI: http://www.nic.at/