idnits 2.17.1 draft-marshall-geopriv-lbyr-requirements-01.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, updated by RFC 4748 on line 570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 594. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (March 4, 2007) is 6262 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) == Missing Reference: 'TBD' is mentioned on line 463, but not defined == Unused Reference: 'I-D.hardie-ecrit-lost' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ecrit-requirements' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ecrit-security-threats' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-geopriv-dhcp-civil' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sipping-toip' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC3351' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC3825' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'RFC3860' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'RFC3966' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'RFC4103' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'RFC4119' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'RFC4412' is defined on line 539, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-requirements-12 == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-security-threats-03 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-00 == Outdated reference: A later version (-09) exists of draft-ietf-sipping-toip-07 -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) Summary: 1 error (**), 0 flaws (~~), 19 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GeoPriv R. Marshall, Ed. 3 Internet-Draft TCS 4 Intended status: Standards Track March 4, 2007 5 Expires: September 5, 2007 7 Requirements for a Location-by-Reference Mechanism used in Location 8 Configuration and Conveyance 9 draft-marshall-geopriv-lbyr-requirements-01 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 months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 5, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines terminology and enumerates requirements for a 43 location-by-reference approach to location configuration and 44 conveyance interactions useful for emergency call routing for voice- 45 over-IP (VoIP) and general Internet multimedia systems, where 46 Internet protocols are used end-to-end. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 5 52 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4. Examples of various LRI Model . . . . . . . . . . . . . . . . 8 55 5. High-Level Requirements . . . . . . . . . . . . . . . . . . . 12 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 58 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 59 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 61 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 62 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 64 Intellectual Property and Copyright Statements . . . . . . . . . . 21 66 1. Introduction 68 This document identifies the individual requirements underlying how a 69 Location-by-Reference (LbyR) mechanism is to be used over the 70 Internet, applied to either a Conveyance protocol or to a 71 Configuration protocol. The LbyR approach is in contrast to the 72 Location-by-Value (LbyV) model, which uses a "location object" (e.g., 73 PIDF-LO) exclusively. Examples using the Location-by-Value method 74 are beyond the scope of this document. 76 A mechanism for either (or both) location configuration and location 77 conveyance may rely on either a location-by-value approach, 78 containing and transporting location information along every leg of 79 the signaling path, or alternatively, a different approach, using a 80 location-by-reference technique, which may be used to reference a 81 location with some identifier, and to de-reference the location when 82 needed for a location-based decision. 84 [http://www.ietf.org/internet-drafts/ 85 draft-ietf-sip-location-conveyance-07.txt] For an application of LbyR 86 Conveyance, we choose to use the example of SIP signaling within an 87 emergency services context, though we also talk about LbyR in a more 88 general sense. In this case, a SIP user agent, or SIP proxy server 89 acting on behalf of a user agent, to another user agent via the SIP 90 protocol [RFC3261]. In place of the actual value for a "Location", a 91 Location Reference ID (LRI) is used to represent the "value" of the 92 location, stored in some Internet-connected host, which we call a 93 location server. 95 For a LbyR Configuration protocol mechanism, even for the emergency 96 service context mentioned, many different protocol choices exist. 97 These include DHCP, LLDP-MED, and several Layer 7 protocols being 98 considered for standardization. Regardless of the variety of 99 choices, the general concept of how LbyR is used for configuration, 100 is not specific to any particular protocol choice. 102 A Location which is referenced can be either Geographic location [RFC 103 3693] (e.g., lat/lon), or a Civic location (e.g., street address). 105 We reintroduce a few basic entities [RFC3693] into the Location-by- 106 Reference discussion. These include a "target" as the entity whose 107 location is being transmitted, (e.g., a user agent's (UA) location. 108 A "using protocol", defined as how a "location server" transmits a 109 "location reference identifier" to a "location recipient". Privacy 110 of a target's location, with repect to identity is important to 111 protect, hence all examples shown assume that any user identity 112 associated with the target is not included with location. 114 Location can be pushed from one host to another, as part of a 115 signaling protocol, in order to be used for location-based routing 116 (or other purposes, outside the scope here), or it can alternatively 117 be queried via a client request to a server which provides location 118 [ref. drafft-sip-conveyance- TBD]. In the case of LbyR Conveyance, 119 the actual location (i.e., location object) never gets pushed along, 120 but is replaced by a Location Reference Identifier. In the case of a 121 client which queries a server for location, the query is either to 122 obtain a Location Reference Identifier, or to obtain an actual 123 Location (e.g., location object) based the input of an LRI in the 124 query. 126 The draft-sip-conveyance- document details how SIP proxies treat LbyV 127 or LbyR scenarios for conveying location via the SIP protocol. 129 Whereas location objects are readily consumable by the hosts that 130 using protocols deliver to, a Location Reference ID must first go 131 through a dereference step in order to be useful. 133 In our SIP example, for LbyR, instead of having a content identifier 134 (cid:) pointing to a location object within a SIP body, the LRI is 135 carried in the Geolocation header of a SIP message which is used to 136 get a location via a dereference. 138 A common example use case is the "emergency services call" case, 139 where an request for emergency services is initiated over the 140 Internet via the SIP protocol (i.e., a '9-1-1' or '1-1-2' call). In 141 order to route the call to the appropriate PSAP, the UA client 142 location is required. 144 This document uses as a baseline scenario, the example of an 145 emergency call, where an request for emergency services is initiated 146 over the Internet using the SIP protocol (e.g., a '9-1-1' or '1-1-2' 147 call). In order to route the call to the appropriate PSAP, since 148 PSAPs are divided regionally, the UA client location is required. 150 We first define terminology in Section 3. The document then outlines 151 baseline requirements (Section 5), around the referencing and 152 dereferencing of location via some location identifier in lieu of the 153 emergency caller's actual location. 155 Identification of the caller, as associated information to location 156 or location reference, either in conveyance or configuration, is out 157 of scope in this document. 159 Location-by-reference is a mechanism which is in use in VoIP 9-1-1 160 systems at the time of this writing, and justified based on the 161 requirements listed in this document. 163 2. Requirements Terminology 165 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 166 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 167 and "OPTIONAL" in this document are to be interpreted as described in 168 RFC 2119 [RFC2119]. 170 3. Terminology 172 3.1. Terms 174 Several of the terms presented below are based on RFC3693, and in 175 some cases, extended to include additional language to support the 176 Location-by-Reference model. 178 Dereference Protocol: A protocol which is used to query a Location 179 server based on an LRI as input. 181 Location Reference Identifier (LRI): An identifier (e.g., URI) which 182 is a pointer to a target's location record on a remote host (e.g., 183 location server), and is used by a dereferencing protocol for 184 retrieval of that specific location. 186 Location Server (LS): A network host which is designed to store 187 location and to provide that same location to appropriate location 188 client requests. May also be referred to as a Location 189 Information Server (LIS). 191 LoST Mapping Server (LMS): A network host which provides a URI 192 response based on input of a location and service identifier [ref. 193 draft-ecrit-lost-]. 195 Using Protocol: A protocol that carries a Location Object or an 196 Location Reference Identifier (i.e., LRI). 198 Target: A person or other entity whose location is communicated by a 199 Geopriv Location Object. 201 Location Recipient (LR): The entity that receives location 202 information. It may have asked for this location explicitly (by 203 sending a query containing an LRI to a location server), or it may 204 receive this location asynchronously. Also may be referred to as 205 a Dereference client within this document, in the context of the 206 Location-by-Reference model. 208 Location Server (LS): The entity to which a LG publishes location 209 objects, the recipient of queries from location receivers, and the 210 entity that applies rules designed by the rule maker. Also may be 211 referred to as a Dereference server within this document, in the 212 context of the Location-by-Reference model. 214 Location: A geographic identification assigned to a region or 215 feature based on a specific coordinate system, or by other precise 216 information such as a street number and name. It can be either a 217 civic or geographic location. 219 Civic location: A described location based on some reference system, 220 such a jurisdictions or postal delivery. A street address is a 221 common example. 223 Geographic location: A reference to a point which is able to be 224 located as described by a set of defined coordinates within a 225 geographic coordinate system, such as latitude and longitude 226 within the WGS-84 datum. For example, 2-D geographic location is 227 defined as an (x,y) coordinate value pair according to the 228 distance north or south of the equator and east or west of the 229 prime meridian. 231 Location-by-Value: The mechanism of representing location either in 232 conveyance protocols or configuration protocols as fully 233 specified, (i.e., including the actual location value itself). 235 Location-by-Reference: The mechanism of representing location either 236 in conveyance protocols or configuration protocols as an 237 identifier which refers to a fully specified location, (i.e., 238 including a pointer to the actual location value itself). 240 4. Examples of various LRI Model 242 To support the referencing or de-referencing of a location, it is 243 appropriate to describe a diagram consisting of network elements 244 around which this might be done. These elements include, the UA 245 (User Agent), P (Proxy), LS (Location Server), and a UA at the PSAP 246 (UA2). 248 This section outlines which entities will be considered in the 249 referernce/dereference scenarios discussed. 251 252
254 | | 260 +--------+ +--------+ 262 Figure 1: Framework for referencing or de-referencing location in a 263 SIP session. 265 Above figure shows simplest LRI interaction, when target happens to 266 also be the Location Recipient [ref. RFC3693 terms] 268 +--------+ +--------+ +--------+ 269 | | | | | | 270 | Target |<----------acquire LO---------| LS |<--deref--| LR | 271 | | | | LRI | | 272 +--------+ +--------+ +--------+ 273 | | 274 +----------------convey LRI--------------------------------->+ 276 Figure 2: Setup showing LRI indirection. 278 The above interaction reduces to two basic interactions: 1. Location 279 provision from LS/LIS to target by reference (LRI). 2. Location 280 indirection by the LS/LIS, at the request of the Target. Location 281 updates, are possible in either case. 283 +--------+ +--------+ +--------+ 284 | | | | | |-------LO------+ 285 | Target |<........>| LG |--LI/LO-->| LS/DS | | 286 | | | | | |<---LRI---+ | 287 +--------+ +--------+ +--------+ | | 288 | | 289 | v 290 +--------+ +--------+ +--------+ 291 | | | | | | 292 | LRG |---LRI--->| LT |--LRI-->| LR/DC | 293 | | | | | | 294 +--------+ +--------+ +--------+ 296 Figure 3: General Setup - LG interaction. 298 Definitions: Target, LG, LR, LI, LO as in RFC 3693. LRG = Location 299 Reference Generator (creates reference) LT = Location Transmitter 300 (one party to Conveyance Protocol) DS/DC = Dereference Server / 301 Client Protocols: Dereference Protocol is between DS and DC 302 Conveyance Protocol is between LT and LR 303 +--------+ 304 | | 305 +--------------| LS |-----------------------------------+ 306 | | | | 307 | + -------+ | 308 LCP ^ LDP 309 | LDP | 310 V V V 311 +--------+ +--------+ +--------+ +--------+ 312 | | | | | | | | 313 | UA1 |--------->| P1 |--------->| P2 |--------->| UA2 | 314 | | | | | | | | 315 +--------+ +--------+ +--------+ +--------+ 316 ^ 317 LMP 318 V 319 +--------+ 320 | | 321 | LMS | 322 | | 323 +--------+ 325 Figure 4: Example of a SIP call. 327 Definitions: LS = Location Server (as in RFC 3693) LCP = Location 328 Configuration Protocol LDP = Location Dereference Protocol LMP = 329 Location Mapping Protocol Sequence: 1. UA1 acquires LRI from its LS 330 (acting as LRG) 2. UA1 sends an INVITE to a service URN via P1 3. 331 P1 dereferences the LRI and uses it to get a URI from the LMS 4. UA2 332 may also wish to dereference the LRI, e.g., to get the current 333 location of UA1. 335 Figure 1 shows the interaction between the entities involved in the 336 call, as to how location is referenced and subsequently de- 337 referenced. The figure proposes that location reference is conveyed 338 from the endpoint-to-endpoint via each middlebox (SIP Proxy), and 339 undergoes a de-referencing operation at each step. The figure also 340 depicts a LMS (Location-to-Mapping Server) element which is used to 341 determine the next target destination, based on the de-referenced 342 location. 344 At the PSAP, the end device also receives a location reference, (as 345 indicated in this figure), and executes a de-reference quiery. 347 Various potential interactions between the entities depicted in 348 Figure 1 are described below: 350 1. Location information might be generated by the end host itself, 351 in which case it may then request reference identifier based on 352 the location that it generated and provided to the LS. 354 2. Alternately, location information might be either generated, 355 provisioned, or stored by the LS (Location Server), and 356 represented to the end device as a location reference, via a 357 location configuration protocol (e.g., using DHCP or some L7LCP 358 (Layer 7 Location Configuration Protocol). 360 3. The location reference is only useful to mask the actual 361 location, but must be de-referenced in order to be useful for 362 location-based routing. Once the location is de-referenced at 363 the LS and returned to the requestor, it can then be used as 364 input to a location-to-mapping service (e.g., LoST). The mapping 365 server returns a URI which can be used to establish the signaling 366 to the next target destination. This returned target identifier 367 may be the URI of the next SIP Proxy (or any other element along 368 the routing path), or may be the URI of the appropriate IP-based 369 PSAP. 371 4. The PSAP, consistent with the figure, may choose to de-reference 372 the location identifier, once it is received, in order to view 373 the location, and to request subsequent location-based actions. 375 5. High-Level Requirements 377 Below, we summarize high-level design requirements needed for a 378 location-by-reference mechanism. 380 Rq1. Location Reference Identifier as a URI: The dereferencing 381 protocol MUST support an LRI in URI form, and may support other 382 non-URI forms. 384 Rq2. Dereference Protocol Confidentiality: The dereferencing 385 protocol MUST support mechanisms for encrypting messages sent 386 between client (Location recipient) and server (Location server). 388 Rq3. Dereference Protocol Transparancy: The dereferencing protocol 389 MUST support the exchange of messages without encryption (i.e., in 390 plaintext). 392 Motivation: In the case where encrypted message exchange is 393 unsuccessful, there must be a way to try to dereference a location 394 reference identifier with less restriction (e..g., in the 395 emergency service case, where every call always needs answered). 397 Rq4. Location Reference Expiry: The dereference protocol MUST 398 support specification of a finite period of validity for the LRI. 400 Motivation: Location references are not intended to represent a 401 location forever, and the identifier eventually may need to be 402 recycled, or may be subject to a specific window of validity, 403 after which the location reference fails to yield a location, or 404 the location is determined to be kept confidential. An expiry 405 timer for a location reference ensures that the location reference 406 becomes invalid based on configuration. 408 Rq5. Dereference Protocol Transport: The de-reference protocol MUST 409 support TCP/IP and MAY support UDP/IP. 411 Motivation: Practical, near-term deployment issues may make TCP/IP 412 implementations unachievable. 414 Rq6''. Dereference Protocol Authentication: The dereferencing 415 protocol MUST support both client-side and server-side 416 authentication. 418 Motivation: It is reasonable to expect implementations of 419 authentication to vary. Some implementations may choose to 420 support both client-side and server-side authentication, might 421 support one only, or may support neither. 423 Rq7. Location Privacy: The dereference protocol MUST support the 424 application of privacy rules to the dissemination of a requested 425 location object. 427 Rq8. Dereferenced PIDF-LO Result: The dereferencing of an LRI MUST 428 result in a well-formed PIDF-LO. 430 Motivation: This is in order to ensure adequate privacy rules can 431 be adhered to, since the PIDF-LO format comprises the necessary 432 structures to maintain location privacy. 434 6. Security Considerations 436 Considerations for security to a Location-by-Reference model for the 437 dereference protocol, include, 1. Privacy Privacy of the LRI itself 438 Privacy of the dereferenced location object 2. Expiry Expiry of the 439 LRI. Expiry of the dereferenced location object. 3. Theft Theft of 440 a LRI. Theft of a dereferenced location object. 4. Replay/Reuse 441 Replay of a stolen LRI to perform a dereference operation. Reuse 442 using the dereference location object. 5. Impact of the two forms of 443 location reference. Location provision from LIS by reference. 444 Location indirection by the LIS, at the request of the Target. May 445 also reference security considerations found within document 446 [I-D.ietf-geopriv-l7-lcp-ps]. 448 7. IANA Considerations 450 This document does not require actions by the IANA. 452 8. Contributors 454 Andrew Newton, James Polk, Martin Thompson, Richard Barnes, Barbara 455 Stark, James Winterbottom, Hannes Tschofenig 457 The contributors can be reached at: 459 Name user@example.com 461 9. Acknowledgments 463 [TBD] 465 10. References 467 10.1. Normative References 469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 470 Requirement Levels", BCP 14, RFC 2119, March 1997. 472 10.2. Informative References 474 [I-D.hardie-ecrit-lost] 475 Hardie, T., "LoST: A Location-to-Service Translation 476 Protocol", draft-hardie-ecrit-lost-00 (work in progress), 477 March 2006. 479 [I-D.ietf-ecrit-requirements] 480 Schulzrinne, H. and R. Marshall, "Requirements for 481 Emergency Context Resolution with Internet Technologies", 482 draft-ietf-ecrit-requirements-12 (work in progress), 483 August 2006. 485 [I-D.ietf-ecrit-security-threats] 486 Taylor, T., "Security Threats and Requirements for 487 Emergency Call Marking and Mapping", 488 draft-ietf-ecrit-security-threats-03 (work in progress), 489 July 2006. 491 [I-D.ietf-geopriv-dhcp-civil] 492 Schulzrinne, H., "Dynamic Host Configuration Protocol 493 (DHCPv4 and DHCPv6) Option for Civic Addresses 494 Configuration Information", 495 draft-ietf-geopriv-dhcp-civil-09 (work in progress), 496 January 2006. 498 [I-D.ietf-geopriv-l7-lcp-ps] 499 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 500 Location Configuration Protocol; Problem Statement and 501 Requirements", draft-ietf-geopriv-l7-lcp-ps-00 (work in 502 progress), January 2007. 504 [I-D.ietf-sipping-toip] 505 Wijk, A. and G. Gybels, "Framework for real-time text over 506 IP using the Session Initiation Protocol (SIP)", 507 draft-ietf-sipping-toip-07 (work in progress), 508 August 2006. 510 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 511 A., Peterson, J., Sparks, R., Handley, M., and E. 512 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 513 June 2002. 515 [RFC3351] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. 516 van Wijk, "User Requirements for the Session Initiation 517 Protocol (SIP) in Support of Deaf, Hard of Hearing and 518 Speech-impaired Individuals", RFC 3351, August 2002. 520 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 521 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 523 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 524 Configuration Protocol Option for Coordinate-based 525 Location Configuration Information", RFC 3825, July 2004. 527 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 528 (CPIM)", RFC 3860, August 2004. 530 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 531 RFC 3966, December 2004. 533 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 534 Conversation", RFC 4103, June 2005. 536 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 537 Format", RFC 4119, December 2005. 539 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 540 Priority for the Session Initiation Protocol (SIP)", 541 RFC 4412, February 2006. 543 Author's Address 545 Roger Marshall (editor) 546 TeleCommunication Systems, Inc. 547 2401 Elliott Avenue 548 2nd Floor 549 Seattle, WA 98121 550 US 552 Phone: +1 206 792 2424 553 Email: rmarshall@telecomsys.com 554 URI: http://www.telecomsys.com 556 Full Copyright Statement 558 Copyright (C) The IETF Trust (2007). 560 This document is subject to the rights, licenses and restrictions 561 contained in BCP 78, and except as set forth therein, the authors 562 retain all their rights. 564 This document and the information contained herein are provided on an 565 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 566 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 567 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 568 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 569 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 570 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 572 Intellectual Property 574 The IETF takes no position regarding the validity or scope of any 575 Intellectual Property Rights or other rights that might be claimed to 576 pertain to the implementation or use of the technology described in 577 this document or the extent to which any license under such rights 578 might or might not be available; nor does it represent that it has 579 made any independent effort to identify any such rights. Information 580 on the procedures with respect to rights in RFC documents can be 581 found in BCP 78 and BCP 79. 583 Copies of IPR disclosures made to the IETF Secretariat and any 584 assurances of licenses to be made available, or the result of an 585 attempt made to obtain a general license or permission for the use of 586 such proprietary rights by implementers or users of this 587 specification can be obtained from the IETF on-line IPR repository at 588 http://www.ietf.org/ipr. 590 The IETF invites any interested party to bring to its attention any 591 copyrights, patents or patent applications, or other proprietary 592 rights that may cover technology that may be required to implement 593 this standard. Please address the information to the IETF at 594 ietf-ipr@ietf.org. 596 Acknowledgment 598 Funding for the RFC Editor function is provided by the IETF 599 Administrative Support Activity (IASA).