idnits 2.17.1
draft-ietf-sip-location-conveyance-04.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 16.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1307.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1284.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1291.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1297.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== It seems as if not all pages are separated by form feeds - found 0 form
feeds but 27 pages
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 273 has weird spacing: '... Rr ar ...'
== Line 277 has weird spacing: '... Rr ar ...'
== The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
does not include the phrase in its RFC 2119 key words list.
-- 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.)
-- Couldn't find a document date in the document -- date freshness check
skipped.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC3851' is mentioned on line 375, but not defined
** Obsolete undefined reference: RFC 3851 (Obsoleted by RFC 5751)
** Downref: Normative reference to an Informational RFC: RFC 3693
** Obsolete normative reference: RFC 2393 (ref. 'RFC2392') (Obsoleted by
RFC 3173)
** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665)
-- Obsolete informational reference (is this intentional?): RFC 3825
(Obsoleted by RFC 6225)
Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIP Working Group James Polk
3 Internet Draft Cisco Systems
4 Expiration: March 1st, 2007 Brian Rosen
5 NeuStar
7 Session Initiation Protocol Location Conveyance
8 draft-ietf-sip-location-conveyance-04.txt
9 Sept 1st, 2006
11 Status of this Memo
13 By submitting this Internet-Draft, each author represents that any
14 applicable patent or other IPR claims of which he or she is aware
15 have been or will be disclosed, and any of which he or she becomes
16 aware will be disclosed, in accordance with Section 6 of BCP 79.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six
24 months and may be updated, replaced, or obsoleted by other documents
25 at any time. It is inappropriate to use Internet-Drafts as
26 reference material or to cite them other than as "work in
27 progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on March 1st, 2007.
37 Copyright Notice
39 Copyright (C) The Internet Society (2006).
41 Abstract
43 This document defines an extension to the Session Initiation
44 Protocol (SIP) to convey geographic location information from one
45 SIP entity to another SIP entity. The extension covers end to end
46 conveyance as well as location-based routing, where proxy servers
47 make routing decisions based on the location of the UAC.
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
52 2. Conventions used in this document . . . . . . . . . . . . . . 4
53 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 4
54 3.1 Overview of SIP Location Conveyance . . . . . . . . . . . 4
55 3.2 The Geolocation Header . . . . . . . . . . . . . . . . . 5
56 3.3 424 (Bad Location Information) Response Code . . . . . . 6
57 3.4 The Geolocation Reason Protocol . . . . . . . . . . . . . 7
58 3.5 The Geolocation Option Tag . . . . . . . . . . . . . . . 7
59 3.6 'routing-query-allowed' Element in PIDF-LO . . . . . . . 8
60 3.7 Using sip/sips/pres as a Dereference Protocol . . . . . . 8
61 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
62 4.1 Location-by-value (Coordinate Format) . . . . . . . . . . 9
63 4.2 Location-by-value (Civic Format) . . . . . . . . . . . . 10
64 4.3 Location-by-reference . . . . . . . . . . . . . . . . . . 12
65 5. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 12
66 5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 13
67 5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 14
68 5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 14
69 6. Special Considerations for Emergency Calls . . . . . . . . . 15
70 7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 15
71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17
73 9.1 IANA Registration for New SIP Geolocation Header . . . . 17
74 9.2 IANA Registration for New SIP Geolocation Option Tag . . 17
75 9.3 IANA Registration for New 4XX Response Code . . . . . . . 17
76 9.4 IANA Registration of the Geolocation Reason Protocol . . 17
77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
79 11.1 Normative References . . . . . . . . . . . . . . . . . 18
80 11.2 Informative References . . . . . . . . . . . . . . . . . 18
81 Author Information . . . . . . . . . . . . . . . . . . . . . 19
82 Appendix A. Changes from Prior Versions . . . . . . . . . . 19
83 Appendix B. Requirements for SIP Location Conveyance . . . . 21
84 Intellectual Property and Copyright Statements . . . . . . . 26
86 1. Introduction
88 This document describes how Location can be "conveyed" (that is,
89 sent on the Internet) from a SIP user agent, or in some
90 circumstances a proxy server acting on behalf of a user agent, to
91 another entity using the SIP [RFC3261] protocol. Here "Location" is
92 a description of the physical geographical area where a User Agent
93 currently exists. We use the term "conveyance" to distinguish other
94 circumstances when a location is used such as how the entity
95 conveying location using this extension determined where the
96 location was (using, for example, an Assisted GPS mechanism) or a
97 protocol by which the entity acquired the location it is conveying
98 from another entity.
100 Geographic location in the IETF is discussed in RFC 3693 (Geopriv
101 Requirements) [RFC3693]. It defines a "target" as the entity whose
102 location is being transmitted, in this case, it is the user agent's
103 (UA) location. A [RFC3693] "using protocol" defines how a "location
104 server" transmits a "location object" to a "location recipient"
105 while maintaining the contained privacy intentions of the target
106 intact. This document describes the extension to SIP for how it
107 complies with the using protocol requirements, where the location
108 server is a User Agent or Proxy Server and the location recipient is
109 another User Agent or Proxy Server.
111 Location can be transmitted by-value or by-reference. The "value"
112 used in this document is a location object as described in
113 [RFC4119], that is, a PIDF-LO. Location-by-value refers to a user
114 agent including a PIDF-LO as a body part of a SIP message, sending
115 that location object to another SIP element. Location-by-reference
116 refers to a user agent or proxy server including a URI in a SIP
117 message which can be exchanged by a location recipient for a
118 location object, in the form of a PIDF-LO.
120 As recited in RFC3693, location often must be kept private. The
121 location object (PIDF-LO) contains rules which are binding on the
122 location recipient and controls onward distribution and retention of
123 the location. This document describes the security and privacy
124 considerations that must be applied to location conveyed with SIP.
126 Often, location is sent from the User Agent Client to the User Agent
127 Server, or vice versa for purposes that are beyond the scope of this
128 document. Another use for location is location-based routing of a
129 SIP request, where the choice of the next hop (and usually, the
130 outgoing Request URI) is determined by the location of the UAC which
131 is in the message by-value or by-reference. This document describes
132 how location may be conveyed from the UAC, or a proxy acting on its
133 behalf, to a routing proxy. How the location is actually used to
134 determine the next hop or Request-URI is beyond the scope of this
135 document.
137 The Geolocation header is introduced to signify that location is
138 included in a SIP message to provide either a content identifier
139 (cid:) pointer to the body part containing the UAs PIDF-LO, or a
140 location-by-reference URI that may subsequently be "dereferenced" by
141 a using protocol (which may be SIP or another protocol).
143 In this document, we frequently refer to the "emergency case". This
144 refers to a specific, important use of sip location conveyance where
145 the location of the caller is used to determine which Public Safety
146 Answering Point (PSAP) should receive an emergency call request for
147 help (e.g. a call to 1-1-2 or 9-1-1). This is an example of
148 location-based routing. The location conveyed is also used by the
149 PSAP to dispatch first responders to the caller's location. There
150 are special security considerations which make the emergency case
151 unique, compared to a normal location conveyance within SIP.
153 2. Conventions used in this document
155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
156 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
157 "OPTIONAL" in this document are to be interpreted as described
158 in [RFC2119].
160 3. Mechanisms
162 3.1 Overview of SIP Location Conveyance
164 This document creates a new SIP header: Geolocation. The
165 Geolocation header contains either a URI which may be a "cid:" URI
166 (Content Identification, per [RFC2392], or a location-by-reference
167 URI to be dereferenced by a location recipient to retrieve the
168 location of the UAC.
170 Where the Geolocation header contains a "cid:", the URI points to a
171 message body that is in the form of a PIDF [RFC3863], which was
172 extended in [RFC4119] to include location, as a PIDF-LO. This is
173 location-by-value, the actual location information in the PIDF-LO is
174 included in the body of the message.
176 If the URI in the Geolocation header is a scheme other than "cid:",
177 another protocol operation is needed by the message recipient to
178 obtain the location of the target (UA). This is
179 location-by-reference. This document describes how a SIP presence
180 subscription [RFC3856] can be used as a dereference protocol.
182 The Geolocation header, either with the PIDF-LO in a body or as a
183 location-by-reference URI, may be included by a User Agent in a
184 message. A proxy server may assert location of the UA by inserting
185 the header, which must specify a location-by-reference URI. Since
186 body parts may not be inserted by a proxy server, location-by-value
187 cannot be inserted by a proxy.
189 This document describes an extension to PIDF-LO, the
190 "routing-query-allowed" element, defined in the 'usage-rules'
191 element. When set, this allows an element receiving location to
192 transmit the location to another element to obtain routing
193 information. When used in conjunction with the
194 "retransmission-allowed" element, the rule maker can control
195 distribution of the location information for location-based routing.
197 This document also creates a new option tag: Geolocation, to
198 indicate support for the Geolocation extension. A new error message
199 (424 Bad Location Information) is also defined in this document.
201 3.2 The Geolocation Header
203 This document creates and IANA registers a new SIP header:
204 Geolocation. The Geolocation header MUST contain one two types of
205 URIs:
207 o a location-by-reference URI, or
209 o a content-ID indicating where location is within the message body
210 of this message
212 A location-by-reference URI is a pointer to a record on a remote
213 node containing location of the location target, typically the
214 UA in this transaction.
216 A location-by-value content-ID (cid-url) [RFC2392] indicates which
217 message body part contains location for this UA.
219 The Geolocation header has the following BNF syntax:
221 Geolocation = "Geolocation" HCOLON (locationURI *(COMMA
222 locationURI))
223 locationURI = sip-URI / sips-URI / pres-URI / cidURI
224 / absoluteURI
225 cidURI = "cid:" content-id
227 content-id = addr-spec ; URL encoding of RFC3261 addr-spec
229 The content-ID (cid:) is defined in [RFC2392] to locate message body
230 parts. This URI MUST be present if location is by-value in a
231 message.
233 sip-URI, sips-URI and absoluteURI are defined according to RFC3261.
234 The pres-URI is defined in RFC 3859 [RFC3859].
236 Other protocols used in the Location URI MUST be reviewed against
237 the RFC3693 criteria for a using protocol.
239 [Editor's Note: The topic of how to control which protocols are
240 allowed in the URI is still contentious. There does seem to be
241 consensus to have the ABNF syntax not restrict the scheme of the
242 dereferencing protocol. This ABNF conforms with how similar
243 extensions are expressed in ABNF in RFC3261: the protocol's use
244 defined by the document is included explicitly, and an "open" (e.g.
245 absoluteURI) is included to allow any future protocol without
246 changing (i.e. updating) the ABNF, for example, in this document.
248 The text currently explicitly requires a Geopriv review of a new
249 proposed dereferencing protocol. This text is still subject to
250 consensus discussions and represents what we believe the direction
251 currently expressed by commenters.]
253 This document defines the Geolocation header as valid in:
255 INVITE [RFC3261],
256 REGISTER [RFC3261],
257 OPTIONS [RFC3261],
258 UPDATE [RFC3311],
259 MESSAGE [RFC3428],
260 SUBSCRIBE [RFC3265], and
261 NOTIFY [RFC3265]
263 Use of the header in BYE, INFO and REFER Methods is allowed,
264 although no purpose is known. Conveying location in a CANCEL, BYE,
265 ACK or PRACK is not defined. Discussing location using the PUBLISH
266 Request Method out of scope for this document.
268 The following table extends the values in Table 2&3 of RFC3261
269 [RFC3261].
271 Header field where proxy INV ACK CAN BYE REG OPT PRA
272 ----------------------------------------------------------------
273 Geolocation Rr ar o - - o o o -
275 Header field where proxy SUB NOT UPD MSG REF INF PUB
276 ----------------------------------------------------------------
277 Geolocation Rr ar o o o o o o -
279 Table 1: Summary of the Geolocation Header
281 The Geolocation header MAY be included in one of the above messages
282 by a User Agent. A proxy MAY add the Geolocation header, but MUST
283 NOT modify the contents of an existing Geolocation header.
284 [RFC3261] states message bodies cannot be added by proxies.
285 Therefore, a Geolocation header added by a proxy MUST specify
286 location-by-reference.
288 It is RECOMMENDED that only one Geolocation header (i.e. header
289 value) be in the same message. There MUST NOT be more than one
290 cid-url pointing to the same location message body (part) in a SIP
291 message.
293 Entities receiving location information MUST honor the usage element
294 rules per RFC4119. Such entities MUST NOT alter the rule set.
296 3.3 424 (Bad Location Information) Response Code
298 If a UAS or SIP intermediary detects an error
299 in a request message specific to the location information supplied
300 by-value or by-reference, a new 4XX level error is created here to
301 indicate a problem with the request message. This
302 document creates and IANA registers the new error code:
304 424 (Bad Location Information)
306 The 424 (Bad Location Information) response code is a rejection of
307 the location contents, within the original SIP Request. If the
308 location was sent by-value, the error indicates the location
309 information was malformed or not satisfactory for the recipient's
310 purpose. If the location was sent by-reference, the error indicates
311 that location could not be obtained using the URI. No further
312 action by the UAC is required. The UAC can use whatever means it
313 knows of to verify/refresh its location information before
314 attempting a new request that includes location. There is no
315 cross-transaction awareness expected by either the UAS or SIP
316 intermediary as a result of this error message.
318 This new error code will be IANA registered in Section 9.
320 More resolution of the error for which the 424 was generated MAY be
321 included in a Reason header [RFC3326]. For these more granular
322 location specific errors, the 'protocol' in the Reason header is
323 'Geolocation', defined in Section 3.4. RFC3326 states that the
324 Reason Header normally is not found in a response. This document
325 extends the use of Reason to include its use within a 424 response.
327 3.4 The Geolocation Reason Protocol
329 For use with the Reason header, this document defines and IANA
330 registers a new Reason Protocol per RFC3326:
332 Protocol Value Protocol Cause Reference
333 Geolocation Status RFCyyyy (i.e. this document)
335 Ed. Note: It has been agreed that Geopriv will create a new IANA
336 registry for the reason code.
338 3.5 The Geolocation Option Tag
340 This document creates and IANA registers one new option tag:
341 "geolocation". This option tag is to be used, per RFC 3261, in the
342 Require, Supported and Unsupported headers. Whenever a UA wants to
343 indicate it understands this SIP extension, the geolocation option
344 tag is included in a Supported header of the SIP message.
346 The purpose of the geolocation option-tag is to indicate support for
347 this extension in the Supported and Unsupported headers. Appearance
348 of the option tag in the Require header is a request for location to
349 be conveyed.
351 A UAC MUST NOT include this option tag in a Proxy-Require header,
352 due to the fact that the UAC is not likely to understand the
353 topology of the infrastructure, and therefore does not understand
354 which proxy will do the location-based routing function.
356 3.6 'routing-query-allowed' element in PIDF-LO
358 This document extends the 'usage-rules' element of RFC4119 to
359 include a new element, 'routing-query-allowed'. When
360 'routing-query-allowed' is set, the receiving element MAY forward
361 the location information to another element to obtain routing
362 information, even if 'retransmission-allowed' value is 'no'. By
363 default, the value MUST be assumed to be 'no'
365 The locPolicyType is extended to define this new element after
366 'note-well':
368
371 3.7 Using sip/sips/pres as a Dereference Protocol
373 A sip, sips or pres URI SHOULD be included in a Geolocation header
374 for the location-by-reference URI. When pres: is used, if the
375 resulting resolution, per [RFC3851], resolves to a sip: or sips:
376 URI, this section applies. Use of other protocols for dereferencing
377 of a pres: URI is not defined, and such use is subject to review
378 against RFC3693 using protocol criteria.
380 Dereferencing using sip or sips MUST be accomplished by treating the
381 URI as a presence URI and dereferencing is accomplished by a
382 SUBSCRIBE to a presence service per [RFC3856]. The resulting NOTIFY
383 will contain a PIDF, which MUST contain a PIDF-LO.
385 When used in this manner, SIP is a using protocol per [RFC3693] and
386 elements receiving location MUST honor the 'usage-element' rules as
387 defined in Section 3.4 above.
389 A dereference of a location-by-reference URI using SUBSCRIBE is not
390 violating a PIDF-LO 'retransmission-allowed' element value set to
391 'no', as the NOTIFY is the only message in this multi-message series
392 of transactions that contains the UAC's location, with the location
393 recipient being the only SIP element to receive location - which the
394 purpose of this extension: to convey location to a specific
395 destination.
397 4. Examples
399 Three examples of messages providing location are provided. One
400 shows location-by-value with geo-coordinates, one shows
401 location-by-value with civic location and the third shows
402 location-by-reference. The examples for (Geo format) are taken
403 from [RFC3825] and (Civic format) are taken from [ID-CIVIC] and are
404 for the exact same position on the Earth. The differences between
405 the two formats is within the of the examples.
406 Other than this portion of each PIDF-LO, the rest is the same for
407 both location formats.
409 4.1 Location-by-value (Coordinate Format)
411 This example shows an INVITE message with a coordinate, or geo
412 location. In this example, the SIP request uses a sips-URI
413 [RFC3261], meaning this message is TLS protected on a hop-by-hop
414 basis all the way to Bob's domain.
416 INVITE sips:bob@biloxi.example.com SIP/2.0
417 Via: SIP/2.0/TLS pc33.atlanta.example.com
418 ;branch=z9hG4bK74bf9
419 Max-Forwards: 70
420 To: Bob
421 From: Alice ;tag=9fxced76sl
422 Call-ID: 3848276298220188511@atlanta.example.com
423 Geolocation: cid:alice123@atlanta.example.com
424 Supported: geolocation
425 Accept: application/sdp, application/pidf+xml
426 CSeq: 31862 INVITE
427 Contact:
428 Content-Type: multipart/mixed; boundary=boundary1
429 Content-Length: ...
431 --boundary1
433 Content-Type: application/sdp
435 ...SDP here
437 --boundary1
439 Content-Type: application/pidf+xml
440 Content-ID: alice123@atlanta.example.com
442
443
448
449 2006-03-20T14:00:00Z
450
451
452
453
454
455 33.001111N
456 96.68142W
458
459
460
461
462 no
463 2006-03-24T18:00:00Z
465 DHCP
466 www.cisco.com
467
468
469
470
471
472 --boundary1--
474 The Geolocation header from the above INVITE...
476 Geolocation: cid:alice123@atlanta.example.com
478 ...indicates the content-ID location [RFC2392] within the multipart
479 message body of were location information is, with SDP being the
480 other message body part.
482 If the Geolocation header were this instead:
484 Geolocation:
486 ...this would indicate location by-reference was included in this
487 message. It is expected that any node wanting to know where user
488 alice123 is would subscribe to server5 to dereference the sips-URI.
489 The returning NOTIFY would contain Alice's location in a PIDF-LO, as
490 if it were included in a message body (part) of the original INVITE
491 here.
493 4.2 Location-by-value (Civic Format)
495 This example shows an INVITE message with a civic location. The
496 headers are shown as if the location was S/MIME encrypted, but the
497 unencrypted location information is shown for clarity.
499 INVITE sip:bob@biloxi.example.com SIP/2.0
500 Via: SIP/2.0/TCP pc33.atlanta.example.com
501 ;branch=z9hG4bK74bf9
502 Max-Forwards: 70
503 To: Bob
504 From: Alice ;tag=9fxced76sl
505 Call-ID: 3848276298220188511@atlanta.example.com
506 Geolocation: cid:alice123@atlanta.example.com
507 Supported: geolocation
508 Accept: application/sdp, application/pidf+xml
509 CSeq: 31862 INVITE
510 Contact:
511 Content-Type: multipart/mixed; boundary=boundary1
512 Content-Length: ...
514 --boundary1
516 Content-Type: application/sdp
518 ...SDP here
520 --boundary1
522 Content-Type: application/pkcs7-mime;
523 smime-type=enveloped-data; name=smime.p7m
524 ;the following would be encrypted, we show the unencrypted form here
525
526
531
532 2006-03-20T14:00:00Z
533
534
535
536
537 US
538 Texas
539 Colleyville
540 3913
541 Treemont
542 Circle
543 76034
544 Polk Place
545 1
546
547
548
549 no
550 2006-03-24T18:00:00Z
552 DHCP
553 www.cisco.com
554
555
556
557
558
559 --boundary1--
561 4.3 Location-by-reference
563 Here is an example of an INVITE with a location-by-reference URI,
564 sips: in this case, instead of a location-by-value PIDF-LO message
565 body part shown in Sections 4.1 and 4.2. It is up to the location
566 recipient to dereference Alice's location at the Atlanta LIS.
568 INVITE sip:bob@biloxi.example.com SIP/2.0
569 Via: SIP/2.0/TCP pc33.atlanta.example.com
570 ;branch=z9hG4bK74bf9
571 Max-Forwards: 70
572 To: Bob
573 From: Alice ;tag=9fxced76sl
574 Call-ID: 3848276298220188511@atlanta.example.com
575 Geolocation: sips:3sdefrhy2jj7@lis.atlanta.com
576 Supported: geolocation
577 Accept: application/sdp, application/pidf+xml
578 CSeq: 31862 INVITE
579 Contact:
581 ...SDP goes here as the only message body
583 5. SIP Element Behavior
585 Because a person's location is generally considered to be sensitive
586 in nature, privacy of the location information must be protected
587 when transmitting such information. Section 26 of [RFC3261] defines
588 the security functionality SIPS for transporting SIP messages with
589 either TLS or IPSec, and S/MIME for encrypting message bodies from
590 SIP intermediaries that would otherwise have access to reading the
591 clear-text bodies. SIP endpoints SHOULD implement S/MIME to encrypt
592 the PIDF-LO message body (part) end-to-end when the intended
593 recipient is the opposite UA. The SIPS-URI from [RFC3261] MUST be
594 implemented for message protection (message integrity and
595 confidentiality) and SHOULD be used when S/MIME is not used.
596 Possession of a dereferenceable location URI may be equivalent to
597 possession of the location information itself and thus TLS SHOULD be
598 used when sending location-by-reference.
600 A PIDF includes identity information. It is possible for the
601 identity in the PIDF to be anonymous. Implementations of this
602 extension should consider the appropriateness of including an
603 anonymous identity in the location information where a real identity
604 is not required. When using location-by-reference, it is
605 RECOMMENDED that the URI not contain any identifying information
606 (for example use 3fg5t5yqw@example.com rather than
607 alice@example.com)
609 The entities receiving location MUST obey the privacy
610 and security rules in the PIDF-LO as described in RFC4119, regarding
611 retransmission and retention.
613 Self-signed certificates SHOULD NOT be used for protecting PIDF,
614 as the sender does not have a secure identity of the recipient.
616 More than one location representation or format, for example: civic
617 and geo, MAY be included in the same message body part, but all MUST
618 point at the same position on the earth. Multiple representations
619 allow the recipient to use the most convenient representation of
620 location.
622 There MAY be more than one PIDF-LO in the same SIP message, but each
623 in separate message body parts. Each location body part MAY point at
624 different 2D positions on the earth (altitude not withstanding).
625 The meaning of such a construction is not defined, and may cause
626 confusion at the recipient.
628 5.1 UAC Behavior
630 A UAC may send location because it was requested to, to facilitate
631 location-based routing, or spontaneously (i.e. a purpose not defined
632 in this document but known to the UAC). A UAC MAY receive location
633 from the UAS because it requested it, or because the UAS sent it
634 spontaneously.
636 A UAC conveying location MUST include a Geolocation header with
637 either a location by-value indication (a cid-URL), or a location
638 by-reference indication (a dereferencable URI). A location body
639 sent without a Geolocation header MUST NOT occur. The UAC
640 supporting this extension MUST include a Supported header with the
641 geolocation option tag.
643 The presence of the geolocation option tag in a Supported header
644 without a Geolocation header in the same message informs a receiving
645 SIP element the UAC understands the concept of location, but it does
646 not know its location at this time. Certain scenarios exist
647 (location-based routing) in which location is required in a message
648 in order to route the message properly. This affects how a UAS or
649 SIP server reacts to such a message.
651 This option tag SHOULD NOT be used in the Proxy-Require header.
653 If the UAC requests the location of the UAS, it MAY include the
654 option tag in the Require header of the request.
656 The behavior of the UAC receiving location is the same as the UAS,
657 as below.
659 5.2 UAS Behavior
661 If the geolocation option tag is present in the Supported header of
662 a request, the UAS will look to the Geolocation header to see if
663 location has been conveyed by-value in a message body (part) or
664 by-reference, requiring an additional dereference transaction. If
665 the by-reference URI is sip:, sips: or pres:, the UAS will initiate
666 a SUBSCRIBE to the URI provided to retrieve the PIDF-LO of the UAC
667 per [RFC3856]. If successful, the PIDF-LO of the UAC will be
668 returned in the NOTIFY request from the server.
670 A Require header with the geolocation option tag indicates that the
671 UAC requests the UAS' location.
673 The UAS behavior in sending location is the same as the UAS as
674 above.
676 5.3 Proxy Behavior
678 [RFC3261] states message bodies cannot be added by proxies. A
679 PIDF-LO MAY be read in transit, if visible to the proxy. A proxy
680 MAY add the Geolocation header in transit. A proxy MAY read the
681 Geolocation header in transit if present, and MAY use the contents
682 of the header to make location-based routing decisions.
684 More than one geolocation header in a message is permitted, but its
685 meaning is undefined. A proxy inserting a Geolocation header when
686 there already is one risks confusing the recipient and SHOULD NOT be
687 done.
689 Proxies receiving location where the proxy performs location-based
690 routing may need to consult external databases or systems to
691 determine the route. Transmission of the location information
692 (which SHOULD NOT reveal identity, even if the proxy knows the
693 identity) is governed by the 'retransmission-allowed' and
694 'routing-query-allowed':
696 Retransmission-allowed Routing-query-allowed Transmission for Query
697 ---------------------- --------------------- ----------------------
698 "no" or not present "no" or not present Not Allowed
699 "no" or not present "yes" Allowed
700 "yes" not present Allowed
701 "yes" "no" Not Allowed
702 "yes" "yes" Allowed
704 If transmission is not allowed per the above, the proxy may provide
705 a suitable error response (424 Bad Location MAY be used).
707 6. Special Considerations for Emergency Calls
709 Emergency calls (1-1-2, 9-1-1, etc.) need location for two reasons:
711 1. Location is needed to route the call to the correct Public Safety
712 Answering Point (PSAP), and
714 2. Location is needed by the PSAP to send responders to the location
715 of the caller when the caller cannot accurately describe where
716 s/he is
718 While all of the privacy concerns for location apply to emergency
719 calls, it is not acceptable for a security mechanism in place to
720 support confidentiality of the location to cause an emergency call
721 to be misrouted, or not supply location when it is needed.
722 Therefore, some of the behaviors of elements in the path are
723 different when used with an emergency call.
725 Recognizing which calls are emergency calls is beyond the scope of
726 this document. When an emergency call is placed, location is
727 normally provided by the UAC. Since emergency calls must be routed
728 based on location (and indeed, in some jurisdictions, there may be
729 several steps to such routing), the location must be visible to
730 proxies along the path. Thus S/MIME protection of location MUST NOT
731 be used. TLS protection of location SHOULD be used, however, if
732 establishment of the TLS connection fails, the call set-up
733 operation, including location conveyance, MUST be retried without
734 TLS.
736 Both the "retransmission-allowed" and "routing-query-allowed" SHOULD
737 be set to "yes". Querying for routing may be performed by proxies
738 providing a routing service for emergency calls even if
739 retransmission-allowed or routing-query-allowed is set to "no" or is
740 not present.
742 While many jurisdictions force a user to reveal their location
743 during an emergency call set-up, there are a small, but real, number
744 of jurisdictions that allow a user to configure their calling device
745 to disable providing location, even during emergency calling. This
746 capability MUST be configurable, but is NOT RECOMMENDED as the
747 default configuration of any UA. Local policies will dictate this
748 ability.
750 7. Geopriv Privacy Considerations
752 Transmitting location information is considered by most to be highly
753 sensitive information, requiring protection from eavesdropping,
754 tracking, and altering in transit. [RFC3693] articulates rules to
755 be followed by any protocol wishing to be considered a Geopriv
756 "using protocol", specifying how a transport protocol meetings
757 those rules. This section describes how SIP as a using protocol
758 meets those requirements.
760 Quoting requirement #4 of [RFC3693]:
762 "The using protocol has to obey the privacy and security
763 instructions coded in the location object and in the
764 corresponding Rules regarding the transmission and storage
765 of the LO."
767 This document requires that SIP entities sending or receiving
768 location MUST obey such instructions.
770 Quoting requirement #5 of [RFC3693]:
772 "The using protocol will typically facilitate that the keys
773 associated with the credentials are transported to the
774 respective parties, that is, key establishment is the
775 responsibility of the using protocol."
777 [RFC3261] and the documents it references define the key
778 establishment mechanisms.
780 Quoting requirement #6 of [RFC3693]:
782 "(Single Message Transfer) In particular, for tracking of
783 small target devices, the design should allow a single
784 message/packet transmission of location as a complete
785 transaction."
787 When used for tracking, a simple NOTIFY or UPDATE normally is
788 relatively small, although the PIDF itself can get large. Normal
789 RFC3261 procedures of reverting to TCP when the MTU size is exceeded
790 would be invoked.
792 8. Security Considerations
794 Conveyance of physical location of a UAC raises privacy concerns,
795 and depending on use, there may be authentication and integrity
796 concerns. This document calls for conveyance to normally be
797 accomplished through secure mechanisms (like S/MIME or TLS). In
798 cases where a session set-up is routed based on the location of the
799 UAC initiating the session or SIP MESSAGE, securing the by-value
800 location with an end-to-end mechanism such as S/MIME is problematic,
801 because one or more proxies on the path need the ability to read the
802 information to route the message appropriately. Securing the
803 location hop-by-hop, using TLS, protects the message from
804 eavesdropping and modification, but exposes the information to all
805 proxies on the path as well as the endpoint. In most cases, the UAC
806 does not know the identity of the proxy or proxies providing
807 location-based routing services, so that end to middle solutions may
808 not be appropriate either.
810 When the UAC is the source of the location information, which is
811 RECOMMENDED, it can decide whether to reveal its location using
812 hop-by-hop methods. UAC implementations MUST make such capabilities
813 conditional on explicit user permission, and SHOULD alert a user
814 that location is being conveyed. Emergency calls have their own
815 rules in this regard, as detailed in Section 6. Proxies inserting
816 location for location-based routing are unable to meet this
817 requirement, and such use is NOT RECOMMENDED. Proxies conveying
818 location using this extension MUST have the permission of the target
819 to do so.
821 9. IANA Considerations
823 9.1 IANA Registration for the SIP Geolocation Header
825 The SIP Geolocation header is created by this document, with its
826 definition and rules in Section 3.2 of this document.
828 9.2 IANA Registration for New SIP Option Tag
830 The SIP option tag "Geolocation" is created by this document, with
831 the definition and rule in Section 3.5 of this document.
833 9.3 IANA Registration for Response Code 4XX
835 Reference: RFC-XXXX (i.e. this document)
836 Response code: 424
837 Default reason phrase: Bad Location Information
839 This SIP Response code is defined in section 3.3 of this document.
841 9.4 IANA Registration of the Geolocation Reason Protocol
843 The Reason Protocol value "Geolocation" is created by this document,
844 with the definition and values in Section 3.4 if this document
846 10. Acknowledgements
848 To Dave Oran for helping to shape this idea. To Jon Peterson and
849 Dean Willis on guidance of the effort. To Allison Mankin, Dick
850 Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom,
851 Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith
852 Drage, Marc Linsner Martin Thomson, Mike Hammer and Paul Kyzivat for
853 constructive feedback.
855 11. References
857 11.1 References - Normative
859 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
860 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
861 Session Initiation Protocol", RFC 3261, May 2002.
863 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
864 "Geopriv Requirements", RFC 3693, February 2004
866 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
867 Format", RFC 4119, December 2005
869 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
870 Requirement Levels", RFC 2119, March 1997
872 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource
873 Locators", RFC 2393, August 1998
875 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J.
876 Peterson, "Presence Information Data Format (PIDF)", RFC
877 3863, August 2004
879 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session
880 Initiation Protocol (SIP)", RFC 3856, August 2004
882 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859,
883 August 2004
885 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,
886 D. Gurle, "Session Initiation Protocol (SIP) Extension for
887 Instant Messaging" , RFC 3428, December 2002
889 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
890 Method", RFC 3311, October 2002
892 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
893 Event Notification", RFC 3265, June 2002.
895 [RFC3326] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header
896 Field for the Session Initiation Protocol (SIP)", RFC 3326
897 Reason Header, December 2002
899 11.2 References - Informative
901 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
902 Configuration Protocol Option for Coordinate-based Location
903 Configuration Information", RFC 3825, July 2004
905 [ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol
906 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
907 Information ", draft-ietf-geopriv-dhcp-civil-09, "work in
908 progress", January 2006
910 Author Information
912 James Polk
913 Cisco Systems
914 3913 Treemont Circle 33.00111N
915 Colleyville, Texas 76034 96.68142W
917 Phone: +1-817-271-3552
918 Email: jmpolk@cisco.com
920 Brian Rosen
921 NeuStar, Inc.
922 470 Conrad Dr. 40.70497N
923 Mars, PA 16046 80.01252W
924 US
926 Phone: +1 724 382 1051
927 Email: br@brianrosen.net
929 Appendix A. Requirements for SIP Location Conveyance
931 The following subsections address the requirements placed on the
932 user agent client, the user agent server, as well as SIP proxies
933 when conveying location. There is a motivational statement below
934 each requirements that is not obvious in intent
936 A.1 Requirements for a UAC Conveying Location
938 UAC-1 The SIP INVITE Method [RFC3261] must support location
939 conveyance.
941 UAC-2 The SIP MESSAGE method [RFC3428] must support location
942 conveyance.
944 UAC-3 SIP Requests within a dialog should support location
945 conveyance.
947 UAC-4 Other SIP Requests may support location conveyance.
949 UAC-5 There must be one, mandatory to implement means of
950 transmitting location confidentially.
952 Motivation: interoperability
954 UAC-6 It must be possible for a UAC to update location conveyed
955 at any time in a dialog, including during dialog
956 establishment.
958 Motivation: in case a UAC has moved prior to the establishment of a
959 dialog between UAs, the UAC must be able to send new location
960 information. In the case of location having been conveyed,
961 and the UA moves, it needs a means to update the conveyed to
962 party of this location change.
964 UAC-7 The privacy and security rules established within [RFC3693]
965 that would categorize SIP as a 'using protocol' must be met.
967 UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for
968 location conveyance within SIP, whether included by-value or
969 by-reference.
971 Motivation: interoperability with other IETF location protocols and
972 mechanisms
974 UAC-9 There must be a mechanism for the UAC to request the UAS send
975 its location
977 UAC-10 There must be a mechanism to differentiate the ability of the
978 UAC to convey location from the UACs lack of knowledge of its
979 location
981 Motivation: Failure to receive location when it is expected can be
982 because the UAC does not implement this extension, or it can
983 be that the UAC implements the extension, but does not know
984 where it is. This may be, for example, due to the failure of
985 the access network to provide a location acquisition
986 mechanisms the UAC understands. These cases must be
987 differentiated.
989 UAC-11 It must be possible to convey location to proxy servers
990 along the path.
992 Motivation: Location-based routing.
994 A.2 Requirements for a UAS Receiving Location
996 The following are the requirements for location conveyance by a user
997 agent server:
999 UAS-1 SIP Responses must support location conveyance.
1001 UAS-2 There must be a unique 4XX response informing the UAC it did
1002 not provide applicable location information.
1004 In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS
1006 A.3 Requirements for SIP Proxies and Intermediaries
1008 The following are the requirements for location conveyance by a SIP
1009 proxies and intermediaries:
1011 Proxy-1 Proxy servers must be capable of adding a Location header
1012 during processing of SIP requests.
1014 Motivation: Provide the capability of network assertion of location
1015 when UACs are unable to do so, or when network assertion is
1016 more reliable than UAC assertion of location
1018 Note: Because UACs connected to sip signaling networks may have
1019 widely varying access network arrangements, including VPN
1020 tunnels and roaming mechanisms, it may be difficult for a
1021 network to reliably know the location of the endpoint. Proxy
1022 assertion of location is NOT RECOMMENDED unless the sip
1023 signaling network has reliable knowledge of the actual
1024 location of the targets.
1026 Proxy-2 There must be a unique 4XX response informing the UAC it
1027 did not provide applicable location information.
1029 Appendix B. Changes from Prior Versions
1031 [NOTE TO RFC-EDITOR: If this document is to be published as an RFC,
1032 this Appendix B is to be removed prior to that event.]
1034 This is a list of the changes that have been made from the SIP WG
1035 version -03 to this version -04:
1037 - removed the inappropriate 2119 language from the Requirements
1038 section.
1040 - removed the old Section 2., which was a Location in a header vs.
1041 in a body artifact from the original versions of the document.
1043 - Added a new Geopriv (or Privacy) Considerations
1045 - Changed the ABNF to reflect discussion on how restrictive the
1046 location-by-reference schemes should be, with an added "Editor's
1047 Note" discussing the issues being faced on this point.
1049 - Changed the "Location" header and option-tag to "Geolocation"
1050 header and option-tag, due to it being pointed out that there is a
1051 conflicting HTTP header called "Location".
1053 - Added new element to PIDF-LO 'routing-query-allowed'
1055 - Stipulated the Reason Header can be used in the 424 Response
1056 Message
1058 - added SUBSCRIBE and NOTIFY as Methods for location conveyance when
1059 used to dereference a sip:, sips: or pres: location-by-reference
1060 URI
1062 - Added OPTIONS Method for a UAC to request the location of a UAS
1063 with a Require header geolocation option-tag.
1065 This is a list of the changes that have been made from the SIP WG
1066 version -02 to this version -03:
1068 - general clean-up of some of the sections
1070 - removed the message examples from the UPDATE, MESSAGE and REGISTER
1071 sections, as these seemed to be making the doc less readable, and
1072 not more readable
1074 - removed the "unknown" option tag, as it was not needed with a
1075 certain combination of the Supported and Location headers
1077 - clarified the location option tag usage in Supported, Require,
1078 Unsupported, and that it shouldn't be used in Proxy-Require, and
1079 why not.
1081 - Added a basic message flow to the basic operation section (Section
1082 4) to aid in understanding of this SIP extension.
1084 - Added a message routing flow, which is based on the location of
1085 the requestor to show how a SIP server can make a routing decision
1086 to a destination based on where the UAC is.
1088 - Articulated how a UAS concludes a UAC understands this extension,
1089 yet does not know its location to provide to the UAS. This is
1090 helpful in those times where an intermediary will act differently
1091 based on whether or not a UAC understands this extension, and
1092 whether or not the UAC includes its location in the request.
1094 - Corrected the erroneous text regarding an Unsupported header being
1095 in a 424 response. It belongs in a 420 response. (Section 5.1)
1097 - Corrected the BNF (I hope)
1099 - Corrected some text in Section 5 that read like this document was
1100 an update to RFC 3261.
1102 This is a list of the changes that have been made from the SIP WG
1103 version -01 to this version -02:
1105 - streamlined the doc by removing text (ultimately removing 42 pages
1106 of text).
1108 - Limited the scope of this document to SIP conveyance, meaning only
1109 how SIP can push location information.
1111 - reduced emergency calling text to just a few paragraphs now that
1112 the ECRIT WG is taking most of that topic on.
1114 - greatly reduced the number of requirements in this version.
1116 - changed the requirements groups from "UA-to-UA", "UA-to-Proxy",
1117 etc to "UAC Reqs", "UAS-Reqs" and "Proxy-Reqs" to focus on what is
1118 being asked of each SIP element.
1120 - Removed the full SIP message examples.
1122 - completed the ABNF for the Location header, including a cid-url to
1123 point at a message body part to help in parsing for location.
1125 - Deleted the call for a new 425 (Retry Location) response code, as
1126 it appears this can easily be used to spoof a UA into providing
1127 where it is inadvertently, even if the intent is legitimate by the
1128 UAC.
1130 This is a list of the changes that have been made from the SIP WG
1131 version -00 to this version -01:
1133 - cleaned up a lot of loose ends in the text
1135 - created a new Location header to convey many means (location is in
1136 the body - even if not viewable, which location format is present,
1137 which format is requested in a query, how to request more than one
1138 location format in a query, whether the UAC understands location
1139 at all, if the UA knows its location, how to push location from
1140 one UA to through a second to a third UA, etc).
1142 - added the ability to convey location by-reference, but only under
1143 certain conditions.
1145 - Added support for the OPTIONS Request to query a server for the
1146 UAC's location, through the use of the new Location header.
1148 - moved both new Response code sections forward in the document for
1149 their meaning to be clearer, earlier for necessary discussion.
1151 - Changed the message flows to only have the pertinent message
1152 headers shown for brevity.
1154 - Added text to the SUB/NOT section showing how and why the location
1155 of a UA can be refreshed or updated with an interval, or by a
1156 trigger.
1158 This is a list of the changes that have been made from the SIPPING
1159 WG version -02 to this SIP WG item document version -00:
1161 - Changed which WG this document is in from SIPPING to SIP due to
1162 the extension of the protocol with new Response codes (424 and
1163 425) for when there is an error involving the LO message body.
1165 - Moved most of the well formed SIP messages out of the main body of
1166 this document and into separate appendixes. This should clean up
1167 the document from a readability point of view, yet still provide
1168 the intended decode examples to readers of this document who wish
1169 that level of detail per flow. The first few flows still have the
1170 decoded SIP messages (unencrypted and encrypted).
1172 - Removed some flow examples which no longer made sense
1174 - Changed all references of "ERC" (Emergency Response Center) to
1175 "PSAP" (Public Safety Answering Point) as a result of discussion
1176 within the new ECRIT WG to define a single term
1178 This is a list of the changes that have been made from the sipping-
1179 01 working group version of this effort to the sipping-02 version:
1181 - added requirements for 2 new 4XX error responses (Bad Location
1182 Information) and (Retry Location Body)
1184 - added "Bad Location Information" as section 8.6
1186 - added "Retry Location Body " as section 9.3
1188 - added support for session mode to cover packet sizes larger than
1189 the single packet limit of 1300 bytes in the message body
1191 - added requirement for a SIP entity to SUBSCRIBE to another for
1192 location information
1194 - added SUBSCRIBE and NOTIFY as section 8.5
1196 - added requirement to have user turn off any tracking created by
1197 subscription
1199 - removed doubt about which method to use for updating location
1200 after a INVITE is sent (update)
1202 - cleaned up which method is to be used if there is no dialog
1203 existing (message)
1205 - removed use of reINVITE to convey location
1207 - clarified that UAs include element of PIDF-LO when
1208 placing an emergency call (to inform PSAP who supplied Location
1209 information)
1211 - updated list of open issues
1213 - added to IANA Considerations section for the two new 4XX level
1214 error responses requested in the last meeting
1216 This is a list of the changes that have been made from the sipping-
1217 00 working group version of this ID to the sipping-01 version:
1219 - Added the offered solution in detail (with message flows,
1220 appropriate SIP Methods for location conveyance, and
1222 - Synchronized the requirements here with those from the Geopriv
1223 Working Group's (attempting to eliminate overlap)
1225 - Took on the task of making this effort the SIP "using protocol"
1226 specification from Geopriv's POV
1228 - Refined the Open Issues section to reflect the progress we've made
1229 here, and to indicate what we have discovered needs addressing,
1230 but has not been to date.
1232 This is a list of the changes that have been made from the -01
1233 individual submission version to the sipping-00 version of this ID:
1235 - Brian Rosen was brought on as a co-author
1237 - Requirements that a location header were negatively received in
1238 the previous version of this document. AD and chair advice was to
1239 move all location information into a message body (and stay away
1240 from headers)
1242 - Added a section of "emergency call" specific requirements
1244 - Added an Open Issues section to mention what hasn't been resolved
1245 yet in this effort
1247 This is a list of the changes that have been made from the
1248 individual submission version -00 to the -01 version
1250 - Added the IPR Statement section
1252 - Adjusted a few requirements based on suggestions from the
1253 Minneapolis meeting
1255 - Added requirements that the UAC is to include from where it
1256 learned its location in any transmission of its LI
1258 - Distinguished the facts (known to date) that certain jurisdictions
1259 relieve persons of their right to privacy when they call a PSAP,
1260 while other jurisdictions maintain a person's right to privacy,
1261 while still others maintain a person's right to privacy - but only
1262 if they ask that their service be set up that way.
1264 - Made the decision that TLS is the security mechanism for location
1265 conveyance in emergency communications (vs. S/MIME, which is still
1266 the mechanism for UA-to-UA non-emergency location conveyance
1267 cases).
1269 - Added the Open Issue of whether a Proxy can insert location
1270 information into an emergency SIP INVITE message, and some of the
1271 open questions surrounding the implications of that action
1273 - added a few names to the acknowledgements section
1275 Intellectual Property Statement
1277 The IETF takes no position regarding the validity or scope of any
1278 Intellectual Property Rights or other rights that might be claimed
1279 to pertain to the implementation or use of the technology described
1280 in this document or the extent to which any license under such
1281 rights might or might not be available; nor does it represent that
1282 it has made any independent effort to identify any such rights.
1283 Information on the procedures with respect to rights in RFC
1284 documents can be found in BCP 78 and BCP 79.
1286 Copies of IPR disclosures made to the IETF Secretariat and any
1287 assurances of licenses to be made available, or the result of an
1288 attempt made to obtain a general license or permission for the use
1289 of such proprietary rights by implementers or users of this
1290 specification can be obtained from the IETF on-line IPR repository
1291 at http://www.ietf.org/ipr.
1293 The IETF invites any interested party to bring to its attention any
1294 copyrights, patents or patent applications, or other proprietary
1295 rights that may cover technology that may be required to implement
1296 this standard. Please address the information to the IETF at
1297 ietf-ipr@ietf.org.
1299 Disclaimer of Validity
1301 This document and the information contained herein are provided on
1302 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
1303 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
1304 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
1305 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1306 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1307 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1309 Copyright Statement
1311 Copyright (C) The Internet Society (2006). This document is subject
1312 to the rights, licenses and restrictions contained in BCP 78, and
1313 except as set forth therein, the authors retain all their rights.
1315 Acknowledgment
1317 Funding for the RFC Editor function is currently provided by the
1318 Internet Society.