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.