idnits 2.17.1 draft-thomson-geopriv-provided-by-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 333. ** 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 (October 11, 2005) is 6772 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV Working Group M. Thomson 3 Internet-Draft Andrew 4 Expires: April 14, 2006 J. Polk 5 Cisco 6 October 11, 2005 8 Using URIs for the PIDF-LO 'provided-by' element 9 draft-thomson-geopriv-provided-by-00.txt 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 April 14, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The "provided-by" element in PIDF-LO is a container designed to carry 43 information about the source of location information. This document 44 defines an XML structure that can be used within the "provided-by" 45 element to convey basic information about the information provider in 46 the form of a URI. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. provided-by URI . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.1. URI Usage . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. provided-by URI Schema . . . . . . . . . . . . . . . . . . . . 5 55 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 6.1. URN sub-namespace registration for 59 'urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri' . . . . . . 8 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 64 Intellectual Property and Copyright Statements . . . . . . . . . . 11 66 1. Introduction 68 The PIDF-LO document [I-D.ietf-geopriv-pidf-lo] defines the 69 "provided-by" element, which is to be used to identify the 70 organization that provided the location information to the endsystem. 71 The "provided-by" element is designed to either augment provider 72 identity information contained in a digital signature, or provide 73 some information in the absence of a signature. The "provided-by" 74 element can also be used to identify an original provider in the case 75 where information is made available by a third party. 77 The PIDF-LO specification [I-D.ietf-geopriv-pidf-lo] includes a 78 definition for a "provided-by" element, that is, for the National 79 Emergency Number Association (NENA), which is North America specific. 80 This document includes a lightweight definition that is more widely 81 applicable. 83 The URI form specified in this document provides a loose means of 84 identifying the provider of location information to the endsystem. 85 It is characterized as "loose" since it the information can only be 86 used as a hint, see Section 5 for details. 88 1.1. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. provided-by URI 96 This document defines "provided-by" content, the "uri" element, that 97 can be used to convey URIs. 99 A URI provides a very flexible means of conveying information. To 100 that end, this document does not mandate specific processing for the 101 "provided-by" element. A User Agent MAY interpret the "provided-by" 102 element in any fashion it considers appropriate, which could simply 103 be to ignore the field entirely. Where URIs are made available, a 104 User Agent SHOULD only use any URI on explicit user direction. 106 It is RECOMMENDED that, where applicable, any URI included in the 107 "provided-by" element be accessible from the public internet without 108 requiring authentication. 110 There MAY be more than one "uri" element in a PIDF-LO so that 111 multiple URIs can be present. It MAY also be used in combination 112 with other "provided-by" content. 114 2.1. URI Usage 116 URIs included in the "provided-by" element can be used for many 117 purposes. The "type" attribute MAY be included to provide a hint to 118 a User Agent about how a URI could be used if it isn't evident from 119 the URI scheme. The following values are defined: 121 contact: The URI can be used to contact the providing organization. 122 This is similar to the "contact" element defined in PIDF 123 [RFC3863]. It is RECOMMENDED that this field include a URI in a 124 scheme that can be used for establishing a media session, such as 125 sip, sips or tel. 127 location: The URI references location information pertaining to the 128 organization or the specific campus, which should be in the form 129 of a PIDF-LO document. 131 info: The URI references general information, which might include 132 information on the privacy policy of the organization; an 133 explanation of how location information is determined by the 134 organization; or any other information. 136 No guidance is provided on how URIs are used, however it is expected 137 that a User Agent use default handling behavior for each scheme. For 138 instance, an http URI might be passed to a web browser or a sips URI 139 might be passed to a SIP UA. 141 3. provided-by URI Schema 143 The following schema defines a "uri" element that can be used for 144 "provided-by" URIs. 146 147 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 171 4. Example 173 The following example demonstrates the inclusion of multiple URIs in 174 the "provided-by" element. 176 177 182 183 184 185 186 187 DE 188 BayernOberbayern 189 München 190 Marienplatz8 191 80331 192 193 194 195 no 196 197 198 http://www.example.com/info/pidf-lo/ 199 sips:location@example.com 200 201 mailto:location@example.com?subject=PIDF-LO 202 203 204 205 206 207 209 5. Security Considerations 211 The information in the "provided-by" element does not provide any 212 assurance that the entity referred to is actually the provider of the 213 location information. Specifically, the contents of a "provided-by" 214 element do not provide a cryptographic assertion of identity of any 215 nature. 217 Unless location information is digitally signed, it is very easy to 218 provide fraudulent information within this field. For example, a 219 PIDF-LO from "example.cracker.com" might include a URI to the well- 220 known and trusted "example.com" web site. This attack could be used 221 to trick users into thinking that the location information was 222 provided by "example.com". 224 When a PIDF-LO is not digitally signed by an authenticated and 225 sufficiently authorized entity the following restrictions apply: 227 o Users of the information MUST NOT represent any authentication 228 information provided when dereferencing the URI as the provider of 229 location information. 231 o Users of this information MUST NOT use the information for any 232 purpose beyond informational. 234 It is RECOMMENDED that a User Agent observe these restrictions even 235 when a digital signature is present. 237 6. IANA Considerations 239 This document calls for IANA to register a new XML namespace, as per 240 the guidelines in [RFC3688]. 242 6.1. URN sub-namespace registration for 243 'urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri' 245 URI 246 urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri 248 Registrant Contact 249 IETF, GEOPRIV working group 250 Martin Thomson 252 XML 253 BEGIN 254 255 257 258 259 GEOPRIV provided-by URI 260 261 262

URI element for the provided-by element in PIDF-LO

263

urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri

264

See RFCXXXX.

265 266 267 END 269 7. References 271 7.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, March 1997. 276 [I-D.ietf-geopriv-pidf-lo] 277 Peterson, J., "A Presence-based GEOPRIV Location Object 278 Format", draft-ietf-geopriv-pidf-lo-03 (work in progress), 279 September 2004. 281 7.2. Informative References 283 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 284 January 2004. 286 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 287 W., and J. Peterson, "Presence Information Data Format 288 (PIDF)", RFC 3863, August 2004. 290 Authors' Addresses 292 Martin Thomson 293 Andrew 294 PO Box U40 295 Wollongong University Campus, NSW 2500 296 AU 298 Phone: +61 2 4221 2915 299 Email: martin.thomson@andrew.com 300 URI: http://www.andrew.com/ 302 James M. Polk 303 Cisco 304 3913 Treemont Circle 305 Colleyville, Texas 76034 306 USA 308 Phone: +1-817-271-3552 309 Email: jmpolk@cisco.com 311 Intellectual Property Statement 313 The IETF takes no position regarding the validity or scope of any 314 Intellectual Property Rights or other rights that might be claimed to 315 pertain to the implementation or use of the technology described in 316 this document or the extent to which any license under such rights 317 might or might not be available; nor does it represent that it has 318 made any independent effort to identify any such rights. Information 319 on the procedures with respect to rights in RFC documents can be 320 found in BCP 78 and BCP 79. 322 Copies of IPR disclosures made to the IETF Secretariat and any 323 assurances of licenses to be made available, or the result of an 324 attempt made to obtain a general license or permission for the use of 325 such proprietary rights by implementers or users of this 326 specification can be obtained from the IETF on-line IPR repository at 327 http://www.ietf.org/ipr. 329 The IETF invites any interested party to bring to its attention any 330 copyrights, patents or patent applications, or other proprietary 331 rights that may cover technology that may be required to implement 332 this standard. Please address the information to the IETF at 333 ietf-ipr@ietf.org. 335 Disclaimer of Validity 337 This document and the information contained herein are provided on an 338 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 339 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 340 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 341 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 342 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 343 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 345 Copyright Statement 347 Copyright (C) The Internet Society (2005). This document is subject 348 to the rights, licenses and restrictions contained in BCP 78, and 349 except as set forth therein, the authors retain all their rights. 351 Acknowledgment 353 Funding for the RFC Editor function is currently provided by the 354 Internet Society.