idnits 2.17.1 draft-mealling-iana-xmlns-registry-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 == Line 90 has weird spacing: '...ssigned then ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 17, 2003) is 7618 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) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Downref: Normative reference to an Informational RFC: RFC 3151 == Outdated reference: A later version (-14) exists of draft-mealling-iana-urn-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Mealling 3 Internet-Draft VeriSign, Inc. 4 Expires: December 16, 2003 June 17, 2003 6 The IETF XML Registry 7 draft-mealling-iana-xmlns-registry-05.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on December 16, 2003. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document describes an IANA maintained registry for IETF 38 standards which use Extensivle Markup Language (XML) related items 39 such as Namespaces, Document Type Declarations (DTDs), Schemas, and 40 Resource Description Framework (RDF) Schemas. 42 1. Introduction 44 Over the past few years the Extensible Markup Language (XML) 45 [W3C.REC-xml] has become a widely used method for data markup. There 46 have already been several IETF Working Groups that have produced 47 standards that define XML Document Type Definitions (DTDs), XML 48 Namespaces [W3C.REC-xml-names] and XML Schemas [W3C.REC-xmlschema-1]. 49 Each one of these technologies uses Uniform Resource Identifiers 50 (URIs) [RFC2396] and other standardized identifiers to identify 51 various components. 53 For example, while it has been the practice within some standards 54 that use Document Type Definitions (DTDs) to forego the use of the 55 PUBLIC identifiers in favor of 'well known' SYSTEM identifiers, it 56 has proven to be more trouble than its worth to attempt to 57 standardize SYSTEM identifiers. The result is that several IETF 58 standards that have simply created non-resolvable URIs in order to 59 simply identify but not resolve the DTD for some given XML document. 61 This document seeks to standardize and improve these practices by 62 creating an IANA maintained registry of XML element identifiers so 63 that document authors and implementors have a well maintained and 64 authoritative location for their XML elements. As part of this 65 standard, the IANA will maintain 67 o the public representation of the document, 69 o the URI for the elements if one is provided at the time of 70 registration, 72 o a registry of Public Identifiers as URIs. 74 In the case where the registrant does not request a particular URI, 75 the IANA will assign it a Uniform Resource Name that follows 76 [RFCXXXX]. 78 2. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119. 84 3. Registerable Documents 86 3.1 The Assigned/Registered URI 88 All elements (except PUBLIC identifiers) in this registry will 89 require a URI in order to be registered. If the registrant wishes to 90 have a URI assigned then a URN of the form: 92 urn:ietf:params:xml:: 94 will be assigned where is the type of the document being 95 registered (see below). is a unique id generated by the IANA 96 based on any means the IANA deems necessary to maintain uniqueness 97 and persistence. NOTE: in order for a URN of this type to be 98 assigned, the item being registered MUST have been through the IETF 99 concensus process. Practically this means it must be documented in an 100 RFC. The RFC XXXX [RFCXXXX] URN registration template is found in 101 Section 6. 103 The IANA will also maintain a file server available via at least HTTP 104 and FTP that contains all of the registered elements in some publicly 105 accessible file space in the same way that all of the IANA's 106 registered elements are available via 107 http://www.iana.org/assignments/. While the directory structure of 108 this server is up to the IANA, it is suggested that the files be 109 organized by the and the individual files have the as 110 their filename. 112 Implementors are warned that they should not programatically rely on 113 those resources being available or the directory structure remaining 114 static for any reason. It is explicitly recognized that some software 115 tools attempt to download DTDs, schema, etc 'on the fly' and that 116 developers should understand when this is done and to not reference 117 IANA network resources as a 'schema download repository'. This is the 118 reason that the IANA will not register or provide SYSTEM identifiers. 120 3.2 Registerable Classes 122 The list of types of XML elements that can be registered with the 123 IANA are: 125 publicid -- An XML document that contains a DOCTYPE declaration or 126 any other external reference can identify that reference via both 127 a PUBLIC identifier and a SYSTEM identifier. The SYSTEM identifier 128 is system-specific information that enables the entity manager of 129 an XML system to locate the file, memory location, or pointer 130 within a file where the entity can be found. It should also be 131 noted that a system identifier could be an invocation of a program 132 that controls access to an entity that is being identified. Thus 133 they are not registered items. In many cases, SYSTEM identifiers 134 are also URIs but in these cases the URI is still only used for 135 system-specific information. In the case where a PUBLIC Identifier 136 is also a URI it is possible for the SYSTEM Identifier to contain 137 the same URI but this behavior is not recommended unless its side 138 effects are well known and understood to not cause any 139 unacceptable harm. 141 A PUBLIC identifier is a name that is intended to be meaningful 142 across systems and different user environments. Typically it will 143 be a name that has a registered owner associated with it, so that 144 public identifiers will be guaranteed unique and no two entities 145 will have the same public identifier. In practice, PUBLIC 146 identifiers are typically Formal Public Identifers [ISO.8879.1986] 147 but they are not restricted to just that set. As said in 148 [RFC3151]: 150 "Any string which consists only of the public identifier 151 characters (defined by Production 13 of Extensible Markup 152 Language (XML) 1.0 Second Edition) is a legal public 153 identifier." 155 Therefore it is legal for a PUBLIC identifier to be a URN if it 156 adheres to the character set restrictions. 158 Thus, the identifier registered along with a DTD is its PUBLIC 159 identifier. The only restriction being that it must adhere to the 160 character set restrictions. In the case where the registrant does 161 not provide one, the IANA will assign one of the form 162 'urn:ietf:params:xml:pi:'. Registrants are encouraged to 163 investigate RFC 3151 [RFC3151] as a recommended method for 164 minting a URN that can also be represented as an FPI. 166 ns -- XML Namespaces [W3C.REC-xml-names] are named by a URI. They 167 have no real, machine-parseable representation. Thus the 168 registered document will be either the specification or a 169 reference to it. In the case where a URI is not provided by the 170 registrant, the IANA will assign a URN of the form 171 'urn:ietf:params:xml:ns: which will be the XML Namespace's 172 name. 174 schema -- XML Schemas [W3C.REC-xmlschema-1] are also identified by a 175 URI but their contents are machine parseable. The IANA registered 176 document will be the XML Schema file. The URN the IANA assigns can 177 be used as the URI for the schema and is of the form 178 'urn:ietf:params:xml:schema:'. 180 rdfschema -- The Resource Description Format (RDF) 181 [W3C.CR-rdf-schema] is an XML serialization of a connected graph 182 based data model used for metadata expression. RDF makes use of 183 schemas for RDF that express grammars about relationships between 184 URIs. These grammars are identified by URIs. The URN assigned by 185 the IANA can be used as the identifying URI and is of the form 186 'urn:ietf:params:xml:rdfschema:'. 188 4. Registration Procedures 190 Until such time as the IANA requests or implements an automated 191 process for the registration of these elements, any specifications 192 wishing to do so must make that request part of the IANA 193 considerations section of their respective documents. That request 194 must be in the form of the following template: 196 URI 197 The URI or PUBLIC identifier that identifies the XML component. 198 If the registrant is requesting that the IANA assign a URI then 199 this field should be specified as "please assign" 201 Registrant Contact 202 The individual/organization that is the registration contact for 203 the component being registered. Ideally this will be the name and 204 pertinent physical and network contact information. In the case of 205 IETF developed standards the Registrant will be the IESG. 207 XML 208 The exact XML to be stored in the registry. Unless otherwise 209 obvious what the beginning and end of the file are, the document 210 should use the text "BEGIN" to mark the beginning of the file and 211 "END" to mark the end of the file. The IANA will insert any text 212 between those two strings (minus any page breaks and RFC 213 formatting inserted by the RFC Editor) into the file kept in the 214 repository. 216 5. Security Considerations 218 The information maintained by the IANA will be authoritative and thus 219 will be a target for attack. In some cases, such as XML Schema and 220 DTDs, the content maintained by the IANA may be directly input into 221 software. Thus, extra care should be taken by the IANA to maintain 222 the security precautions required for an important reference location 223 for the Internet. 225 Beyond this concern there are no other security considerations not 226 already found with any other IANA registry. 228 6. IANA Considerations 230 This documents seeks to create a rather large registry for which the 231 IANA (at the direction of the IESG) will be primarily responsible. 232 The amount of effort required to maintain this registry is not 233 insignificant and the policies and procedures surrounding any 234 approval process are non-trivial. The registry is on a First Come 235 First Served basis but at this time a Specification is Required. Once 236 the IETF has some experience with this registry these policies may 237 change. 239 RFC XXXX [RFCXXXX] specifies that any new registry that requires a 240 name to be assigned below the 'urn:ietf:params' namespace must 241 specify the structure of that space in template form. The IANA is 242 directed to create and maintain this new sub-namespace: 244 Registry-name: xml 246 Specification: This document contains the registry specification. The 247 namespace is organized with one sub-namespace which is the . 249 Repository: To be assigned according to the guidelines found above. 251 Index value: The class name 253 Normative References 255 [ISO.8879.1986] 256 International Organization for Standardization, 257 "Information processing - Text and office systems - 258 Standard generalized markup language (SGML)", ISO Standard 259 8879, 1986. 261 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 262 Resource Identifiers (URI): Generic Syntax", RFC 2396, 263 August 1998. 265 [RFC3151] Walsh, N., Cowan, J. and P. Grosso, "A URN Namespace for 266 Public Identifiers", RFC 3151, August 2001. 268 [RFCXXXX] Mealling, M., Masinter, L., Hardie, T. and G. Klyne, "An 269 IETF URN Sub-namespace for Registered Protocol 270 Parameters", draft-mealling-iana-urn-02.txt (work in 271 progress), August 2001. 273 [W3C.CR-rdf-schema] 274 Brickley, D. and R. Guha, "Resource Description Framework 275 (RDF) Schema Specification 1.0", W3C CR-rdf-schema, March 276 2000, . 278 [W3C.REC-xml] 279 Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 280 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C 281 REC-xml, October 2000, . 283 [W3C.REC-xml-names] 284 Bray, T., Hollander, D. and A. Layman, "Namespaces in 285 XML", W3C REC-xml-names, January 1999, . 288 [W3C.REC-xmlschema-1] 289 Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, 290 "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 291 2001, . 293 Author's Address 295 Michael Mealling 296 VeriSign, Inc. 298 Mountain View, CA 299 US 301 URI: http://www.research.verisignlabs.com 303 Intellectual Property Statement 305 The IETF takes no position regarding the validity or scope of any 306 intellectual property or other rights that might be claimed to 307 pertain to the implementation or use of the technology described in 308 this document or the extent to which any license under such rights 309 might or might not be available; neither does it represent that it 310 has made any effort to identify any such rights. Information on the 311 IETF's procedures with respect to rights in standards-track and 312 standards-related documentation can be found in BCP-11. Copies of 313 claims of rights made available for publication and any assurances of 314 licenses to be made available, or the result of an attempt made to 315 obtain a general license or permission for the use of such 316 proprietary rights by implementors or users of this specification can 317 be obtained from the IETF Secretariat. 319 The IETF invites any interested party to bring to its attention any 320 copyrights, patents or patent applications, or other proprietary 321 rights which may cover technology that may be required to practice 322 this standard. Please address the information to the IETF Executive 323 Director. 325 Full Copyright Statement 327 Copyright (C) The Internet Society (2003). All Rights Reserved. 329 This document and translations of it may be copied and furnished to 330 others, and derivative works that comment on or otherwise explain it 331 or assist in its implementation may be prepared, copied, published 332 and distributed, in whole or in part, without restriction of any 333 kind, provided that the above copyright notice and this paragraph are 334 included on all such copies and derivative works. However, this 335 document itself may not be modified in any way, such as by removing 336 the copyright notice or references to the Internet Society or other 337 Internet organizations, except as needed for the purpose of 338 developing Internet standards in which case the procedures for 339 copyrights defined in the Internet Standards process must be 340 followed, or as required to translate it into languages other than 341 English. 343 The limited permissions granted above are perpetual and will not be 344 revoked by the Internet Society or its successors or assignees. 346 This document and the information contained herein is provided on an 347 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 348 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 349 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 350 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 351 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 353 Acknowledgement 355 Funding for the RFC Editor function is currently provided by the 356 Internet Society.