idnits 2.17.1 draft-ietf-geopriv-http-location-delivery-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1745. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1756. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1763. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1769. 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 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 (January 14, 2008) is 5939 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: '5' is defined on line 1444, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1457, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1477, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1496, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1502, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2616 (ref. '3') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (ref. '4') (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 3693 (ref. '7') == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-10 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-06 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-l7-lcp-ps (ref. '11') -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-lbyr-requirements (ref. '15') -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '16') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3023 (ref. '18') (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '21') (Obsoleted by RFC 6225) -- Obsolete informational reference (is this intentional?): RFC 4395 (ref. '22') (Obsoleted by RFC 7595) == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-09 == Outdated reference: A later version (-05) exists of draft-winterbottom-geopriv-deref-protocol-00 Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV WG M. Barnes, Ed. 3 Internet-Draft Nortel 4 Intended status: Standards Track 5 Expires: July 17, 2008 7 January 14, 2008 9 HTTP Enabled Location Delivery (HELD) 10 draft-ietf-geopriv-http-location-delivery-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in 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 July 17, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 A Layer 7 Location Configuration Protocol (L7 LCP) is described that 44 is used for retrieving location information from a server within an 45 access network. The protocol includes options for retrieving 46 location information in two forms: by-value and by-reference. The 47 protocol is an extensible application-layer protocol that is 48 independent of session-layer. This document describes the use of 49 Hypertext Transfer Protocol (HTTP) as a transport for the protocol. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 55 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 57 4.1. Location by Value . . . . . . . . . . . . . . . . . . . . 7 58 4.2. Location by Reference . . . . . . . . . . . . . . . . . . 7 59 4.3. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7 60 4.3.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8 61 4.3.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8 62 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 63 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9 64 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 9 65 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10 66 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 67 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 68 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 69 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 11 70 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12 71 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 12 72 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13 73 6.5. "locationURI" Parameter . . . . . . . . . . . . . . . . . 13 74 6.5.1. "expires" Parameter . . . . . . . . . . . . . . . . . 14 75 6.6. "pidf-LO" Parameter . . . . . . . . . . . . . . . . . . . 15 76 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 79 9.1. Return Routability . . . . . . . . . . . . . . . . . . . . 20 80 9.2. Transaction Layer Security . . . . . . . . . . . . . . . . 21 81 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 10.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 21 83 10.2. Simple Location Request Example . . . . . . . . . . . . . 24 84 10.3. Location Request Example for Multiple Location Types . . . 25 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 86 11.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 26 87 11.1.1. URN Sub-Namespace Registration for 88 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . 26 89 11.1.2. URN Sub-Namespace Registration for 90 urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . 27 91 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 28 92 11.3. MIME Media Type Registration for 'application/held+xml' . 28 93 11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 29 94 11.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 29 95 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 96 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 97 14. Changes since last Version . . . . . . . . . . . . . . . . . . 31 98 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 99 15.1. Normative References . . . . . . . . . . . . . . . . . . . 33 100 15.2. Informative References . . . . . . . . . . . . . . . . . . 35 101 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 36 102 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 36 103 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 36 104 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 37 105 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 37 106 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 37 107 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 38 108 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 38 109 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 38 110 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 39 111 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 39 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 113 Intellectual Property and Copyright Statements . . . . . . . . . . 41 115 1. Introduction 117 The location of a Device is information that is useful for a number 118 of applications. The L7 Location Configuration Protocol (LCP) 119 problem statement and requirements document [11] provides some 120 scenarios in which the Device might rely on its access network to 121 provide location information. The LIS service applies to access 122 networks employing both wired technology (e.g. DSL, Cable) and 123 wireless technology (e.g. WiMAX) with varying degrees of Device 124 mobility. This document describes a protocol that can be used to 125 acquire Location Information (LI) from a Location Information Server 126 (LIS) within an access network. 128 This specification identifies two types of location information that 129 may be retrieved from the LIS. Location may be retrieved from the 130 LIS by-value, that is, the Device may acquire a literal location 131 object describing the location of the Device. The Device may also 132 request that the LIS provide a location reference in the form of a 133 location URI or set of location URIs, allowing the Device to 134 distribute its LI by-reference. Both of these methods can be 135 provided concurrently from the same LIS to accommodate application 136 requirements for different types of location information. 138 This specification defines an extensible XML-based protocol that 139 enables the retrieval of LI from a LIS by a Device. This protocol 140 can be bound to any session-layer protocol, particularly those 141 capable of MIME transport. This document describes the use of 142 Hypertext Transfer Protocol (HTTP) as a transport for the protocol. 144 2. Conventions & Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [1]. 150 This document uses the terms (and their acronym forms) Access 151 Provider (AP), Location Information (LI), Location Object (LO), 152 Device, Target, Location Generator (LG), Location Recipient (LR), 153 Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV 154 Requirements [7] . The terms Location Information Server (LIS), 155 Access Network, Access Provider (AP) and Access Network Provider are 156 used in the same context as defined in the L7 LCP Problem statement 157 and Requirements document [11]. The usage of the terms, Civic 158 Location/Address and Geodetic Location follows the usage in many of 159 the referenced documents. 161 In describing the protocol, the terms "attribute" and "element" are 162 used according to their context in XML. The term "parameter" is used 163 in a more general protocol context and can refer to either an XML 164 "attribute" or "element". 166 3. Overview and Scope 168 This document describes an interface between a Device and a Location 169 Information Server (LIS). This document assumes that the LIS is 170 present within the same administrative domain as the Device (e.g., 171 the access network). An Access Provider (AP) operates the LIS so 172 that Devices (and Targets) can retrieve LI. The LIS exists because 173 not all Devices are capable of determining LI, and because, even if a 174 device is able to determine its own LI, it may be more efficient with 175 assistance. This document does not specify how LI is determined. 177 This document is based on the attribution of the LI to a Device and 178 not specifically a person (end user) or Target, based on the premise 179 that location determination technologies are generally designed to 180 locate a device and not a person. It is expected that, for most 181 applications, LI for the device can be used as an adequate substitute 182 for the end user's LI. Since revealing the location of the device 183 almost invariably reveals some information about the location of the 184 user of the device, the same level of privacy protection demanded by 185 a user is required for the device. This approach may require either 186 some additional assurances about the link between device and target, 187 or an acceptance of the limitation that unless the device requires 188 active user authentication, there is no guarantee that any particular 189 individual is using the device at that instant. 191 The following diagram shows the logical configuration of some of the 192 functional elements identified in [7] and the LIS defined in [11] and 193 where this protocol applies, with the Rule Maker and Target 194 represented by the role of the Device. 196 +---------------------------------------------+ 197 | Access Network Provider | 198 | | 199 | +--------------------------------------+ | 200 | | Location Information Server | | 201 | | | | 202 | | | | 203 | | | | 204 | | | | 205 | +------|---------------------'---------+ | 206 +----------|---------------------'------------+ 207 | ' 208 | ' 209 HELD APP 210 | ' 211 Rule Maker - _ +-----------+ +-----------+ 212 o - - | Device | | Location | 213 and as specified in [8] MUST be applied. A default value of "no" 638 SHALL be used for the element. A default 639 value of 24 hours SHALL be used for value of any 640 generated PIDF-LO documents. A LIS MAY provide a shorter value for 641 but MUST NOT provide a value longer than 24 hours. 643 Note that the PIDF-LO is not explicitly shown in the XML schema 644 Section 7 for a location response message due to XML schema 645 constraints. 647 7. XML Schema 649 This section gives the XML Schema Definition [12] of the 650 "application/held+xml" format. This is presented as a formal 651 definition of the "application/held+xml" format. Note that the XML 652 Schema definition is not intended to be used with on-the-fly 653 validation of the presence XML document. 655 656 664 665 666 668 This document defines HELD messages. 669 670 672 674 675 676 677 678 679 681 682 684 685 686 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 705 706 707 708 709 710 711 713 714 716 717 718 719 720 721 722 723 724 725 726 727 729 730 731 732 734 735 736 738 739 740 741 742 743 744 745 746 747 748 749 751 752 753 754 755 756 758 759 761 762 764 765 766 767 768 770 772 773 774 775 777 779 780 781 782 783 784 787 789 790 791 792 794 797 799 800 801 802 803 806 808 809 810 811 813 816 818 8. HTTP Binding 820 This section describes the use of HTTP [3] as a transport mechanism 821 for this protocol, which all conforming implementations MUST support. 823 The request is carried in the body of an HTTP POST request. The MIME 824 type of both request and response bodies should be 825 "application/held+xml". 827 The LIS populates the HTTP headers so that they are consistent with 828 the contents of the message. In particular, the "expires" and cache 829 control headers are used to control the caching of any PIDF-LO 830 document or Location URIs. The HTTP status code SHOULD indicate a 831 2xx series response when a PIDF-LO document or Location URI is 832 included. 834 The use of HTTP also includes a default behaviour, which is triggered 835 by a GET request, or a POST with no request body. If either of these 836 queries are received, the LIS MUST attempt to provide either a 837 PIDF-LO document or a Location URI, as if the request was a location 838 request. 840 The implementation of HTTP as a transport mechanism MUST implement 841 TLS as described in [4]. TLS provides message integrity and privacy 842 between Device and LIS. The LIS MUST use the server authentication 843 method described in [4]; the Device MUST fail a request if server 844 authentication fails, except in the event of an emergency. 846 9. Security Considerations 848 The Security Requirements for the Geopriv Location System [Editor's 849 note: need to add explicit reference to this doc, BUT xml2rfc not 850 happy with that doc not having an abbreviated title] identifies the 851 threat model for the protocols that interface with a LIS. The threat 852 model for the HELD protocol assumes that the LIS exists within the 853 same administrative domain as the Device. The LIS requires access to 854 network information so that it can determine Location. Therefore, 855 the LIS can use network information to protect against a number of 856 the possible attacks. 858 Specific requirements and security considerations for location 859 acquisition protocols are provided in [11] including that the LCP 860 MUST NOT assume prior network access authentication, which is 861 addressed in Section 9.2 863 An in-depth discussion of the security considerations applicable to 864 the use of Location URIs and by-reference provision of LI is included 865 in [15]. 867 9.1. Return Routability 869 It is RECOMMENDED that Location Information Servers use return 870 routability rather than requiring Device authentication. Device 871 authentication SHOULD NOT be required due to the administrative 872 challenge of issuing and managing of client credentials, particularly 873 when networks allow visiting users to attach devices. However, the 874 LIS MAY require any form of authentication as long as these factors 875 are considered. 877 Addressing information used in a request to the LIS is used to 878 determine the identity of the Device, and to address a response. 879 This ensures that a Device can only request its own LI. 881 A temporary spoofing of IP address could mean that a device could 882 request a Location URI that would result in another Device's 883 location. One or more of the follow approaches are RECOMMENDED to 884 limit this exposure: 885 o Location URIs SHOULD have a limited lifetime, as reflected by the 886 value for the expires element (Section 6.5.1). 887 o The network SHOULD have mechanisms that protect against IP address 888 spoofing. 889 o The LIS SHOULD ensure that requests can only originate from within 890 its administrative domain. 891 o The LIS and network SHOULD be configured so that the LIS is made 892 aware of Device movement within the network and addressing 893 changes. If the LIS detects a change in the network, then all 894 location URIs MUST be invalidated. 896 The above measures are dependent on network configuration and SHOULD 897 be considered with circumstances in mind. For instance, in a fixed 898 internet access, providers may be able to restrict the allocation of 899 IP addresses to a single physical line, ensuring that spoofing is not 900 possible; in such an environment, other measures may not be 901 necessary. 903 9.2. Transaction Layer Security 905 All bindings for this protocol MUST ensure that messages are 906 adequately protected against eavesdropping and modification. 907 Bindings MUST also provide a means of authenticating the LIS. 909 It is RECOMMENDED that all bindings also use TLS [2]. 911 For the HTTP binding, TLS MUST be used. TLS provides protection 912 against eavesdropping and modification. The server authentication 913 methods described in HTTP on TLS [4] MUST be used. 915 10. Examples 917 10.1. HTTP Example Messages 919 The examples in this section show a complete HTTP message that 920 includes the HELD request or response document. 922 This example shows the most basic request for a LO. This uses the 923 GET feature described by the HTTP binding. This example assumes that 924 the LIS service exists at the URL "https://lis.example.com/location". 926 GET /location HTTP/1.1 927 Host: lis.example.com 928 Accept:application/held+xml, 929 application/xml;q=0.8, 930 text/xml;q=0.7 931 Accept-Charset: UTF-8,* 933 The GET request is exactly identical to a minimal POST request that 934 includes an empty "locationRequest" element. 936 POST /location HTTP/1.1 937 Host: lis.example.com 938 Accept: application/held+xml, 939 application/xml;q=0.8, 940 text/xml;q=0.7 941 Accept-Charset: UTF-8,* 942 Content-Type: application/held+xml 943 Content-Length: 87 945 946 948 The successful response to either of these requests is a PIDF-LO 949 document. The following response shows a minimal PIDF-LO response. 951 HTTP/1.x 200 OK 952 Server: Example LIS 953 Date: Tue, 10 Jan 2006 03:42:29 GMT 954 Expires: Tue, 10 Jan 2006 03:42:29 GMT 955 Cache-control: private 956 Content-Type: application/held+xml 957 Content-Length: 594 959 960 961 963 964 965 966 967 969 -34.407 150.88001 970 971 972 973 974 2006-01-11T03:42:28+00:00 975 976 977 978 2006-01-10T03:42:28+00:00 979 980 981 983 The error response to either of these requests is an error document. 984 The following response shows an example error response. 986 HTTP/1.x 200 OK 987 Server: Example LIS 988 Expires: Tue, 10 Jan 2006 03:49:20 GMT 989 Cache-control: private 990 Content-Type: application/held+xml 991 Content-Length: 135 993 994 998 Note: To focus on important portions of messages, all examples 999 following this note do not show HTTP headers or the XML prologue. 1000 In addition, sections of XML not relevant to the example are 1001 replaced with comments. 1003 10.2. Simple Location Request Example 1005 The location request shown below doesn't specify any location types 1006 or response time. 1008 1010 The response to this location request is a list of Location URIs. 1012 1013 1014 held://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1015 1016 held://9769+357yc6s64ceyoiuy5ax3o@ls.example.com 1017 1018 1019 1021 An error response to this location request is shown below: 1023 1027 10.3. Location Request Example for Multiple Location Types 1029 The following Location Request message includes a request for 1030 geodetic, civic and any Location URIs. 1032 1033 1034 geodetic 1035 civic 1036 locationURI 1037 1038 1040 The corresponding Location Response message includes the requested 1041 location information, including two location URIs. 1043 1044 1045 held://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1046 1047 held://9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 1048 1049 1050 1052 1053 1054 1055 1056 1060 -34.407242 150.882518 1061 30 1062 1063 1064 1067 AU 1068 NSW 1069 Wollongong 1070 Gwynneville 1071 Northfield Avenue 1072 University of Wollongong 1073 2 1074 Andrew Corporation 1075 2500 1076 39 1077 WS-183 1078 U40 1079 1080 1081 1082 false 1083 2007-05-25T12:35:02+10:00 1084 1085 1086 Wiremap 1087 1088 1089 2007-05-24T12:35:02+10:00 1090 1091 1092 1094 11. IANA Considerations 1096 This document requires several IANA registrations detailed in the 1097 following sections. 1099 11.1. URN Sub-Namespace Registration 1101 This specification registers two new XML namespaces, as per the 1102 guidelines in [6]. 1104 11.1.1. URN Sub-Namespace Registration for 1105 urn:ietf:params:xml:ns:geopriv:held 1107 This section registers a new XML namespace, 1108 "urn:ietf:params:xml:ns:geopriv:held". 1109 URI: urn:ietf:params:xml:ns:geopriv:held 1110 Registrant Contact: IETF, GEOPRIV working group, 1111 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). 1112 XML: 1114 BEGIN 1115 1116 1118 1119 1120 HELD Messages 1121 1122 1123

Namespace for HELD Messages

1124

urn:ietf:params:xml:ns:geopriv:held

1125 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1126 with the RFC number for this specification.]] 1127

See RFCXXXX.

1128 1129 1130 END 1132 11.1.2. URN Sub-Namespace Registration for 1133 urn:ietf:params:xml:ns:geopriv:held:http 1135 TThis section registers a new XML namespace, 1136 "urn:ietf:params:xml:ns:geopriv:held:http." 1137 URI: urn:ietf:params:xml:ns:geopriv:held:http 1138 Registrant Contact: IETF, GEOPRIV working group, 1139 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). 1140 XML: 1142 BEGIN 1143 1144 1146 1147 1148 HELD HTTP Binding WS 1149 1150 1151

Namespace for HELD HTTP Binding WS

1152

urn:ietf:params:xml:ns:geopriv:held:http

1153 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1154 with the RFC number for this specification.]] 1155

See RFCXXXX.

1156 1157 1158 END 1160 11.2. XML Schema Registration 1162 This section registers an XML schema as per the guidelines in [6]. 1163 URI: urn:ietf:params:xml:schema:geopriv:held 1164 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1165 Mary Barnes (mary.barnes@nortel.com). 1166 Schema: The XML for this schema can be found as the entirety of 1167 Section 7 of this document. 1169 11.3. MIME Media Type Registration for 'application/held+xml' 1171 This section registers the "application/held+xml" MIME type. 1172 To: ietf-types@iana.org 1173 Subject: Registration of MIME media type application/held+xml 1174 MIME media type name: application 1175 MIME subtype name: held+xml 1176 Required parameters: (none) 1177 Optional parameters: charset 1178 Indicates the character encoding of enclosed XML. Default is 1179 UTF-8. 1180 Encoding considerations: Uses XML, which can employ 8-bit 1181 characters, depending on the character encoding used. See RFC 1182 3023 [18], section 3.2. 1183 Security considerations: This content type is designed to carry 1184 protocol data related to the location of an entity, which could 1185 include information that is considered private. Appropriate 1186 precautions should be taken to limit disclosure of this 1187 information. 1188 Interoperability considerations: This content type provides a basis 1189 for a protocol 1190 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 1191 replace XXXX with the RFC number for this specification.]] 1192 Applications which use this media type: Location information 1193 providers and consumers. 1194 Additional Information: Magic Number(s): (none) 1195 File extension(s): .xml 1196 Macintosh File Type Code(s): (none) 1197 Person & email address to contact for further information: Mary 1198 Barnes 1199 Intended usage: LIMITED USE 1200 Author/Change controller: The IETF 1201 Other information: This media type is a specialization of 1202 application/xml [18], and many of the considerations described 1203 there also apply to application/held+xml. 1205 11.4. Error code Registry 1207 This document requests that the IANA create a new registry the HELD 1208 protocol including an initial registry for error codes. The error 1209 codes are included in HELD error messages as described in Section 6.3 1210 and defined in the schema in the 'codeType' token in the XML schema 1211 in (Section 7) 1213 The following summarizes the requested registry: 1215 Related Registry: Geopriv HELD Registries, Error codes for HELD 1216 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1217 with the RFC number for this specification.] 1218 Registration/Assignment Procedures: New error codes are allocated on 1219 a first-come/first-serve basis with specification recommended. 1220 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1221 Mary Barnes (mary.barnes@nortel.com). 1223 This section pre-registers the following seven initial error codes as 1224 described above in Section 6.3: 1226 requestError: This code indicates that the request was badly formed 1227 in some fashion. 1228 xmlError: This code indicates that the XML content of the request 1229 was either badly formed or invalid. 1230 generalLisError: This code indicates that an unspecified error 1231 occurred at the LIS. 1232 locationUnknown: This code indicates that the LIS could not 1233 determine the location of the Device. 1234 unsupportedMessage: This code indicates that the request was not 1235 supported or understood by the LIS. 1236 timeout: This code indicates that the LIS could not satisfy the 1237 request within the time specified in the "responseTime" parameter. 1238 cannotProvideLiType: This code indicates that the LIS was unable to 1239 provide LI of the type or types requested. This code is used when 1240 the "exact" attribute on the "locationType" parameter is set to 1241 "true". 1243 11.5. URI Registration 1245 The following summarizes the information necessary to register the 1246 held: URI. [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the 1247 RFC number for this specification in the following list.] 1248 URI Scheme Name: held 1249 Status: permanent 1250 URI Scheme syntax: See section 1251 URI Scheme Semantics: The held: URI is intended to be used as a 1252 reference to a location object. Further detail is provided in 1253 Section 6.5 of RFCXXXX. 1254 Encoding Considerations: The HELD: URI is not intended to be human- 1255 readable text, therefore they are encoded entirely in US-ASCII. 1256 Applications/protocols that use this URI scheme: The HELD protocol 1257 described in RFCXXXX and the GEOPRIV Location De-reference 1258 Protocol [24] 1259 Interoperability considerations: This URI is intended for use as a 1260 parameter for the HELD protocol and this URI is also used as an 1261 input parameter for the GEOPRIV Location De-reference Protocol 1262 [24]. Refer to Section 6.5 in RFXXXX for further detail, in 1263 particular on the lack of permanence of a specific HELD: URI and 1264 thus the importance of using these URIs only within the specific 1265 contexts outlined in the references. 1266 Security considerations: Section 9 in RFXXXX addresses the necessary 1267 security associated with the transport of location information 1268 between a Device and the LIS to ensure the privacy and integrity 1269 of the held: URI. The schema for the held: URI allows for a 1270 random identifier in the form of a token in the URI Section 6.5 in 1271 RFCXXXX also recommends that the token be allocated such that it 1272 does not reveal any detail at all about the content of the PIDF-LO 1273 that it may indirectly reference. 1274 Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary 1275 Barnes (mary.barnes@nortel.com). 1276 Author/Change controller: This scheme is registered under the IETF 1277 tree. As such, IETF maintains change control. 1278 References: RFC XXXX, GEOPRIV Location De-reference Protocol [24] 1280 12. Contributors 1282 James Winterbottom, Martin Thomson and Barbara Stark are the authors 1283 of the original document, from which this WG document was derived. 1284 Their contact information is included in the Author's address 1285 section. In addition, they also contributed to the WG document, 1286 including the XML schema. 1288 13. Acknowledgements 1290 The author/contributors would like to thank the participants in the 1291 GEOPRIV WG and the following people for their constructive input and 1292 feedback on this document (in alphabetical order): Nadine Abbott, 1293 Eric Arolick, Richard Barnes, Peter Blatherwick, Guy Caron, Martin 1294 Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie, Neil Justusson, 1295 Tat Lam, Marc Linsner, Patti McCalmont, Roger Marshall, Perry 1296 Prozeniuk, Carl Reed, Brian Rosen, John Schnizlein, Shida Schubert, 1297 Henning Schulzrinne, Ed Shrum, Doug Stuard and Hannes Tschofenig. 1299 14. Changes since last Version 1301 NOTE TO THE RFC-Editor: Please remove this section prior to 1302 publication as an RFC. 1304 Changes from WG 03 to 04: 1306 1) Terminology: clarified in terminology section that "attribute" and 1307 "element" are used in the strict XML sense and "parameter" is used as 1308 a general protocol term Replaced term "HTTP delivery" with "HTTP 1309 transport". Still have two terms "HTTP transport" and "HTTP 1310 binding", but those are consistent with general uses of HTTP. 1312 2) Editorial changes and clarifications: per Roger Marshall's and 1313 Eric Arolick's comments and subsequent WG mailing list discussion. 1315 3) Changed normative language for describing expected and recommended 1316 LIS behaviors to be non-normative recommendations in cases where the 1317 protocol parameters were not the target of the discussion (e.g., we 1318 can't prescribe to the LIS how it determines location or what it 1319 defines to be an "accurate" location). 1321 4) Clarified responseTime attribute (section 6.1). Changed type from 1322 "decimal" to "nonNegativeInteger" in XML schema (section 7) 1324 5) Updated Table 1 in section 6 to only include top-level parameters 1325 and fixed some errors in that table (i.e., code for locationResponse) 1326 and adding PIDF-LO to the table. Added a detailed section describing 1327 PIDF-LO (section 6.6), moving some of the normative text in the 1328 Protocol Overview to this section. 1330 6) Added schema and description for locationURI to section 6.5. 1331 Added IANA registration for HELD: URI schema. 1333 7) Added IANA registry for error codes. 1335 Changes from WG 02 to 03: 1337 1) Added text to address concern over use of IP address as device 1338 identifier, per long email thread - changes to section 3 (overview) 1339 and section 4 (protocol overview). 1341 2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed) 1343 3) Added extensibility to baseRequestType in the schema (an oversight 1344 from previous edits), along with fixing some other nits in schema 1345 (section 7) 1347 4) Moved discussion of Location URI from section 5.3 (Location 1348 Response) to where it rightly belonged in Section 6.5 (Location URI 1349 Parameter). 1351 5) Clarified text for "expires" parameter (6.5.1) - it's an optional 1352 parm, but required for LocationURIs 1354 6) Clarified responseTime parameter: when missing, then the LCS 1355 provides most precise LI, with the time required being implementation 1356 specific. 1358 7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST 1359 implement. 1361 8) Updated references (removed unused/added new). 1363 Changes from WG 01 to 02: 1365 1) Updated Terminology to be consistent with WG agreements and other 1366 documents (e.g., LCS -> LIS and removed duplicate terms). In the 1367 end, there are no new terms defined in this document. 1369 2) Modified definition of responseTime to reflect WG consensus. 1371 3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving 1372 just "civic"). 1374 4) Clarified text that locationType is optional. Fixed table 1 and 1375 text in section 5.2 (locationRequest description). Text in section 1376 6.2 (description of locationType element) already defined the default 1377 to be "any". 1379 5) Simplified error responses. Separated the definition of error 1380 response type from the locationResponse type thus no need for 1381 defining an error code of "success". This simplifies the schema and 1382 processing. 1384 6) Updated schema/examples for the above. 1386 7) Updated Appendix A based on updates to requirements document, 1387 specifically changes to A.1, A.3 and adding A.10. 1389 8) Miscellaneous editorial clarifications. 1391 Changes from WG 00 to 01: 1393 1) heldResponse renamed to locationResponse. 1395 2) Changed namespace references for the PIDF-LO geoShape in the 1396 schema to match the agreed GML PIDF-LO Geometry Shape Application 1397 Schema. 1399 3) Removed "options" element - leaving optionality/extensibility to 1400 XML mechanisms. 1402 4) Changed error codes to be enumerations and not redefinitions of 1403 HTTP response codes. 1405 5) Updated schema/examples for the above and removed some remnants of 1406 the context element. 1408 6) Clarified the definition of "Location Information (LI)" to include 1409 a reference to the location (to match the XML schema and provide 1410 consistency of usage throughout the document). Added an additional 1411 statement in section 7.2 (locationType) to clarify that LCS MAY also 1412 return a Location URI. 1414 7) Modifed the definition of "Location Configuration Server (LCS)" to 1415 be consistent with the current definiton in the requirements 1416 document. 1418 8) Updated Location Response (section 6.3) to remove reference to 1419 context and discuss the used of a local identifier or unlinked 1420 pseudonym in providing privacy/security. 1422 9) Clarified that the source IP address in the request is used as the 1423 identifier for the target/device for the HELD protocol as defined in 1424 this document. 1426 10) Miscellaneous editorial clarifications. 1428 15. References 1430 15.1. Normative References 1432 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1433 Levels", BCP 14, RFC 2119, March 1997. 1435 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1436 RFC 2246, January 1999. 1438 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1439 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1440 HTTP/1.1", RFC 2616, June 1999. 1442 [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1444 [5] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 1445 Language) XML-Signature Syntax and Processing", RFC 3275, 1446 March 2002. 1448 [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1449 January 2004. 1451 [7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 1452 Polk, "Geopriv Requirements", RFC 3693, February 2004. 1454 [8] Peterson, J., "A Presence-based GEOPRIV Location Object 1455 Format", RFC 4119, December 2005. 1457 [9] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 1458 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-07 (work in 1459 progress), December 2007. 1461 [10] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1462 PIDF-LO Usage Clarification, Considerations and 1463 Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 (work 1464 in progress), October 2007. 1466 [11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location 1467 Configuration Protocol; Problem Statement and Requirements", 1468 draft-ietf-geopriv-l7-lcp-ps-06 (work in progress), 1469 November 2007. 1471 [12] Thompson, H., Maloney, M., Beech, D., and N. Mendelsohn, "XML 1472 Schema Part 1: Structures Second Edition", World Wide Web 1473 Consortium Recommendation REC-xmlschema-1-20041028, 1474 October 2004, 1475 . 1477 [13] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second 1478 Edition", World Wide Web Consortium Recommendation REC- 1479 xmlschema-2-20041028, October 2004, 1480 . 1482 [14] Thomson, M. and J. Winterbottom, "Discovering the Local 1483 Location Information Server (LIS)", 1484 draft-thomson-geopriv-lis-discovery-03 (work in progress), 1485 September 2007. 1487 [15] Marshall, R., "Requirements for a Location-by-Reference 1488 Mechanism", draft-ietf-geopriv-lbyr-requirements-01 (work in 1489 progress), October 2007. 1491 15.2. Informative References 1493 [16] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 1494 September 1981. 1496 [17] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 1497 and Instant Messaging", RFC 2778, February 2000. 1499 [18] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 1500 RFC 3023, January 2001. 1502 [19] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1503 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1504 Session Initiation Protocol", RFC 3261, June 2002. 1506 [20] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1507 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 1508 January 2005. 1510 [21] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1511 Configuration Protocol Option for Coordinate-based Location 1512 Configuration Information", RFC 3825, July 2004. 1514 [22] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 1515 Registration Procedures for New URI Schemes", BCP 115, 1516 RFC 4395, February 2006. 1518 [23] Polk, J. and B. Rosen, "Location Conveyance for the Session 1519 Initiation Protocol", draft-ietf-sip-location-conveyance-09 1520 (work in progress), November 2007. 1522 [24] Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, M., 1523 and M. Dawson, "An HTTPS Location Dereferencing Protocol Using 1524 HELD", draft-winterbottom-geopriv-deref-protocol-00 (work in 1525 progress), November 2007. 1527 [25] TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 1528 Endpoint Discovery". 1530 Appendix A. HELD Compliance to IETF LCP requirements 1532 This appendix describes HELD's compliance to the requirements 1533 specified in the [11]. 1535 A.1. L7-1: Identifier Choice 1537 "The L7 LCP MUST be able to carry different identifiers or MUST 1538 define an identifier that is mandatory to implement. Regarding the 1539 latter aspect, such an identifier is only appropriate if it is from 1540 the same realm as the one for which the location information service 1541 maintains identifier to location mapping." 1543 COMPLY 1545 HELD uses the IP address of the location request message as the 1546 primary source of identity for the requesting device or target. This 1547 identity can be used with other contextual network information to 1548 provide a physical location for the Target for many network 1549 deployments. There may be network deployments where an IP address 1550 alone is insufficient to identify a Target in a network. However, 1551 any necessary identity extensions for these networks is beyond the 1552 scope of this document. 1554 A.2. L7-2: Mobility Support 1556 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a 1557 broad range of mobility from devices that can only move between 1558 reboots, to devices that can change attachment points with the impact 1559 that their IP address is changed, to devices that do not change their 1560 IP address while roaming, to devices that continuously move by being 1561 attached to the same network attachment point." 1563 COMPLY 1565 Mobility support is inherently a characteristic of the access network 1566 technology and HELD is designed to be access network agnostic. 1567 Consequently HELD complies with this requirement. In addition HELD 1568 provides specific support for mobile environments by providing an 1569 optional responseTime attribute in location request messages. 1570 Wireless networks often have several different mechanisms at their 1571 disposal for position determination (e.g. Assisted GPS versus 1572 location based on serving base station identity), each providing 1573 different degrees of accuracy and taking different amounts of time to 1574 yield a result. The responseTime parameter provides the LIS with a 1575 criterion which it can use to select a location determination 1576 technique. 1578 A.3. L7-3: ASP and Access Network Provider Relationship 1580 "The design of the L7 LCP MUST NOT assume a business or trust 1581 relationship between the Application Service Provider (ASP) and the 1582 Access Network Provider. Requirements for resolving a reference to 1583 location information are not discussed in this document." 1585 COMPLY 1587 HELD describes a location acquisition protocol and has no 1588 dependencies on the business or trust relationship between the ASP 1589 and the Access Network Provider. Location acquisition using HELD is 1590 subject to the restrictions described in Section 9. 1592 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship 1594 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1595 MUST assume that there is a trust and business relationship between 1596 the L2 and the L3 provider. The L3 provider operates the LIS and 1597 needs to obtain location information from the L2 provider since this 1598 one is closest to the end host. If the L2 and L3 provider for the 1599 same host are different entities, they cooperate for the purposes 1600 needed to determine end system locations." 1602 COMPLY 1604 HELD was specifically designed with this model in mind and readily 1605 allows itself to chaining requests between operators without a change 1606 in protocol being required. HELD is a webservices protocol it can be 1607 bound to transports other than HTTP. Using o offers the option of 1608 high request throughput over a dedicated connection between an L3 1609 provider and an L2 provider without incurring the serial restriction 1610 imposed by HTTP. This is less easy to do with protocols that do not 1611 decouple themselves from the transport. 1613 A.5. L7-5: Legacy Device Considerations 1615 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1616 MUST consider legacy residential NAT devices and NTEs in an DSL 1617 environment that cannot be upgraded to support additional protocols, 1618 for example to pass additional information through DHCP." 1620 COMPLY 1622 HELD is an application protocol and operates on top of IP. A HELD 1623 request from a host behind a residential NAT will traverse the NAT 1624 acquiring the external address of the home router. The location 1625 provided to the host therefore will be the address of the home router 1626 in this circumstance. No changes are required to the home router in 1627 order to support this function, HELD was designed specifically to 1628 address this deployment scenario. 1630 A.6. L7-6: VPN Awareness 1632 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1633 MUST assume that at least one end of a VPN is aware of the VPN 1634 functionality. In an enterprise scenario, the enterprise side will 1635 provide the LIS used by the client and can thereby detect whether the 1636 LIS request was initiated through a VPN tunnel." 1638 COMPLY 1640 HELD does not preclude a LIS on the far end of a VPN tunnel being 1641 aware that the client request is occurring over that tunnel. It also 1642 does not preclude a client device from accessing a LIS serving the 1643 local physical network and subsequently using the location 1644 information with an application that is accessed over a VPN tunnel. 1646 A.7. L7-7: Network Access Authentication 1648 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1649 MUST NOT assume prior network access authentication." 1651 COMPLY 1653 HELD makes no assumptions about prior network access authentication. 1654 HELD strongly recommends the use of TLS with server-side certificates 1655 for communication between the end-point and the LIS. There is no 1656 requirement for the end-point to authenticate with the LIS. 1658 A.8. L7-8: Network Topology Unawareness 1660 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1661 MUST NOT assume end systems being aware of the access network 1662 topology. End systems are, however, able to determine their public 1663 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." 1665 COMPLY 1667 HELD makes no assumption about the network topology. HELD doesn't 1668 require that the device know its external IP address, except where 1669 that is required for discovery of the LIS. 1671 A.9. L7-9: Discovery Mechanism 1673 "The L7 LCP MUST define a single mandatory to implement discovery 1674 mechanism." 1676 COMPLY 1678 HELD uses the discovery mechanism in [14]. 1680 A.10. L7-10: PIDF-LO Creation 1682 "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the 1683 element into the element of the presence document 1684 (see RFC 4479). This ensures that the resulting PIDF-LO document, 1685 which is subsequently distributed to other entities, conforms to the 1686 rules outlined in ". [10] 1688 COMPLY 1690 HELD protocol overview (Section 4 ) describes the requirements on the 1691 LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated 1692 by the LIS MUST conform to [10]. 1694 Authors' Addresses 1696 Mary Barnes (editor) 1697 Nortel 1698 2201 Lakeside Blvd 1699 Richardson, TX 1701 Email: mary.barnes@nortel.com 1703 James Winterbottom 1704 Andrew 1705 PO Box U40 1706 Wollongong University Campus, NSW 2500 1707 AU 1709 Phone: +61 2 4221 2938 1710 Email: james.winterbottom@andrew.com 1711 URI: http://www.andrew.com/ 1712 Martin Thomson 1713 Andrew 1714 PO Box U40 1715 Wollongong University Campus, NSW 2500 1716 AU 1718 Phone: +61 2 4221 2915 1719 Email: martin.thomson@andrew.com 1720 URI: http://www.andrew.com/ 1722 Barbara Stark 1723 BellSouth 1724 Room 7A41 1725 725 W Peachtree St. 1726 Atlanta, GA 30308 1727 US 1729 Email: barbara.stark@bellsouth.com 1731 Full Copyright Statement 1733 Copyright (C) The IETF Trust (2008). 1735 This document is subject to the rights, licenses and restrictions 1736 contained in BCP 78, and except as set forth therein, the authors 1737 retain all their rights. 1739 This document and the information contained herein are provided on an 1740 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1741 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1742 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1743 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1744 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1745 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1747 Intellectual Property 1749 The IETF takes no position regarding the validity or scope of any 1750 Intellectual Property Rights or other rights that might be claimed to 1751 pertain to the implementation or use of the technology described in 1752 this document or the extent to which any license under such rights 1753 might or might not be available; nor does it represent that it has 1754 made any independent effort to identify any such rights. Information 1755 on the procedures with respect to rights in RFC documents can be 1756 found in BCP 78 and BCP 79. 1758 Copies of IPR disclosures made to the IETF Secretariat and any 1759 assurances of licenses to be made available, or the result of an 1760 attempt made to obtain a general license or permission for the use of 1761 such proprietary rights by implementers or users of this 1762 specification can be obtained from the IETF on-line IPR repository at 1763 http://www.ietf.org/ipr. 1765 The IETF invites any interested party to bring to its attention any 1766 copyrights, patents or patent applications, or other proprietary 1767 rights that may cover technology that may be required to implement 1768 this standard. Please address the information to the IETF at 1769 ietf-ipr@ietf.org. 1771 Acknowledgment 1773 Funding for the RFC Editor function is provided by the IETF 1774 Administrative Support Activity (IASA).