idnits 2.17.1 draft-ietf-ecrit-lost-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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 933. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 940. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 946. ** 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 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 -- 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 (June 16, 2006) is 6524 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: '1' is defined on line 837, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 841, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 864, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-security-threats-01 ** Downref: Normative reference to an Informational draft: draft-ietf-ecrit-security-threats (ref. '4') == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-requirements-10 ** Downref: Normative reference to an Informational draft: draft-ietf-ecrit-requirements (ref. '5') == Outdated reference: A later version (-07) exists of draft-ietf-ecrit-service-urn-03 == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-03 -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hardie 3 Internet-Draft Qualcomm, Inc. 4 Expires: December 18, 2006 A. Newton 5 SunRocket 6 H. Schulzrinne 7 Columbia U. 8 H. Tschofenig 9 Siemens 10 June 16, 2006 12 LoST: A Location-to-Service Translation Protocol 13 draft-ietf-ecrit-lost-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 18, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document describes an XML-based protocol for mapping service 47 identifiers and geospatial or civic location information to service 48 contact URIs. In particular, it can be used to determine the 49 location-appropriate PSAP for emergency services. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 55 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4. Server Discovery . . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 5.1. Location Information Element . . . . . . . . . . . . . . . 8 59 5.2. Service Identifier Element . . . . . . . . . . . . . . . . 8 60 5.3. Validate Attribute . . . . . . . . . . . . . . . . . . . . 8 61 5.4. Query Message Examples . . . . . . . . . . . . . . . . . . 8 62 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 6.1. Uniform Resource Identifiers (URI) Element . . . . . . . . 10 64 6.2. Display Name Element Element . . . . . . . . . . . . . . . 10 65 6.3. Region Element . . . . . . . . . . . . . . . . . . . . . . 10 66 6.4. Dialstring Element . . . . . . . . . . . . . . . . . . . . 10 67 6.5. TimeToLive Attribute . . . . . . . . . . . . . . . . . . . 10 68 6.6. Validated Element . . . . . . . . . . . . . . . . . . . . 10 69 6.7. text Attribute . . . . . . . . . . . . . . . . . . . . . . 11 70 6.8. Response Message Examples . . . . . . . . . . . . . . . . 11 71 7. Miscellaneous Functionality . . . . . . . . . . . . . . . . . 13 72 7.1. List Service Query . . . . . . . . . . . . . . . . . . . . 13 73 7.2. Response to a List Service Query . . . . . . . . . . . . . 13 74 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9. Deployment Methods . . . . . . . . . . . . . . . . . . . . . . 17 76 10. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 11. Internationalization Considerations . . . . . . . . . . . . . 24 78 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 79 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 80 14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 82 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 83 15.2. Informative References . . . . . . . . . . . . . . . . . . 28 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 85 Intellectual Property and Copyright Statements . . . . . . . . . . 31 87 1. Introduction 89 This document describes a protocol for mapping a service 90 identifier[6] and location information compatible with PIDF-LO [10] 91 to one or more service contact URIs. Example contact URI schemes 92 include sip, xmpp, and tel. While the initial focus is on providing 93 mapping functions for emergency services, it is likely that the 94 protocol is applicable to any service URN. For example, in the 95 United States, the "2-1-1" and "3-1-1" services follow a similar 96 location-to-service behavior as emergency services. 98 This document names this protocol usage "LoST" for Location-to- 99 Service Translation Protocol. The features of LoST are: 101 o Supports queries using civic as well as geospatial location 102 information. 104 o Can be used in both recursive and iterative resolution. 106 o Can be used for civic address validation. 108 o A hierarchical deployment of mapping servers is independent of 109 civic location labels. 111 o Can indicate errors in the location data to facilitate debugging 112 and proper user feedback while simultaneously providing best- 113 effort answers. 115 o Mapping can be based on either civic or geospatial location 116 information, with no performance penalty for either. 118 o Service regions can overlap. 120 o Satisfies the requirements [5] for mapping protocols. 122 o Minimizes round trips by caching individual mappings and by 123 supporting return of coverage regions ("hinting"). 125 o Facilitates reuse of TLS. 127 This document focuses on the description of the protocol between the 128 mapping client (seeker or resolver) and the mapping server (resolver 129 or other servers). The relationship between other functions, such as 130 discovery of mapping servers, data replication and the overall 131 mapping server architecture in general, will be described in a 132 separate document. [12] is a first attempt to describe such a mapping 133 server architecture. 135 The high-level protocol operation can be described as follows: 137 Location 138 Info +----------+ 139 --------> | | 140 Service | LoST | 141 URN | Server | 142 --------> | | 143 +----------+ 145 Query 147 URI +----------+ 148 <------- | | 149 Optional | LoST | 150 Info (hints)| Server | 151 <------- | | 152 +----------+ 154 Response 156 Figure 1: Overview 158 The query message carries location information and a service 159 identifier enconded as a Uniform Resource Name (URN) (see [6]) from 160 the LoST client to the LoST server. The LoST server uses its 161 database to map the input values to a Uniform Resource Identifiers 162 (URI) and returns it including optional information such as hints 163 about the service boundary in a response message back to the LoST 164 client. 166 2. Requirements Notation 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [3]. 172 3. Usage 174 The client queries a server, indicating the desired service and the 175 location object. If the query succeeds, the server returns a result 176 that includes one or more URIs for reaching the appropriate service 177 for the location indicated. Depending on the query, the result may 178 contain a region where the same mapping would apply, a reference to 179 another server to which the client should send a query, and error 180 messages indicating problems with interpretation of location 181 information. The combination of these components are left to the 182 needs and policy of the jurisdiction where the server is being 183 operated. 185 The client may perform the mapping at any time. Among the common 186 triggers for mapping are: 188 1. When the client starts up and/or attaches to a new network 189 location. 191 2. When the client detects that its location has changed 192 sufficiently that it is outside the bounds of the region returned 193 in an earlier query. 195 3. When cached mapping information has expired. 197 4. When calling for a particular service. During such calls, a 198 client MAY request a short response that contains only the 199 mapping data, omitting region information. In some operational 200 environments a UDP-based transport may be available and MAY be 201 used to confirm or update data already available. 203 Cached answers are expected to be used by clients only after failing 204 to accomplish a location-to-URI mapping at call time. Cache entries 205 may expire according to their time-to-live value, or they may become 206 invalid if the location of the caller's device moves outside the 207 boundary limits of the cache entry. Boundaries for cache entries may 208 be set in both geospatial and civic terms. 210 4. Server Discovery 212 There are likely to be a variety of ways that clients can discover 213 appropriate LoST servers, including DHCP, SIP device configuration, 214 or DNS records for their signaling protocol domain, e.g., the AOR 215 domain for SIP. The appropriate server depends on, among other 216 considerations, who operates LoST services, including the Internet 217 Service Provider (ISP), Voice Service Provider (VSP), or the user's 218 home domain. A DNS based approach utilizing the S-NAPTR mechanism is 219 specified in [6]. 221 5. Query 223 LoST provides the ability to use civic or geospatial location 224 information in the query message message. In addition to location 225 information the query also contains a service identifier. An 226 optional parameter might furthermore request the LoST server to 227 validate location information. 229 5.1. Location Information Element 231 LoST supports a query using geospatial and civic location information 232 using the findLoSTByCivic and the findLoSTByGeo query. Geospatial 233 location information uses GML format [9] and civic location 234 information utilizes the format defined in [10]. Hence, the location 235 format is not defined in this document but references already 236 available standards. 238 5.2. Service Identifier Element 240 The type of service desired is specified by the element. 241 The emergency identifiers listed in the registry established with [6] 242 will be used in this document. 244 5.3. Validate Attribute 246 The 'validate' attribute implements the validation behavior described 247 in [5]. 249 5.4. Query Message Examples 251 This section shows an example of a query message providing geospatial 252 and civic location information. 254 255 261 262 263 37:46:30N 122:25:10W 264 265 266 urn:service:sos 268 270 Figure 2: Query Message Example using Geospatial Location Information 272 The example above shows a query using geospatial location information 273 with no validation required and asking for the 'urn:service:sos' 274 service. 276 277 283 284 Germany 285 Bavaria 286 Munich 287 Neu Perlach 288 96 289 81675 290 291 urn:service:sos.police 293 295 Figure 3: Query Message Example using Civic Location Information 297 The example above shows a query using a civic location in Munich 298 asking for the 'urn:service:sos' service. The query also indicates 299 that validation is desired. 301 6. Response 303 A response message might either be a responseGeo or a responseCivic 304 depending on the type of query message. If the query message was a 305 findLoSTByCivic then the response will be a responseCivic. If a 306 findLoSTByGeo message was sent as a query then the response will be a 307 findLoSTByGeo. The location information that is provided by the 308 response message depends on the query and refers to the service 309 boundary as described in Section 6.3. 311 6.1. Uniform Resource Identifiers (URI) Element 313 Each uri element contains an appropriate contact URI for the service 314 for which mapping was requested. uri elements are of type xs:anyURI. 315 In the emergency service context operators are strongly discouraged 316 from using relative URIs, even though these are permitted by the 317 type. 319 6.2. Display Name Element Element 321 Each displayName element contains a string that is suitable for 322 display. displayName elements are of type "text" as described in 323 Section 6.7. 325 6.3. Region Element 327 Each region element contains either one or more civic location 328 elements derived from the GeoPriv civic address schema or feature.xsd 329 expression from GML. 331 6.4. Dialstring Element 333 Each dialstring element contains from one to sixteen digits. Note 334 that a Tel URI may also contain the same target, expressed in a 335 different format; see RFC 3966 [11]. 337 6.5. TimeToLive Attribute 339 Each timeToLive attribute is a positive integer, expressing the 340 validity period of the response in seconds. 342 6.6. Validated Element 344 Each validated element contains a string which is composed by by 345 concatenating the elements from the request which have been 346 recognized as valid by the server. 348 6.7. text Attribute 350 This is a text type suitable for internationalized human readable 351 text. 353 6.8. Response Message Examples 355 This section shows an example of a query message providing geospatial 356 and civic location information. 358 359 365 New York City Police Department 366 367 368 369 37.775 -122.4194 370 37.555 -122.4194 371 37.555 -122.4264 372 37.775 -122.4264 373 37.775 -122.4194 374 375 376 377 sip:nypd@example.com 378 xmpp:nypd@example.com 379 911 381 383 Figure 4: Response Message Example using Geospatial Location Service 384 Boundary Hints 386 This example shows a reponse with two URIs for the previously queried 387 service URN. Information about the service boundary is provided in 388 the Polyon. The element indicates the valid dialstring 389 for the expressed location and service URN. 391 392 398 Munich Police Department 399 400 Germany 401 Bavaria 402 Munich 403 404 country A1 A3 A6 PC 405 sip:munich-police@example.com 406 xmpp:munich-police@example.com 407 110 409 411 Figure 5: Response Message Example providing Civic Location Service 412 Boundary Hints 414 This example shows a response that returns two URIs (one for SIP and 415 another one for XMPP), a distring that indicates the valid distring 416 for the location provided in the query, a hint about the service 417 boundary in the element and information about the validated 418 civic address fields. The timeToLive indicates that the returned 419 information can be cached for 10000 seconds and provides a 420 displayName with additional, textual information about the returned 421 information. 423 7. Miscellaneous Functionality 425 7.1. List Service Query 427 This subsection describes a query that offers the LoST client to 428 query for available service identifiers supported by the LoST server. 430 431 435 urn:service:sos 437 439 Figure 6: Example for a List Service Query 441 This listService query aims to query the immediate child elements of 442 the 'urn:service:sos' URN. 444 7.2. Response to a List Service Query 446 This subsection describes the response message that provides the LoST 447 client with the list of immediate child service identifiers based on 448 the service identifier provided by LoST client in the query. 450 451 456 urn:service:sos.ambulance 457 urn:service:sos.animal-control 458 urn:service:sos.fire 459 urn:service:sos.gas 460 urn:service:sos.mountain 461 urn:service:sos.marine 462 urn:service:sos.physician 463 urn:service:sos.poison 464 urn:service:sos.police 465 urn:service:sos.suicide 467 469 Figure 7: Example for the Response to a List Service Query 471 This response corresponds to the query of Figure 6. 473 8. Example 475 After performing link layer attachment and end host performs stateful 476 address autoconfiguration (in our example) using DHCP. Then, DHCP 477 provides the end host with civic location as described in[7]. 479 +--------+---------------+ 480 | CAtype | CAvalue | 481 +--------+---------------+ 482 | 0 | US | 483 | 1 | New York | 484 | 3 | New York | 485 | 6 | Broadway | 486 | 22 | Suite 75 | 487 | 24 | 10027-0401 | 488 +--------+---------------+ 490 Figure 8: DHCP Civic Information Example 492 Additionally, DHCP may provide information about the LoST server that 493 can be contacted. Alternatively, an additional step of indirection 494 is possible, for example by having DHCP return a domain name that has 495 to be resolved to one or more IP addresses hosting LoST servers. 497 Both at attachment time and call time, the client places a LoST 498 request, including its civic location and the desired service. The 499 request is shown below: 501 502 508 509 US 510 New York 511 New York 512 Broadway 513 Suite 75 514 10027-0401 515 516 urn:service:sos.police 518 519 Since the contacted LoST server has the requested information 520 available the following response is returned. The response 521 indicates, as a human readable display string that the 'New York City 522 Police Department' is responsible for the given geographical area. 523 The indicated URI allows the user to start communication using SIP or 524 XMPP. The 'validated' element indicates which parts of the civic 525 address were matched successfully against a database and represent a 526 known address. Other parts of the address, here, the suite number, 527 were ignored and not validated. The returned service boundary 528 indicates that all of New York City would result in the same 529 response. The dialstring element indicates that the service can be 530 reached via the dial string 9-1-1. 532 533 539 New York City Police Department 540 541 US 542 New York 543 New York 544 545 country A1 A3 A6 PC 546 sip:nypd@example.com 547 xmpp:nypd@example.com 548 911 550 552 9. Deployment Methods 554 Because services for emergency contact resolution may differ 555 depending on local or service needs, this document only specifies the 556 "wire format" for LoST services and explicitly leaves open the 557 possibility for many different types of deployment. 559 For instance: 561 During discovery, a client may be directed to issue all queries to 562 an LoST service completely authoritative for a given jursidiction. 564 A client may be directed to issue queries to an LoST server that 565 acts as a reflector. In such a case, the LoST server analyzes the 566 query to determine the best server to wich to refer the client. 568 Or the client may be directed to a server that performs further 569 resolution on behalf of the client. 571 A LoST service may also be represented by multiple LoST servers, 572 either grouped together or at multiple network locations. Using 573 S-NAPTR [13], clients may be given a list of multiple servers to 574 which queries can be sent for a single service. 576 For instance, the service at emergency.example.com may advertise LoST 577 service at local1.emergency.example.com, 578 local2.emergency.example.com, and master.emergency.example.com. Each 579 server may given a different preference. In this case, 'local-1' and 580 'local-2' may be given a lower preference (more preferred) than 581 'master', which might be a busier server or located further away. 583 +-----------+ pref 10 +-----------+ 584 | |-------------------->+ | 585 | client |------ | local-1 | 586 | |--- \ | | 587 +-----------+ \ \ +-----------+ 588 \ \ 589 \ \ +-----------+ 590 \ \ pref 10 | | 591 \ --------->| local-2 | 592 \ | | 593 \ +-----------+ 594 \ 595 \ +-----------+ 596 \ pref 20 | | 597 ------------------------->| master | 598 | | 599 +-----------+ 601 10. XML Schema 603 This section provides the XML schema used by LoST. 605 606 615 616 617 A schema for a Location to Service Translation Protocol 618 619 621 622 623 625 627 628 630 632 635 636 637 638 639 642 644 645 647 649 650 652 654 657 658 659 660 661 663 665 666 668 669 670 672 674 677 678 679 680 681 683 684 685 686 688 689 690 692 693 695 696 698 700 702 705 706 707 708 709 712 715 718 721 722 723 724 726 729 730 731 732 733 736 738 741 744 745 746 747 749 752 753 754 755 756 758 759 760 761 763 764 765 767 770 773 776 779 780 781 782 783 784 785 788 789 790 791 792 793 794 796 11. Internationalization Considerations 798 This mechanism is largely for passing protocol information from one 799 subsystem to another; as such, most of its elements are tokens not 800 meant for direct human consumption. If these tokens are presented to 801 the end user, some localization may need to occur. The content of 802 the displayName element may be displayed to the end user, and it is 803 thus a complex type designed for this purpose. 805 12. IANA Considerations 807 TBD, such as namespace registrations. 809 13. Security Considerations 811 There are multiple threats to the overall system of which service 812 mapping forms a part. An attacker that can obtain service contact 813 URIs can use those URIs to attempt to disrupt those services. An 814 attacker that can prevent the lookup of contact URIs can impair the 815 reachability of such services. An attacker that can eavesdrop on the 816 communication requesting this lookup can surmise the existence of an 817 emergency and possibly its nature, and may be able to use this to 818 launch a physical attack on the caller. 820 To avoid that an attacker can modify the query or its result, LoST 821 RECOMMENDS the use of channel security, such as TLS. 823 A more detailed description of threats and security requirements are 824 provided in [4]. 826 [Editor's Note: A future version of this document will describe the 827 countermeasures based on the security requirements outlined in[4].] 829 14. Open Issues 831 Please find open issues at: http://www.ietf-ecrit.org:8080/lost/ 833 15. References 835 15.1. Normative References 837 [1] World Wide Web Consortium, "XML Schema Part 2: Datatypes", 838 W3C XML Schema, October 2000, 839 . 841 [2] World Wide Web Consortium, "XML Schema Part 1: Structures", 842 W3C XML Schema, October 2000, 843 . 845 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 846 Levels", RFC 2119, BCP 14, March 1997. 848 [4] Taylor, T., "Security Threats and Requirements for Emergency 849 Call Marking and Mapping", draft-ietf-ecrit-security-threats-01 850 (work in progress), April 2006. 852 [5] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 853 Context Resolution with Internet Technologies", 854 draft-ietf-ecrit-requirements-10 (work in progress), June 2006. 856 [6] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", 857 draft-ietf-ecrit-service-urn-03 (work in progress), May 2006. 859 [7] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 860 and DHCPv6) Option for Civic Addresses Configuration 861 Information", draft-ietf-geopriv-dhcp-civil-09 (work in 862 progress), January 2006. 864 [8] Mealling, M., "The IETF XML Registry", 865 draft-mealling-iana-xmlns-registry-03 (work in progress), 866 November 2001. 868 [9] OpenGIS, "Open Geography Markup Language (GML) Implementation 869 Specification", OGC OGC 02-023r4, January 2003. 871 [10] Peterson, J., "A Presence-based GEOPRIV Location Object 872 Format", RFC 4119, December 2005. 874 15.2. Informative References 876 [11] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 877 December 2004. 879 [12] Schulzrinne, H., "Location-to-URL Mapping Architecture and 880 Framework", draft-schulzrinne-ecrit-mapping-arch-00 (work in 881 progress), October 2005. 883 [13] Daigle, L. and A. Newton, "Domain-Based Application Service 884 Location Using SRV RRs and the Dynamic Delegation Discovery 885 Service (DDDS)", RFC 3958, January 2005. 887 Authors' Addresses 889 Ted Hardie 890 Qualcomm, Inc. 892 Email: hardie@qualcomm.com 894 Andrew Newton 895 SunRocket 896 8045 Leesburg Pike, Suite 300 897 Vienna, VA 22182 898 US 900 Phone: +1 703 636 0852 901 Email: andy@hxr.us 903 Henning Schulzrinne 904 Columbia University 905 Department of Computer Science 906 450 Computer Science Building 907 New York, NY 10027 908 US 910 Phone: +1 212 939 7004 911 Email: hgs+ecrit@cs.columbia.edu 912 URI: http://www.cs.columbia.edu 914 Hannes Tschofenig 915 Siemens 916 Otto-Hahn-Ring 6 917 Munich, Bavaria 81739 918 Germany 920 Phone: +49 89 636 40390 921 Email: Hannes.Tschofenig@siemens.com 922 URI: http://www.tschofenig.com 924 Intellectual Property Statement 926 The IETF takes no position regarding the validity or scope of any 927 Intellectual Property Rights or other rights that might be claimed to 928 pertain to the implementation or use of the technology described in 929 this document or the extent to which any license under such rights 930 might or might not be available; nor does it represent that it has 931 made any independent effort to identify any such rights. Information 932 on the procedures with respect to rights in RFC documents can be 933 found in BCP 78 and BCP 79. 935 Copies of IPR disclosures made to the IETF Secretariat and any 936 assurances of licenses to be made available, or the result of an 937 attempt made to obtain a general license or permission for the use of 938 such proprietary rights by implementers or users of this 939 specification can be obtained from the IETF on-line IPR repository at 940 http://www.ietf.org/ipr. 942 The IETF invites any interested party to bring to its attention any 943 copyrights, patents or patent applications, or other proprietary 944 rights that may cover technology that may be required to implement 945 this standard. Please address the information to the IETF at 946 ietf-ipr@ietf.org. 948 Disclaimer of Validity 950 This document and the information contained herein are provided on an 951 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 952 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 953 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 954 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 955 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 956 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 958 Copyright Statement 960 Copyright (C) The Internet Society (2006). This document is subject 961 to the rights, licenses and restrictions contained in BCP 78, and 962 except as set forth therein, the authors retain all their rights. 964 Acknowledgment 966 Funding for the RFC Editor function is currently provided by the 967 Internet Society.