idnits 2.17.1 draft-wolf-ecrit-lost-servicelistboundary-02.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.ii 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1, 2009) is 5314 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 (==), 2 comments (--). 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 4, 2010 October 1, 2009 6 Location-to-Service Translation Protocol (LoST) Extension: 7 ServiceListBoundary 8 draft-wolf-ecrit-lost-servicelistboundary-02 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 4, 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. The 88 LoST server returns a list of services that are available at this 89 particular location. But the server does not inform the client for 90 which geographical region the returned service list is valid. This 91 may lead to the situation where a client initially discovered all 92 available services by the query, and then 93 moves to a different location while refreshing the service mappings, 94 but does not notice the availability of another service. The 95 following imaginary example illustrates the problem for emergency 96 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 these services. Then the client moves, refreshing 110 the service mappings when necessary as told by the ServiceBoundary. 111 However, when arriving in location B (close to a mountain), service 112 sos.mountainrescue is available, which was not available in location 113 A. Nevertheless, the client does not detect this, because only the 114 mapping of the initially discovered services (police, ambulance, 115 fire) are refreshed. Consequently, the dialstring for the mountain 116 rescue is not known by the client, and the emergency call to the 117 mountain rescue service will certainly fail. 119 Note that the ServiceBoundary (service region for an individual 120 service) cannot be considered as an indicator for the region a 121 specific service list is valid for. The service list may even change 122 within the ServiceBoundary of another service. For example, the 123 ambulance mapping is valid for a whole state, but for a part of the 124 state there is an additional mountain rescue service. 126 Consequently, there are two ways to tackle this issue: 128 o clients continuously ask for the service list, although it may not 129 have changed 130 o a boundary information (telling the client that the service list 131 does not change inside this area) 133 Since the LoST protocol has the ServiceBoundary concept in order to 134 avoid that clients continuously try to refresh the mapping of a 135 specific service, a ServiceListBoundary would provide a similar 136 mechanism for service lists. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 3. LoST Extensions 146 This chapter describes the necessary modifications to the LoST 147 protocol in order to support the proposed ServiceListBoundary in a 148 similar way as the ServiceBoundary. 150 3.1. Extensions to 152 The query may contain an additional 153 serviceListBoundary element to request the boundary for the service 154 list, either by value or by reference. In the example below the 155 value of the serviceListBoundary element ist set to "value": 157 158 163 164 166 AT 167 Lower Austria 168 Wolfsthal 169 Hauptplatz 170 1 171 2412 172 173 174 urn:service:sos 175 value 176 178 A possible response is shown below: 180 181 183 xmlns:slb="TBD" 184 185 urn:service:sos.ambulance 186 urn:service:sos.fire 187 urn:service:sos.gas 188 urn:service:sos.mountain 189 urn:service:sos.poison 190 urn:service:sos.police 191 192 193 194 195 196 197 198 200 AT 201 Lower Austria 202 203 204 206 This response above indicates that the service list is valid for 207 Lower Austria. The request has to be 208 repeated by the client only when moving out of Lower Austria. 209 However, the mappings of the services itself may have other service 210 boundaries. Additionally, the expires attribute indicates the 211 absolute time when this service list becomes invalid. 213 The boundary can also be requested by reference when setting the 214 attribute serviceListBoundary to "reference". Then the response 215 contains a serviceListBoundaryReference element, as shown below. 217 218 220 xmlns:slb="TBD" 221 222 urn:service:sos.ambulance 223 urn:service:sos.fire 224 urn:service:sos.gas 225 urn:service:sos.mountain 226 urn:service:sos.poison 227 urn:service:sos.police 228 229 230 231 232 233 234 237 239 3.2. Retrieving the serviceList Boundary via getServiceListBoundary 241 In order to retrieve the boundary corresponding a specific 242 serviceListKey, the client issues a request, 243 similar to the request. 245 An example is shown below: 247 248 251 The LoST server response is shown below: 253 254 255 256 258 AT 259 Lower Austria 260 261 262 263 264 265 266 268 The serviceListKey uniquely identifies a serviceListBoundary as the 269 key does for the service boundary (see Section 5.6 in RFC 5222). 270 Therefore the serviceListKey is a random token with at least 128 bits 271 of entropy and can be assumed globally unique. Whenever the boundary 272 changes, a new serviceListKey MUST be assigned. 274 3.3. Service List Boundary 276 The service list boundary indicates a region within which all 277 queries with the same service identifiers 278 result in the same serviceList. A service list boundary may consist 279 of geometric shapes (both in civic and geodetic location format), and 280 may be non-contiguous, like the service boundary. 282 The mapping of the specific services within the service list boundary 283 may be different at different locations. 285 The server may return the boundary information in multiple profiles, 286 but has to use at least one profile that the client used in the 287 request in order to ensure that the client is able to process the 288 boundary information. 290 TBD: For an attribute in the request could 291 be used to indicate which profile the client understands (e.g. 292 . requests are purely for 296 diagnostic purposes and do not contain location information at all, 297 so no boundary information is reasonable. 299 3.4. Implementation Considerations 301 The subsections below discuss implementations issues for the LoST 302 server and client for the serviceListBoundary support. 304 3.4.1. Server Side 306 The mapping architecture and framework [RFC5582] describes that each 307 tree announces its coverage region (for one type of service, e.g. 308 sos.police) to one or more forest guides. Forest guides peer with 309 each other and synchronize their data. Hence, a forest guide has 310 sufficient knowledge (it knows all the services and their coverage 311 regions) to answer a listServicesByLocation query and additionally 312 add the serviceListBoundary as well. 314 The calculation of the largest possible area for which the service 315 list stays the same might be a complex task. An alternative would be 316 to return smaller areas that are easier to compute. In such a case 317 some unneeded queries to the LoST server are the consequence, but 318 still the main purpose of the serviceListBoundary is achieved: Never 319 miss a change of available services. So a reasonable trade-off 320 between the effort to generate the boundary information and the saved 321 queries to the LoST server has to be considered. 323 Probably for some countries the county (or disrict, canton, state, 324 ...) borders would be suitable as serviceListBoundary. Some 325 neighbouring counties may have implemented different services while a 326 listServicesByLocation query in other neighbouring counties still 327 results in the same serviceList. So when moving across a county 328 border, it is at least ensured, that every device fetches a new 329 service list from the LoST server. 331 Other countries might have different structures and the generation of 332 the serviceListBoundary might follow other rules as long as it is 333 ensured that a client is able to notice any change in the service 334 list when moving. 336 3.4.2. Client Side 338 A mobile client that already implements LoST and evaluates the 339 serviceBoundary has almost everything that is needed to make use of 340 the serviceListBoundary. Since the integration into LoST follows the 341 concept of the serviceBoundary (and also makes use of the same 342 location profiles), just the additional serviceListBoundary has to be 343 evaluated. Whenever moving outside a serviceListBoundary, the client 344 must perform a new listServicesByLocation query with the new location 345 information in order to determine a change in available services. 347 4. Security & Privacy Considerations 349 Security considerations are discussed in [RFC5222]. 351 5. IANA Considerations 353 TODO. 355 6. Acknowledgement 357 The author would like to thank Henning Schulzrinne for the discussion 358 on the draft. 360 7. Normative References 362 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 363 Tschofenig, "LoST: A Location-to-Service Translation 364 Protocol", RFC 5222, August 2008. 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, March 1997. 369 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 370 Framework", RFC 5582, September 2009. 372 Author's Address 374 Karl Heinz Wolf 375 nic.at GmbH 376 Karlsplatz 1/2/9 377 Wien A-1010 378 Austria 380 Phone: +43 1 5056416 37 381 Email: karlheinz.wolf@nic.at 382 URI: http://www.nic.at/