idnits 2.17.1 draft-winterbottom-sip-location-package-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1067. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 7, 2008) is 5771 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) == Unused Reference: 'RFC3856' is defined on line 811, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-geopriv-pdif-lo-profile' is defined on line 814, but no explicit reference was found in the text == Unused Reference: 'RFC4119' is defined on line 827, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3693 ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-02 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-lbyr-requirements (ref. 'I-D.ietf-geopriv-lbyr-requirements') == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-07 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-08 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-l7-lcp-ps (ref. 'I-D.ietf-geopriv-l7-lcp-ps') == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-11 == Outdated reference: A later version (-05) exists of draft-winterbottom-geopriv-deref-protocol-01 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-17 == Outdated reference: A later version (-05) exists of draft-winterbottom-geopriv-held-context-02 == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-location-quality-01 == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-loc-filters-01 Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Winterbottom 3 Internet-Draft M. Thomson 4 Intended status: Standards Track Andrew Corporation 5 Expires: January 8, 2009 H. Tschofenig 6 Nokia Siemens Networks 7 July 7, 2008 9 A Session Initiation Protocol (SIP) Event Package for Location 10 Information 11 draft-winterbottom-sip-location-package-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 8, 2009. 38 Abstract 40 This document specifies a SIP event package allowing allowing a 41 location receiptient to subscribe for location information when 42 provided a location URI using the sip, sips, or pres URI schemes. 43 The notification that results from the subscription is either the 44 location of the Target or an error. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3. Protocol Interaction . . . . . . . . . . . . . . . . . . . . . 6 51 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8 52 5. Event Package details . . . . . . . . . . . . . . . . . . . . 10 53 5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 10 54 5.2. Event Package Parameters . . . . . . . . . . . . . . . . . 10 55 5.3. Accept Header Value . . . . . . . . . . . . . . . . . . . 10 56 5.4. Subscription Duration . . . . . . . . . . . . . . . . . . 10 57 5.5. Forked SUBSCRIBE Requests . . . . . . . . . . . . . . . . 10 58 5.6. Subscribing for Location Information . . . . . . . . . . . 11 59 5.6.1. SUBSCRIBE Message Body . . . . . . . . . . . . . . . . 11 60 5.7. Location Notification . . . . . . . . . . . . . . . . . . 12 61 5.7.1. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . 12 62 5.7.2. Rate of Notifications . . . . . . . . . . . . . . . . 12 63 5.8. State Agents . . . . . . . . . . . . . . . . . . . . . . . 13 64 6. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 66 7.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 16 67 7.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 18 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 70 9.1. HELD Error Token Registration . . . . . . . . . . . . . . 20 71 9.2. URN Sub-Namespace Registration for 72 urn:ietf:params:xml:ns:loc-event . . . . . . . . . . . . . 20 73 9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 21 74 9.4. MIME Media Type Registration for 75 'application/loc-event+xml' . . . . . . . . . . . . . . . 21 76 9.5. Event Package Registration . . . . . . . . . . . . . . . . 22 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 79 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 80 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 81 Appendix A. Subscription Examples . . . . . . . . . . . . . . . . 27 82 A.1. Requesting a Quality of Position . . . . . . . . . . . . . 27 83 A.2. Inclusion of Mahy Loc-Filters . . . . . . . . . . . . . . 28 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 85 Intellectual Property and Copyright Statements . . . . . . . . . . 32 87 1. Introduction 89 Location information is generally recognized as being a subset of 90 presence as described in [RFC4079]. It is also recognized that 91 location information is most readily available from the local access 92 network serving a specific end-device. The node in a local access 93 network responsible for determining and desseminating an end-point's 94 location is referred to as a location information server (LIS). 95 Where the LIS is capable of supporting SIP SUBSCRIBE and NOTIFY 96 messages [RFC3265] for the dissemination of location information it 97 becomes a limited capability presence server. To support this 98 limited capability a new SIP event package is defined specifically 99 for the subscription to, and notification of, a Target's physical 100 location. 102 This document proposes the usage of the Session Initiation Protocol 103 (SIP) [RFC3261] as a location dereference protocol. This is 104 accomplished by defining a new subscription event package as 105 described in RFC3265 [RFC3265]. 107 This event package is based on the concept of a location information 108 server (LIS), which resides in the same access network as a Target. 109 the LIS is capable of accepting subscriptions, storing subscription 110 state, and generating notifications either periodically or when the 111 LIS detects changes in a Target's physical location. 113 The event package defines a simple but extensible XML schema which 114 allows a location recipient to subscribe to a LIS for a Target's 115 location information. A base set of subscription criteria are 116 defined in an XML schema. Extensions points are provided in the 117 schema so that additional criteria can be specified for future 118 application requirements. 120 How the location recipient learns the location URI is out of scope 121 for this document. The specification relies of existing SIP, 122 presence, and georpiv mechansisms for the authentication of location 123 recipients and the application of these mechanisms is deemed out of 124 scope for this specification. Existing presence and location 125 authorization policies such as those described in common policy 126 [RFC4745] and geolocation policy [I-D.ietf-geopriv-policy] are 127 assumed to be in place. Alternatively, specific constraints attached 128 to the location URI itself, such as those described in 129 [I-D.winterbottom-geopriv-held-context] are assumed to exist. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 The terms Location Recipient and Target are used as defined in 138 [RFC3693] 140 The term location information (LIS) is used throughout this document 141 as defined in [I-D.ietf-geopriv-l7-lcp-ps]. A presence server that 142 distributes physical location to watchers may also be regarded as a 143 LIS in the terms of reference for this document. 145 3. Protocol Interaction 147 Using a location URI that provides a Target's location to a recipient 148 directly from the LIS is often preferable and more effient than 149 requiring location information originate from the LIS and traverse 150 the Target end-point before reaching the location recipient. This is 151 especially true in environments where the Target can move and change 152 points of network attachment without an interuption in service. The 153 merits and requirements of using a location URI are addressed in 154 detail in the location by reference requirements document 155 [I-D.ietf-geopriv-lbyr-requirements]. 157 Location configuration protocols, such as HELD, provide an end-point 158 the ability to request a location URI that they can distribute to 159 external entities and applications for the purpose of later location 160 retrival. A scheme for dereferencing HELD URIs is described in 161 [I-D.winterbottom-geopriv-deref-protocol]. This specification 162 describes a location information event package that an application or 163 entity can use this to request location information directly from a 164 LIS or presence server using SIP. 166 The SIP subscription functionality is described in [RFC3265], along 167 with general guidelines for defining new event packages for which 168 subscriptions can be made. This specification defines a new event 169 package that allows a recipient to specifically subscribe for 170 location information. The event package consists of an XML schema 171 that is included in the body of the SIP subscribe message, and a new 172 subscribe event header. Both the schema and the subscribe event 173 header are registered with IANA in Section 9. The general context 174 and model for location subscription is shown in Figure 1. 176 +-----------+ 177 +------------+ | Location | +-----------+ 178 | End Device | |Information| | Location | 179 | (Target) | | Server | | Recipient | 180 +-----+------+ +----+------+ +-----+-----+ 181 | | | 182 +--+--------------------------+--+ | 183 | | | | | 184 | |===locationRequest(URI)==>0 | | 185 | | | | Location | 186 | | | | Configuration | 187 | 0<==locationResponse(URI)==| | Protocol | 188 | | | | | 189 +--+--------------------------+--+ | 190 | | | 191 | | | 192 |~~~~~~~~~~~~Location Conveyance (URI)~~~~~~~~~~~~~~~~~~>0 193 | | | 194 | +--+-----------------------------+--+ 195 | | | | | 196 | Location | 0<======SUBSCRIBE(loc)========| | 197 | Event | | | | 198 | Package | |========NOTIFY(PIDF-LO)=====>0 | 199 | | |========NOTIFY(PIDF-LO)=====>0 | 200 | | |========NOTIFY(PIDF-LO)=====>0 | 201 | +--+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+--+ 202 | | | 203 | | | 205 Figure 1: Context Diagram 207 4. Overview of Operation 209 In this section, an overview of the operation of this event package 210 is presented. In order to provide clarity on this package the 211 overview describes behavior that is documented in part here, partly 212 in the SIP event framework [RFC3265], and in the SIP specification 213 [RFC3261]. However, the detailed semantics of this package require 214 the reader to be familiar with SIP events and the SIP specification 215 itself. 217 When an entity, the subscriber, wishes to learn about the location 218 from some user, it creates a SUBSCRIBE request. This request 219 identifies the desired Target in the Request-URI, using a SIP URI, 220 SIPS URI [RFC3261] or a presence (pres) URI [RFC3859]. The SUBSCRIBE 221 request is carried along SIP proxies as any other SIP request would 222 be and eventually arrives at a LIS, which will generate a response to 223 the request. 225 The LIS first authenticates the subscription, then authorizes it. 226 The means for authorization are outside the scope of this protocol. 227 If authorized, a 200 OK response is returned followed immediately by 228 a NOTFIY message containing the location of the target. If 229 authorization could not be obtained at this time, the subscription is 230 considered "terminated" with a reason code of "rejected" and a 231 $quot;403 Forbidden" response is returned. Periodicially, or as the 232 location of the Target changes, the LIS generates and sends NOTIFY 233 messages containing the location information to all subscribers with 234 authorized subscriptions. Changes in the state of the subscription 235 itself can also trigger NOTIFY messages; that state is carried in the 236 Subscription-State header field of the NOTIFY, and would typically 237 indicate whether the subscription is active or terminated. No 238 pending state for location information is considered. 240 The SUBSCRIBE message establishes a "dialog" with the LIS. A dialog 241 is defined in RFC 3261 [RFC3261], and it represents the SIP state 242 between a pair of entities to facilitate peer-to-peer message 243 exchanges. This state includes the sequence numbers for messages in 244 both directions (SUBSCRIBE from the subscriber, NOTIFY from the LIS), 245 in addition to a route set and remote target URI. The route set is a 246 list of SIP (or SIPS) URIs which identify SIP proxy servers that are 247 to be visited along the path of SUBSCRIBE refreshes or NOTIFY 248 requests. The remote target URI is the SIP or SIPS URI that 249 identifies the target of the message - the subscriber, in the case of 250 NOTIFY, or the LIS, in the case of a SUBSCRIBE refresh. 252 The subscription persists for a duration that is negotiated as part 253 of the initial SUBSCRIBE. The subscriber will need to refresh the 254 subscription before its expiration, if they wish to retain the 255 subscription. This is accomplished by sending a SUBSCRIBE refresh 256 within the same dialog established by the initial SUBSCRIBE. This 257 SUBSCRIBE is nearly identical to the initial one, but contains a tag 258 in the To header field and a higher CSeq header field value. 260 The subscriber can terminate the subscription by sending a SUBSCRIBE, 261 within the dialog, with an Expires header field (which indicates 262 duration of the subscription) value of zero. This causes an 263 immediate termination of the subscription. A NOTIFY request is then 264 generated by the LIS with the most recent location information for 265 the Target. 267 The LIS can terminate the subscription at any time. To do so, it 268 sends a NOTIFY request with a Subscription-State header field with a 269 value of "terminated". A reason parameter is also supplied which 270 provides the reason for the termination. 272 5. Event Package details 274 5.1. Event Package Name 276 A SIP subscription specifies precisely which event or set events 277 (event package) the subscriber is interested in being notified about. 278 This specification deals with subscription for location information 279 and specifies a new event package excplicitly for this purpose. The 280 SIP event notification specification [RFC3265] stipulates that a new 281 event package requires the registration of a new "Event" header token 282 so that a subscriber can explcitly subscribe for these events. This 283 specification defines the "loc-event" Event header token, and 284 registers it in Section 9. All subscriptions for location 285 information are expected to use this Event header token. 287 5.2. Event Package Parameters 289 The SIP event framework allows event packages to define additional 290 parameters carried in the Event header field. This package, 291 presence, does not define any additional parameters. 293 5.3. Accept Header Value 295 The Accept header in the SUBSCRIBE indicates to the LIS what type of 296 information the location recipient is expecting. This event package 297 requires that the Accept header bet set to "application/held+xml". 298 The rationale for resuing the HELD MIME type in the NOTIFY message is 299 provide in Section 5.7.1. 301 5.4. Subscription Duration 303 Default is 24 hours. If the URI was generated using HELD Context 304 management or some other policy-based mechansism then the LIS MUST 305 provide and expires value that is equal to or less than the expiry 306 time of the specified in the policy. 308 Very short subscription times will be treated as though they are 309 immediate notification requests. Assuming that the subscription is 310 accepted, the LIS will respond with the fastest location that it is 311 able to provide. 313 5.5. Forked SUBSCRIBE Requests 315 This event package does not support forked SUBSCRIBE requests. 317 5.6. Subscribing for Location Information 319 5.6.1. SUBSCRIBE Message Body 321 The characteristics of the subscription are defined in the XML schema 322 which is conveyed from the subscriber to the LIS in the body of the 323 SUBSCRIBE message. A new MIME type of application/loc-event+xml is 324 defined for use with this schema and it is registered in Section 9. 326 The schema is broken into two parts, a "what" part, and a "when" 327 part. The "what" part defines what the subscriber requires, and the 328 "when" part defines when the LIS should send it. These two 329 components are described in more detail below. 331 5.6.1.1. What 333 The "what" part of the location subscription comprises of two basic 334 components. A location type element allows the subscriber to specify 335 the type of location information that they wish to receive, geodetic, 336 civic, or any. The LIS should try to provide location in the form 337 subscribed for. If the LIS is unable to provide location in the form 338 requested, then it may provide location in an alternative form. If 339 the subscriber is unable to process the location form returned by the 340 LIS, then the subscriber is expected to terminate the subscription. 342 An extension point is included in the schema so that additional 343 requirements of what is to be provided in notification responses can 344 be specified. Examples of how to use this this extension point are 345 providced in Appendix A. Thes examples should be considered 346 informative only. 348 5.6.1.2. When 350 The "when" part of the subscription tells the LIS when the subscriber 351 would like to receive location information about the Target. Two 352 basic components are provided. An interval, in seconds, tell the LIS 353 how often to send a location update to the subscriber. An trigger 354 for sending notifications when the Target's point of network 355 attachment changes is also provided. The "when" elements operate in 356 a logical OR manner, and a notification SHOULD be sent whenever one 357 of these conditions occurs. 359 An extension point exists in the schema so that additional 360 notification triggers can be specified and added as they become 361 required. 363 5.7. Location Notification 365 Location information and error messages are returned to the 366 subscriber in the body of a SIP NOTIFY message. 368 5.7.1. NOTIFY Bodies 370 The NOTIFY body is either a HELD locationResponse, or a HELD error 371 message, both are defined in 372 [I-D.ietf-geopriv-http-location-delivery]. The rationale for reusing 373 the location response and error messages from HELD is twofold. 374 Firstly a location recipient cannot be assured ahead of time of the 375 location URI type that a Target will provide it; this is largely 376 determined by what the LIS in the local access network provides to 377 the Target and so is out of the control of both the Target and 378 recipient. So the recipient should be capable of dealing with HELD 379 location responses in any event. Secondly, the HELD location 380 response and error messages provide excellent containers for the 381 information that the LIS needs to provide to the location recipient 382 in a NOTIFY. Rules from HELD 383 [I-D.ietf-geopriv-http-location-delivery] apply when constructing 384 these messages, with the exception of the clarifications provided 385 later. 387 An error will, in some circumstances, result in a terminated 388 subscription, however in other cases the error condition may be 389 present for only one specific notification cycle in which case the 390 subscription will remain active. The subscriber MUST examine the 391 value of the Subscription-State header to determine if the 392 subscription has been terminated or not. 394 The LIS MUST send a NOTIFY with a Subscription-State header value of 395 "terminated" and a reason code of "noresource"when it is no longer 396 able to provide the Target's location though the subscribed URI. 397 This informs the subscriber that no further attempts to subscribe to 398 the resource should be attempted. The LIS MUST include a HELD error 399 message with a code of "locationUnknown" in the NOTFIY body when this 400 condition occurs. 402 5.7.2. Rate of Notifications 404 The rate at which notifications are generated is excplictly defined 405 in the interval element of the "when" component in the SUBSCRIBE 406 body. This element defines how often the subscriber wishes to 407 receive notifications about a Target's location. The interval value 408 is a positive integer respresenting seconds. 410 A new HELD error token of "intervalTooShort" is regsitered in 411 Section 9 and MUST be used by the LIS when an inappropriately short 412 notification interval is requested by the subscriber. When this 413 error is returned the corresponding NOTIFY message MUST have a 414 Subscription-State header value of "termninated", reason code of 415 "giveup" and a value for the retry-after parameter MAY be provided. 417 5.8. State Agents 419 The LIS is responsible for keeping track of where a Target is 420 physically located in the access network. Stare, as it pertains to 421 this event package, refers to the policies associated with the URI to 422 which the subscription was made, and physical location of the Target. 423 State is therefore maintained internal to the LIS and is explcitly 424 resolved at the time that a notification is generated. 426 6. Schema 428 This section defines the schema that constitutes the body of this 429 even package. 431 432 440 441 442 445 447 448 449 451 452 453 454 455 459 462 464 465 466 467 468 470 471 472 473 474 475 476 478 479 480 481 482 485 488 490 491 492 493 494 496 497 498 499 502 503 504 505 507 Figure 2: XML Schema for Subscription Body 509 7. Examples 511 7.1. Example 1 513 In this example emergency application 1, emgapp1, is subscribing for 514 the location information associated is xyzabc being service by the 515 LIS at example.com. The emergency application would like to get 516 geodetic location information, updated every 10 seconds or when 517 xyzabc changes wireless access points. The subscription is for a 518 duration of 30 minutes. 520 SUBSCRIBE sip:xyzabc@lis.example.com SIP/2.0 521 Via: SIP/2.0/TCP emergency.emergizone.com;branch=z9hG4bKnashds7 522 To: 523 From: ;tag=xfg9 524 Call-ID: 2010@emergency.emergizone.com 525 CSeq: 17766 SUBSCRIBE 526 Max-Forwards: 70 527 Event: loc-event 528 Accept: application/held+xml 529 Contact: 530 Expires: 1800 531 Content-Type: application/loc-event+xml 532 Content-Length: 330 534 535 536 537 538 geodetic 539 540 541 542 543 10 544 545 546 yes 547 548 549 551 Figure 3: SUBSCRIBE Message 553 The successful response to the subscription shown in Figure 3 is a 554 200 OK followed almost immediately by a NOTIFY containing the 555 requested location. This is shown in Figure 4. 557 NOTIFY sip:emgapp1@emergizone.com SIP/2.0 558 Via: SIP/2.0/TCP lis.example.com;branch=z9hG4bKna998sk 559 From: ;tag=ffd2 560 To: ;tag=xfg9 561 Call-ID: 2010@emergency.emergizone.com 562 Event: loc-event 563 Subscription-State: active;expires=1790 564 Max-Forwards: 70 565 CSeq: 8775 NOTIFY 566 Contact: sip:lis.example.com 567 Content-Type: application/held+xml 568 Content-Length: 911 570 571 572 574 575 576 577 578 580 -34.407 150.88001 581 582 583 584 585 2006-01-11T03:42:28+00:00 586 587 588 589 Device-Assisted_A-GPS 590 591 592 593 2008-03-31T03:42:28+00:00 594 595 596 598 Figure 4: NOTIFY Message with Location Information 600 7.2. Example 2 602 An error message is returned when a problem with the subscription is 603 encountered, for example the location URI that the subscriber 604 subscribed too has expired or its usage count has been exceeded. 605 This error message may look something like the NOTIFY shown in 606 Figure 5. 608 NOTIFY sip:emgapp1@emergizone.com SIP/2.0 609 Via: SIP/2.0/TCP lis.example.com;branch=z9hG4bKna998sk 610 From: ;tag=ffd2 611 To: ;tag=xfg9 612 Call-ID: 2010@emergency.emergizone.com 613 Event: loc-event 614 Subscription-State: terminated;reason=noresource 615 Max-Forwards: 70 616 CSeq: 8775 NOTIFY 617 Contact: sip:lis.example.com 618 Content-Type: application/held+xml 619 Content-Length: 159 621 622 626 Figure 5: NOTIFY Message with Error 628 8. Security Considerations 630 TBD. 632 9. IANA Considerations 634 9.1. HELD Error Token Registration 636 Reference: RFC-XXXX (i.e., this document) requires the following new 637 HELD error code to be added to the HELD error code respository 638 defined in [I-D.ietf-geopriv-http-location-delivery]. 640 Error code: intervalTooShort 642 9.2. URN Sub-Namespace Registration for 643 urn:ietf:params:xml:ns:loc-event 645 This section registers a new XML namespace, 646 "urn:ietf:params:xml:ns:loc-event", as per the guidelines in 647 [RFC3688]. 649 URI: urn:ietf:params:xml:ns:loc-event 651 Registrant Contact: IETF, SIP working group, (sip@ietf.org), James 652 Winterbottom (james.winterbottom@andrew.com). 654 XML: 656 BEGIN 657 658 660 661 662 Location Information Subscription Event Package 663 664 665

Namespace for the Location Information 666 Subscription Application Event Package 667

668

urn:ietf:params:xml:ns:loc-event

669 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 670 with the RFC number for this specification.]] 671

See RFCXXXX.

672 673 674 END 676 9.3. XML Schema Registration 678 This section registers an XML schema as per the guidelines in 679 [RFC3688]. 681 URI: urn:ietf:params:xml:schema:loc-event 683 Registrant Contact: IETF, SIP working group, (sip@ietf.org), James 684 Winterbottom (james.winterbottom@andrew.com). 686 Schema: The XML for this schema can be found as the entirety of 687 Section 6 of this document. 689 9.4. MIME Media Type Registration for 'application/loc-event+xml' 691 This section registers the "application/loc-event+xml" MIME type. 693 To: ietf-types@iana.org 695 Subject: Registration of MIME media type application/loc-event+xml 697 MIME media type name: application 699 MIME subtype name: loc-event+xml 701 Required parameters: (none) 703 Optional parameters: charset 704 Indicates the character encoding of enclosed XML. Default is 705 UTF-8. 707 Encoding considerations: Uses XML, which can employ 8-bit 708 characters, depending on the character encoding used. See RFC 709 3023 [RFC3023], section 3.2. 711 Security considerations: This content type is designed to carry 712 protocol data related to the location of an entity, which could 713 include information that is considered private. Appropriate 714 precautions should be taken to limit disclosure of this 715 information. 717 Interoperability considerations: This content type provides a basis 718 for a protocol 720 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 721 replace XXXX with the RFC number for this specification.]] 723 Applications which use this media type: Location information 724 consumers. 726 Additional Information: Magic Number(s): (none) 727 File extension(s): .xml 728 Macintosh File Type Code(s): (none) 730 Person & email address to contact for further information: James 731 Winterbottom 733 Intended usage: LIMITED USE 735 Author/Change controller: This specification is TBD 737 Other information: This media type is a specialization of 738 application/xml [RFC3023], and many of the considerations 739 described there also apply to application/loc-event+xml. 741 9.5. Event Package Registration 743 This specification registers an event package, based on the 744 registration procedures defined in RFC3265 [RFC3265]. The following 745 is the information required for such a registration: 747 Package Name: loc-event 749 Package or Template-Package: This is a Package 751 Published Document: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 752 replace XXXX with the RFC number for this specification.]] 754 Person or Contact: James Winterbottom, james.winterbottom@andrew.com 756 10. Acknowledgements 758 We would like to thank Miguel Garcia and Brian Rosen for their 759 comments. 761 11. References 763 11.1. Normative References 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels", BCP 14, RFC 2119, March 1997. 768 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 769 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 771 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 772 Event Notification", RFC 3265, June 2002. 774 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 775 Types", RFC 3023, January 2001. 777 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 778 January 2004. 780 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", 781 RFC 3859, August 2004. 783 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 784 A., Peterson, J., Sparks, R., Handley, M., and E. 785 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 786 June 2002. 788 [I-D.ietf-geopriv-lbyr-requirements] 789 Marshall, R., "Requirements for a Location-by-Reference 790 Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work 791 in progress), February 2008. 793 [I-D.ietf-geopriv-http-location-delivery] 794 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 795 "HTTP Enabled Location Delivery (HELD)", 796 draft-ietf-geopriv-http-location-delivery-07 (work in 797 progress), April 2008. 799 [I-D.ietf-geopriv-l7-lcp-ps] 800 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 801 Location Configuration Protocol; Problem Statement and 802 Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in 803 progress), June 2008. 805 11.2. Informative References 807 [RFC4079] Peterson, J., "A Presence Architecture for the 808 Distribution of GEOPRIV Location Objects", RFC 4079, 809 July 2005. 811 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 812 Initiation Protocol (SIP)", RFC 3856, August 2004. 814 [I-D.ietf-geopriv-pdif-lo-profile] 815 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 816 PIDF-LO Usage Clarification, Considerations and 817 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 818 (work in progress), February 2008. 820 [I-D.winterbottom-geopriv-deref-protocol] 821 Winterbottom, J., Tschofenig, H., Schulzrinne, H., 822 Thomson, M., and M. Dawson, "An HTTPS Location 823 Dereferencing Protocol Using HELD", 824 draft-winterbottom-geopriv-deref-protocol-01 (work in 825 progress), July 2008. 827 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 828 Format", RFC 4119, December 2005. 830 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 831 Polk, J., and J. Rosenberg, "Common Policy: A Document 832 Format for Expressing Privacy Preferences", RFC 4745, 833 February 2007. 835 [I-D.ietf-geopriv-policy] 836 Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 837 and J. Polk, "Geolocation Policy: A Document Format for 838 Expressing Privacy Preferences for Location Information", 839 draft-ietf-geopriv-policy-17 (work in progress), 840 June 2008. 842 [I-D.winterbottom-geopriv-held-context] 843 Winterbottom, J., Tschofenig, H., and M. Thomson, "HELD 844 Protocol Context Management Extensions", 845 draft-winterbottom-geopriv-held-context-02 (work in 846 progress), February 2008. 848 [I-D.thomson-geopriv-location-quality] 849 Thomson, M. and J. Winterbottom, "Specifying Location 850 Quality Constraints in Location Protocols", 851 draft-thomson-geopriv-location-quality-01 (work in 852 progress), May 2008. 854 [I-D.ietf-geopriv-loc-filters] 855 Mahy, R., "A Document Format for Filtering and Reporting 856 Location Notications in the Presence Information Document 857 Format Location Object (PIDF-LO)", 858 draft-ietf-geopriv-loc-filters-01 (work in progress), 859 March 2007. 861 Appendix A. Subscription Examples 863 The exmaples in this appendix should be regarded as non-normative, 864 that is that they are for informational purposes only. There intent 865 is to demonstrate that other geoprive location request criteria can 866 easily be included into the framework described in this document. 868 A.1. Requesting a Quality of Position 870 It is quite common for applications to want loation to be provided as 871 a set of coordinates, latitude, longitude and optionally alitutde, 872 and an area of uncertainty. The document 873 [I-D.thomson-geopriv-location-quality] describes a means by which 874 location information of a specific accuracy and/or confidence can be 875 requested. Together these characteristics are referred to as the 876 Quality of Position (QoP). The following example show how a location 877 subscription can be constructed including QoP parameters based on the 878 scheme provided in [I-D.thomson-geopriv-location-quality], the 879 location provided in the subsequent location response messages should 880 also comply with [I-D.thomson-geopriv-location-quality]. 882 883 884 geodetic 885 886 887 150 888 1000 889 890 PT30S 891 892 893 894 895 180 896 897 898 true 899 900 901 903 Figure 6: Subscribing for Location with a Quality of Position 905 A.2. Inclusion of Mahy Loc-Filters 907 Rohan Mahy produced an early specification 908 [I-D.ietf-geopriv-loc-filters] that described how specific location 909 events and triggers could be defined in an XML document. This work 910 is easily included into the framework. 912 In this example the LIS is to generate a noficiation if the Target 913 moves horizontally by more than 20 metres, or vertical by more than 914 10 metres. The LIS should provide an update every 3 minutes 915 regardless of the Target movements, or when the Target changes its 916 point of attachment to the network. 918 919 920 civic 921 922 923 924 180 925 926 927 true 928 929 931 20 932 3 933 934 935 937 Figure 7: Subscribing for Location of Location Constrained Target 939 In this example LIS is to generate a noficiation if the Target 940 exceeds a speed of 3 MPH. The LIS should provide an update every 3 941 minutes regardless of the Target movements, or when the Target 942 changes its point of attachment to the network. 944 945 946 civic 947 948 949 950 60 951 952 954 3 955 956 957 959 Figure 8: Subscribing for Location of a Speed Limited Target 961 This final filters example shows how the entry or exit of a specific 962 polygon by the Target can be subscribed to using the framework. 964 965 966 civic 967 968 969 970 60 971 972 974 975 978 979 980 981 37.41188 -121.93243 982 37.41142 -121.93243 983 37.41142 -121.93132 984 37.41188 -121.93132 985 37.41188 -121.93243 986 987 988 989 990 991 992 993 995 Figure 9: Subscribing for Location of Target in a Polygon 997 Authors' Addresses 999 James Winterbottom 1000 Andrew Corporation 1001 PO Box U40 1002 Wollongong University Campus, NSW 2500 1003 AU 1005 Phone: +61 2 4221 2938 1006 Email: james.winterbottom@andrew.com 1007 URI: http://www.andrew.com/ 1009 Martin Thomson 1010 Andrew Corporation 1011 PO Box U40 1012 Wollongong University Campus, NSW 2500 1013 AU 1015 Phone: +61 2 4221 2915 1016 Email: martin.thomson@andrew.com 1017 URI: http://www.andrew.com/ 1019 Hannes Tschofenig 1020 Nokia Siemens Networks 1021 Linnoitustie 6 1022 Espoo, 02600 1023 Finland 1025 Phone: +358 (50) 4871445 1026 Email: Hannes.Tschofenig@nsn.com 1027 URI: http://www.tschofenig.priv.at 1029 Full Copyright Statement 1031 Copyright (C) The IETF Trust (2008). 1033 This document is subject to the rights, licenses and restrictions 1034 contained in BCP 78, and except as set forth therein, the authors 1035 retain all their rights. 1037 This document and the information contained herein are provided on an 1038 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1039 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1040 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1041 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1042 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1043 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1045 Intellectual Property 1047 The IETF takes no position regarding the validity or scope of any 1048 Intellectual Property Rights or other rights that might be claimed to 1049 pertain to the implementation or use of the technology described in 1050 this document or the extent to which any license under such rights 1051 might or might not be available; nor does it represent that it has 1052 made any independent effort to identify any such rights. Information 1053 on the procedures with respect to rights in RFC documents can be 1054 found in BCP 78 and BCP 79. 1056 Copies of IPR disclosures made to the IETF Secretariat and any 1057 assurances of licenses to be made available, or the result of an 1058 attempt made to obtain a general license or permission for the use of 1059 such proprietary rights by implementers or users of this 1060 specification can be obtained from the IETF on-line IPR repository at 1061 http://www.ietf.org/ipr. 1063 The IETF invites any interested party to bring to its attention any 1064 copyrights, patents or patent applications, or other proprietary 1065 rights that may cover technology that may be required to implement 1066 this standard. Please address the information to the IETF at 1067 ietf-ipr@ietf.org.