idnits 2.17.1 draft-hansen-2717bis-2718bis-uri-guidelines-06.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 623. ** 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2717, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2718, but the abstract doesn't seem to mention this, which it should. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 10, 2005) is 6800 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: '3' is defined on line 529, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 547, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (ref. '2') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2279 (ref. '3') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3978 (ref. '5') (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 2717 (ref. '9') (Obsoleted by RFC 4395) -- Obsolete informational reference (is this intentional?): RFC 2718 (ref. '10') (Obsoleted by RFC 4395) -- Obsolete informational reference (is this intentional?): RFC 3406 (ref. '11') (Obsoleted by RFC 8141) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hansen 3 Internet-Draft AT&T Laboratories 4 Obsoletes: 2717,2718 (if approved) T. Hardie 5 Expires: March 14, 2006 Qualcomm, Inc. 6 L. Masinter 7 Adobe Systems 8 September 10, 2005 10 Guidelines and Registration Procedures for new URI Schemes 11 draft-hansen-2717bis-2718bis-uri-guidelines-06.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 14, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document provides guidelines and recommendations for the 45 definition of Uniform Resource Identifier (URI) schemes. It also 46 updates the process and IANA registry for URI schemes. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Guidelines for Permanent URI scheme definitions . . . . . . . 4 52 2.1. Demonstratable, new, long-lived utility . . . . . . . . . 4 53 2.2. Syntactic compatibility . . . . . . . . . . . . . . . . . 4 54 2.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.4. Definition of operations . . . . . . . . . . . . . . . . . 6 56 2.5. Context of use . . . . . . . . . . . . . . . . . . . . . . 6 57 2.6. Internationalization and character encoding . . . . . . . 7 58 2.7. Clear security considerations . . . . . . . . . . . . . . 7 59 2.8. Scheme Name considerations . . . . . . . . . . . . . . . . 7 60 3. Guidelines for Provisional URI Scheme Registration . . . . . . 8 61 4. Guidelines for Historical URI Scheme Registration . . . . . . 8 62 5. URI Scheme Registration Procedure . . . . . . . . . . . . . . 8 63 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.2. Registration Procedures . . . . . . . . . . . . . . . . . 9 65 5.3. Change Control . . . . . . . . . . . . . . . . . . . . . . 10 66 5.4. URI Scheme Registration Template . . . . . . . . . . . . . 10 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 74 Intellectual Property and Copyright Statements . . . . . . . . . . 15 76 1. Introduction 78 The Uniform Resource Identifier (URI) protocol element and generic 79 syntax is defined by RFC 3986 [6]. Each URI begins with a scheme 80 name, as defined by Section 3.1 of RFC 3986, that refers to a 81 specification for identifiers within that scheme. The URI syntax 82 provides a federated and extensible naming system, where each 83 scheme's specification may further restrict the syntax and semantics 84 of identifiers using that scheme. This document provides guidelines 85 for the definition of new URI schemes, for consideration by those who 86 are defining, registering, or evaluating those definitions, as well 87 as a process and mechanism for registering URI schemes within the 88 IANA URI scheme registry. The registry has two parts: "provisional" 89 and "permanent"; with different requirements; guidelines and 90 requirements for both parts are given. 92 This document obsoletes both RFCs 2717 [9] and 2718 [10]. RFCs 2717 93 and 2718 drew a distinction between 'locators' -- identifiers used 94 for accessing resources available on the Internet, and 'names' -- 95 identifiers used for naming possibly abstract resources, independent 96 of any mechanism for accessing them. The intent was to use the 97 designation "URL" (Uniform Resource Locator) for those identifiers 98 that were locators, and "URN" (Uniform Resource Name) for those 99 identifiers that were names. In practice, the line between 'locator' 100 and 'name' has been difficult to draw: locators can be used as names, 101 and names can be used as locators. 103 As a result, recent documents have used the term "URI" for all 104 resource identifiers, avoiding the term "URL", and reserving the term 105 "URN" explicitly for those URIs using the "urn" scheme name (RFC 2141 106 [2]). URN "namespaces" (RFC 3406 [11]) are specific to the "urn" 107 scheme and not covered explicitly by this document. 109 RFC 2717 defined a set of registration trees in which URI schemes 110 could be registered, one of which was called the IETF Tree, to be 111 managed by IANA. RFC 2717 proposed that additional registration 112 trees might be approved by the IESG. However, no such registration 113 trees have been approved. 115 This document eliminates RFC 2717's distinction between different 116 'trees' for URI schemes; instead there is a single namespace for 117 registered values. Within that namespace, there are values that are 118 approved as meeting a set of criteria for URI schemes. Other scheme 119 names may also be registered provisionally, without necessarily 120 meeting those criteria. The intent of the registry is to: 121 o provide a central point of discovery for established URI scheme 122 names, and easy location of their defining documents; 124 o discourage multiple definitions of URI scheme names for different 125 purposes; 126 o help those proposing new URI scheme names to discern established 127 trends and conventions, and avoid names that might be confused 128 with existing ones; 129 o encourage registration by setting a low barrier for provisional 130 registrations. 132 RFC 3987 [7] introduced a new protocol element, the Internationalized 133 Resource Identifier (IRI), and defined a mapping between URIs and 134 IRIs. There is no separate registry or registration process for 135 IRIs. Those who wish to describe resource identifiers that are 136 useful as IRIs should define the corresponding URI syntax, and note 137 that the IRI usage follows the rules and transformations defined in 138 RFC 3987. 140 Within this document, the key words MUST, MAY, SHOULD, REQUIRED, 141 RECOMMENDED and so forth are used within the general meanings 142 established in RFC 2119 [1], within the context that they are 143 requirements on future registration documents. 145 2. Guidelines for Permanent URI scheme definitions 147 This section gives considerations for new URI schemes. Meeting these 148 guidelines is REQUIRED for permanent URI scheme registration. 149 Meeting these guidelines are also RECOMMENDED for provisional 150 registration, as described in Section 3. 152 2.1. Demonstratable, new, long-lived utility 154 The use and deployment of new URI schemes in the Internet 155 infrastructure is costly; some parts of URI processing may be scheme- 156 dependent, and deployed software already processes URIs of well-known 157 schemes. Introducing a new URI scheme may require additional 158 software, not only for client software and user agents but also in 159 additional parts of the network infrastructure (gateways, proxies, 160 caches).[13]. URI schemes constitute a single, global namespace; it 161 is desirable to avoid contention over use of short, mneumonic scheme 162 names. For these reasons, the unbounded registration of new schemes 163 is harmful. New URI schemes SHOULD have clear utility to the broad 164 Internet community, beyond that available with already registered URI 165 schemes. 167 2.2. Syntactic compatibility 169 RFC 3986 [6] defines the generic syntax for all URI schemes, along 170 with the syntax of common URI components that are used by many URI 171 schemes to define hierarchical identifiers. All URI scheme 172 specifications MUST define their own syntax such that all strings 173 matching their scheme-specific syntax will also match the grammar described in Section 4.3 of RFC 3986. 176 New URI schemes SHOULD reuse the common URI components of RFC 3986 177 for the definition of hierarchical naming schemes. However, if there 178 is a strong reason for a URI scheme to not use the hierarchical 179 syntax, then the new scheme definition SHOULD follow the syntax of 180 previously registered schemes. 182 URI schemes that are not intended for use with relative URIs SHOULD 183 avoid use of the forward slash "/" character, which is used for 184 hierarchical delimiters, and the complete path segments "." and ".." 185 (dot-segments). 187 Avoid improper use of "//". The use of double slashes in the first 188 part of a URI is not an artistic indicator that what follows is a 189 URI: Double slashes are used ONLY when the syntax of the URI's 190 contains a hierarchical structure as described 191 in RFC 3986. In URIs from such schemes, the use of double slashes 192 indicates that what follows is the top hierarchical element for a 193 naming authority. (See section 3.2 of RFC 3986 for more details.) 194 URI schemes that do not contain a conformant hierarchical structure 195 in their SHOULD NOT use double slashes 196 following the ":" string. 198 New URI schemes SHOULD clearly define the role of RFC 3986 [6] 199 reserved characters in URIs of the scheme being defined. The syntax 200 of the new scheme should be clear about which of the "reserved" set 201 of characters (as defined in RFC 3986) are used as delimiters within 202 the URIs of the new scheme and when those characters must be escaped, 203 vs. when they may be used without escaping. 205 2.3. Well-Defined 207 While URIs may or may not be useful as locators in practice, a URI 208 scheme definition itself MUST be clear as to how it is expected to 209 function. Schemes that are not intended to be used as locators 210 SHOULD describe how the resource identified can be determined or 211 accessed by software that obtains a URI of that scheme. 213 For schemes that function as locators, it is important that the 214 mechanism of resource location be clearly defined. This might mean 215 different things depending on the nature of the URI scheme. 217 In many cases, new URI schemes are defined as ways to translate 218 between other namespaces or protocols and the general framework of 219 URIs. For example, the "ftp" URI scheme translates into the FTP 220 protocol, while the "mid" URI scheme translates into a Message-ID 221 identifier of an email message. For such schemes, the description of 222 the mapping must be complete, and in sufficient detail so that the 223 mapping in both directions is clear: how to map from a URI into an 224 identifier or set of protocol actions or name in the target 225 namespace, and how legal values in the base namespace, or legal 226 protocol interactions, might be represented in a valid URI. In 227 particular, the mapping should describe the mechanisms for encoding 228 binary or character strings within valid character sequences in a URI 229 (See Section 2.6 for guidelines). If not all legal values or 230 protocol interactions of the base standard can be represented using 231 the URI scheme, the definition should be clear about which subset are 232 allowed, and why. 234 2.4. Definition of operations 236 As part of the definition of how a URI identifies a resource, a URI 237 scheme definition SHOULD define the applicable set of operations that 238 may be performed on a resource using the URI as its identifier. A 239 model for this is HTTP; an HTTP resource can be operated on by GET, 240 POST, PUT and a number of other operations available through the HTTP 241 protocol. The URI scheme definition should describe all well-defined 242 operations on the URI identifier, and what they are supposed to do. 244 Some URI schemes don't fit into the "information access" paradigm of 245 URIs. For example, "telnet" provides location information for 246 initiating a bi-directional data stream to a remote host; the only 247 operation defined is to initiate the connection. In any case, the 248 operations appropriate for a URI scheme should be documented. 250 NOTE: It is perfectly valid to say that "no operation apart from GET 251 is defined for this URI". It is also valid to say that "there's only 252 one operation defined for this URI, and it's not very GET-like". The 253 important point is that what is defined on this scheme is described. 255 2.5. Context of use 257 In general, URIs are used within a broad range of protocols and 258 applications. Most commonly, URIs are used as references to 259 resources within directories or hypertext documents, as hyperlinks to 260 other resources. In some cases, a URI scheme is intended for use 261 within a different, specific set of protocols or applications. If 262 so, the scheme defintion SHOULD describe the intended use and include 263 references to documentation that define the applications and/or 264 protocols cited. 266 2.6. Internationalization and character encoding 268 When describing URI schemes in which (some of) the elements of the 269 URI are actually representations of human-readable text, care should 270 be taken not to introduce unnecessary variety in the ways in which 271 characters are encoded into octets and then into URI characters; see 272 RFC 3987 [7] and section 2.5 of RFC 3986 [6] for guidelines. If URIs 273 of a scheme contain any text fields, the scheme definition MUST 274 describe the ways in which characters are encoded, and any 275 compatibility issues with IRIs of the scheme. 277 2.7. Clear security considerations 279 Definitions of URI schemes MUST be accompanied by a clear analysis of 280 the security implications for systems that use the URI scheme; this 281 follows the practice of Security Consideration sections within IANA 282 registrations[4]. 284 In particular, section 7 of RFC 3986[6] describes general security 285 considerations for URI schemes. The definition of an individual URI 286 scheme should note which of these apply to the specified scheme. 288 2.8. Scheme Name considerations 290 Section 3.1 of RFC 3986 defines the syntax of a URI scheme name. New 291 scheme registrations MUST comply. Note that although scheme names 292 are case insensitive, scheme names MUST be registered using lowercase 293 letters. 295 URI scheme names should be short, but also sufficiently descriptive 296 and distinguished to avoid problems. 298 Avoid names or other symbols that might cause problems with rights to 299 use the name in IETF specifications and Internet protocols. For 300 example, be careful with trademark and service mark names. (See 301 section 7.4 of RFC 3978 [5].) 303 Avoid using names that are either very general purpose or associated 304 in the community with some other application or protocol. Avoid 305 scheme names that are overly general or grandiose in scope (e.g., 306 that allude to their "universal" or "standard" nature when the 307 described namespace is not.) 309 Organizations that desire a private name space for URI scheme names 310 are encouraged to use a prefix based on their domain name, expressed 311 in reverse order. For example, a URI scheme name of com-example-info 312 might be registered by the vendor that owns the example.com domain 313 name. 315 3. Guidelines for Provisional URI Scheme Registration 317 While the guidelines in Section 2 are REQUIRED for permanent 318 registration, they are RECOMMENDED for provisional registration. For 319 a provisional registration, the following are REQUIRED: 320 o The scheme name meets the syntactic requirements of Section 2.8. 321 o There is not already a entry with the same URI scheme name. (In 322 the unfortunate case that there are multiple, different uses of 323 the same scheme name, the IESG may approve a request to modify an 324 existing entry to note the separate use.) 325 o Contact information identifying the person supplying the 326 registration is included. Previously unregistered URI schemes 327 discovered in use may be registered by third parties on behalf of 328 those who created the URI scheme; in this case, both the 329 registering party and the scheme creator SHOULD be identified. 330 o If no permanent, citable specification for the URI scheme 331 definition is included, credible reasons for not providing it 332 should be given. 333 o A valid security considerations section, as required by section 6 334 of [4]. 335 o If the scheme definition does not meet the guidelines laid out in 336 Section 2, the differences and reasons SHOULD be noted. 338 4. Guidelines for Historical URI Scheme Registration 340 In some circumstances, it is appropriate to note a URI scheme that 341 was once in use or registered but for whatever reason is no longer in 342 common use or the use is not recommended. In this case, it is 343 possible for an individual to request that the URI scheme be 344 registered (newly, or as an update to an existing registration) as 345 'historical'. Any scheme that is no longer in common use MAY be 346 designated as historical; the registration should contain some 347 indication to where the scheme was previously defined or documented. 349 5. URI Scheme Registration Procedure 351 5.1. General 353 The URI registration process is described in the terminology of [4]. 354 The registration process is an optional mailing list review, followed 355 by "Expert Review". The registration request should note the desired 356 status. The Designated Expert will evaluate the request against the 357 criteria of the requested status. In the case of a permanent 358 registration request, the Designated Expert may: 360 o Accept the URI scheme name for Permanent registration. 361 o Suggest provisional registration instead. 362 o Request IETF review and IESG approval; in the meanwhile, suggest 363 provisional registration. 365 URI scheme definitions contained within other IETF documents 366 (Informational, Experimental or Standards-Track RFCs) must also 367 undergo Expert Review; in the case of Standards-Track documents, 368 permanent registration status approval is required. 370 5.2. Registration Procedures 372 Someone wishing to register a URI scheme SHOULD: 373 1. Check the IANA URI scheme registry to see whether or not there is 374 already an entry for the desired name. If there is already an 375 entry under the name, choose a different URI scheme name. 376 2. Prepare a URI scheme registration template, as specified in 377 Section 5.4. The URI scheme registration template may be 378 contained in an Internet Draft, alone or as part of some other 379 protocol specification. The template may also be submitted in 380 some other form (as part of another document or as a stand-alone 381 document), but the contents will be treated as an "IETF 382 Contribution" under the guidelines of RFC 3987 [5]. 383 3. Send a copy of the template or a pointer to the containing 384 document (with specific reference to the section with the 385 template) to the mailing list uri-review@ietf.org, requesting 386 review. In addition, request review on other mailing lists as 387 appropriate. For example, general discussion of URI syntactical 388 issues could be discussed on uri@w3.org; schemes for a network 389 protocol could be discussed on a mailing list for that protocol. 390 Allow a reasonable time for discussion and comments. Four weeks 391 is reasonable for a permanent registration requests. 392 4. Respond to review comments and make revisions to the proposed 393 registration as needed to bring it into line with the guidelines 394 given in this document. 395 5. Submit the (possibly updated) registration template (or pointer 396 to document containing it) to IANA at iana@iana.org, specifying 397 whether 'permanent' or 'provisional' registration is requested. 399 Upon receipt of a URI scheme registration request, 400 1. IANA checks the submission for completeness; if sections are 401 missing or citations are not correct, IANA rejects the 402 registration request. 403 2. IANA checks the current registry for a entry with the same name; 404 if such a registry exists, IANA rejects the registration request. 405 3. IANA requests Expert Review of the registration request against 406 the corresponding guidelines. 408 4. The Designated Expert may request additional review or 409 discussion, as necessary. 410 5. If Expert Review recommends registration 'provisional' or 411 'provisional' registration, IANA adds the registration to the 412 appropriate registry. 413 6. Unless Expert Review has explicitly rejected the registration 414 request within two weeks, IANA should automatically add the 415 registration in the 'provisional' registry. 417 Either based on an explicit request or independently initiated, the 418 Designated Expert or IESG may request the upgrade of a 'provisional' 419 registration to a 'permanent' one. In such cases, IANA should move 420 the corresponding entry from the provisional registry. 422 5.3. Change Control 424 Registrations may be updated in each registry by the same mechanism 425 as required for an initial registration. In cases where the original 426 definition of the scheme is contained in an IESG-approved document, 427 update of the specification also requires IESG approval. 429 Provisional registrations may be updated by the original registrant 430 or anyone designated by them. In addition, the IESG may reassign 431 responsibility for a provisional registration scheme, or may request 432 specific changes to a scheme registration. This will enable changes 433 to be made to schemes where the original registrator is out of 434 contact, or unwilling or unable to make changes. 436 Transition to 'permanent' status (or from 'permanent' to 'historical' 437 status) requires IESG approval; transition from 'provisional' to 438 'historical' may be requested by anyone authorized to update the 439 provisional registration. 441 5.4. URI Scheme Registration Template 443 This template describes the fields that must be supplied in a URI 444 scheme registration request: 445 URI scheme name. 446 See Section 2.8 for guidelines. 447 Status. 448 This reflects the status requested, and should be one of 449 'permanent', 'provisional' or 'historical'. 450 URI scheme syntax. 451 See Section 2.2 for guidelines. 453 URI scheme semantics. 454 See Section 2.3 and Section 2.4 for guidelines. 455 Encoding considerations. 456 See Section 2.3 and Section 2.6 for guidelines. 457 Applications/protocols that use this URI scheme name. 458 Applications and/or protocols that use this URI scheme name; see 459 Section 2.5. 460 Interoperability considerations. 461 If you are aware of any details regarding your scheme that might 462 impact interoperability, please identify them here. For example: 463 proprietary or uncommon encoding method; inability to support 464 multibyte character sets; incompatibility with types or versions 465 of any underlying protocol. 466 Security considerations. 467 See Section 2.7 for guidelines. 468 Contact. 469 Person (including contact information) to contact for further 470 information. 471 Author/Change controller. 472 Person (including contact information) authorized to change this, 473 if a provisional registration. 474 References. 475 Include full citations for all referenced documents. Registration 476 templates for provisional registration may be included in an 477 Internet Draft; when the documents expire or are approved for 478 publication as an RFC, the registration will be updated. 480 6. IANA Considerations 482 This document replaces the current "URL Scheme" registry with a new 483 Uniform Resource Identifier scheme registry, establishes a new 484 registration template and a new process for registration. The 485 process is based on [4] "Expert Review" with an initial (optional) 486 mailing list review. 488 The template has an additional field for the status of the URI name 489 scheme, and the procedures for entering new name schemes have been 490 augmented. Section Section 5 establishes the process for new URI 491 scheme registration. 493 To transition to the new registry, all URL name schemes in the 494 existing table should be entered as URI schemes, with 'permanent' 495 status. 497 7. Security Considerations 498 All registered values are expected to contain accurate security 499 consideration sections; 'permanent' registered scheme names are 500 expected to contain complete definitions. 502 Information concerning possible security vulnerabilities of a 503 protocol may change over time. Consequently, claims as to the 504 security properties of a registered URI scheme may change as well. 505 As new vulnerabilities are discovered, information about such 506 vulnerabilities may need to be attached to existing documentation, so 507 that users are not misled as to the true security properties of a 508 registered URI scheme. 510 8. Acknowledgements 512 Many thanks to Paul Hoffmann, Ira McDonald, Roy Fielding, Stu Weibel, 513 Tony Hammond, Charles Lindsey, Mark Baker and other members of the 514 uri@w3.org [14] mailing list for their comments on earlier drafts. 516 Parts of this document are based on [9], [10] and [12]. Some of the 517 ideas about use of URIs were taken from the 'Architecture of the 518 World Wide Web' [13]. 520 9. References 522 9.1. Normative References 524 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 525 Levels", BCP 14, RFC 2119, March 1997. 527 [2] Moats, R., "URN Syntax", RFC 2141, May 1997. 529 [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 530 RFC 2279, January 1998. 532 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 533 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 535 [5] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, 536 March 2005. 538 [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 539 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 540 January 2005. 542 [7] Duerst, M. and M. Suignard, "Internationalized Resource 543 Identifiers (IRIs)", RFC 3987, January 2005. 545 9.2. Informative References 547 [8] Bradner, S., "The Internet Standards Process -- Revision 3", 548 BCP 9, RFC 2026, October 1996. 550 [9] Petke, R. and I. King, "Registration Procedures for URL Scheme 551 Names", BCP 35, RFC 2717, November 1999. 553 [10] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 554 "Guidelines for new URL Schemes", RFC 2718, November 1999. 556 [11] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 557 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 558 BCP 66, RFC 3406, October 2002. 560 [12] Klyne, G., Nottingham, M., and J. Mogul, "Registration 561 Procedures for Message Header Fields", BCP 90, RFC 3864, 562 September 2004. 564 [13] W3C Technical Architecture Group, "Architecture of the World 565 Wide Web, Volume One", December 2004, 566 . 568 URIs 570 [14] 572 Authors' Addresses 574 Tony Hansen 575 AT&T Laboratories 576 200 Laurel Ave. 577 Middletown, NJ 07748 578 USA 580 Email: tony+urireg@maillennium.att.com 582 Ted Hardie 583 Qualcomm, Inc. 584 675 Campbell Technology Parkway 585 Suite 200 586 Campbell, CA 587 USA 589 Email: hardie@qualcomm.com 591 Larry Masinter 592 Adobe Systems 593 345 Park Ave 594 San Jose, CA 95110 595 US 597 Phone: +1 408 536 3024 598 Email: LMM@acm.org 599 URI: http://larry.masinter.net 601 Intellectual Property Statement 603 The IETF takes no position regarding the validity or scope of any 604 Intellectual Property Rights or other rights that might be claimed to 605 pertain to the implementation or use of the technology described in 606 this document or the extent to which any license under such rights 607 might or might not be available; nor does it represent that it has 608 made any independent effort to identify any such rights. Information 609 on the procedures with respect to rights in RFC documents can be 610 found in BCP 78 and BCP 79. 612 Copies of IPR disclosures made to the IETF Secretariat and any 613 assurances of licenses to be made available, or the result of an 614 attempt made to obtain a general license or permission for the use of 615 such proprietary rights by implementers or users of this 616 specification can be obtained from the IETF on-line IPR repository at 617 http://www.ietf.org/ipr. 619 The IETF invites any interested party to bring to its attention any 620 copyrights, patents or patent applications, or other proprietary 621 rights that may cover technology that may be required to implement 622 this standard. Please address the information to the IETF at 623 ietf-ipr@ietf.org. 625 Disclaimer of Validity 627 This document and the information contained herein are provided on an 628 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 629 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 630 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 631 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 632 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 633 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 635 Copyright Statement 637 Copyright (C) The Internet Society (2005). This document is subject 638 to the rights, licenses and restrictions contained in BCP 78, and 639 except as set forth therein, the authors retain all their rights. 641 Acknowledgment 643 Funding for the RFC Editor function is currently provided by the 644 Internet Society.