idnits 2.17.1 draft-saintandre-xmpp-urn-03.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 360. 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 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 (February 23, 2007) is 6272 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 3406 (ref. 'MECHANISMS') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2141 (ref. 'URN') (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP-CORE') (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. 'XMPP-IM') (Obsoleted by RFC 6121) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft XSF 4 Expires: August 27, 2007 February 23, 2007 6 A Uniform Resource Name (URN) Namespace for Extensions to the Extensible 7 Messaging and Presence Protocol (XMPP) 8 draft-saintandre-xmpp-urn-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 27, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes a Uniform Resource Name (URN) namespace for 42 uniquely identifying Extensible Markup Language (XML) formats and 43 protocols that provide extensions to the Extensible Messaging and 44 Presence Protocol (XMPP) and are defined in specifications published 45 by the XMPP Standards Foundation (XSF). 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Specification Template . . . . . . . . . . . . . . . . . . . . 3 51 3. Namespace Considerations . . . . . . . . . . . . . . . . . . . 6 52 4. Community Considerations . . . . . . . . . . . . . . . . . . . 6 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 57 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 Intellectual Property and Copyright Statements . . . . . . . . . . 9 61 1. Introduction 63 While the Extensible Messaging and Presence Protocol (XMPP) as 64 specified in [XMPP-CORE] and [XMPP-IM] provides basic messaging and 65 presence functionality, the fact that XMPP is at root a technology 66 for streaming Extensible Markup Language [XML] data makes it possible 67 to include virtually any structured information within XMPP, as long 68 as such information is qualified by appropriate XML namespaces 69 [XML-NAMES]. When sent over XMPP, such structured data formats and 70 protocols are generally referred to as "XMPP extensions". 72 A large number of such XMPP extensions exist. The main standards 73 development organization in which such extensions are defined is the 74 XMPP Standards Foundation (XSF) (formerly the Jabber Software 75 Foundation), which contributed XMPP to the Internet Standards 76 Process. Typically, such extensions are defined within the XSF's 77 XMPP Extension Protocol (XEP) specification series. To date, the XML 78 namespaces defined within the Jabber/XMPP community have used names 79 of the form "jabber:*" (deprecated since early 2002) and 80 "http://jabber.org/protocol/*" (not including names of the form 81 "urn:ietf:params:xml:ns:xmpp-*" specified in the XMPP RFCs). 82 However, it is desirable that names associated with future XMPP 83 extensions be both unique and persistent, which is not necessarily 84 the case with names that are also HTTP URLs. Therefore, in 85 accordance with the process defined in [MECHANISMS], this document 86 registers a formal namespace identifier (NID) for Uniform Resource 87 Names [URN] associated with XMPP extensions published in the XSF's 88 XEP series and for XML namespaces registered with the XSF's XMPP 89 Registrar function [REGISTRAR]. 91 2. Specification Template 93 Namespace ID: 95 The Namespace ID "xmpp" is requested. 97 Registration Information: 99 Version 1 100 Date: 102 Declared Registrant of the Namespace: 104 Registering organization 105 Organization: XMPP Standards Foundation 106 Address: P.O. Box 1641, Denver, CO 80201 USA 108 Designated contact 109 Role: XMPP Registrar 110 Email: registrar@xmpp.org 112 Declaration of Syntactic Structure: 114 The Namespace Specific String (NSS) of all URNs that use the 115 "xmpp" NID shall have the following structure: 117 urn:xmpp:{ShortName}:{SubName} 119 The keywords have the following meaning: 121 (1) the "ShortName" is a required US-ASCII string that 122 conforms to the URN syntax requirements (see RFC 2141) 123 and defines a particular protocol or format that is used 124 as an XMPP extension. 126 (2) the "SubName" is an optional US-ASCII string that 127 conforms to the URN syntax requirements (see RFC 2141) 128 and defines a particular subset of the relevant protocol 129 or format. 131 The XSF's XMPP Registrar function shall be responsible for 132 managing the assignment of both "ShortName" and "SubName" 133 strings and for maintaining a registry of resulting namespaces 134 at . The 135 XMPP Registrar may also assign URNs in sub-trees below the 136 level of the ShortName or SubName as needed for use in various 137 XMPP extensions. 139 Relevant Ancillary Documentation: 141 Information about the XSF's XMPP Registrar function can be 142 found at 143 and . 145 Identifier Uniqueness Considerations: 147 The XMPP Registrar is already responsible for managing 148 the assignment of XML namespace names of the form 149 "http://jabber.org/protocol/{ShortName}" and 150 "http://jabber.org/protocol/{ShortName}#{SubName}" 151 (e.g., "http://jabber.org/protocol/pubsub" and 152 "http://jabber.org/protocol/disco#info"). In order to 153 assign namespace names in the context of the "xmpp" 154 NID, the XMPP Registrar shall simply modify the syntax 155 of the namespace names it assigns from 156 "http://jabber.org/protocol/{ShortName}" and 157 "http://jabber.org/protocol/{ShortName}#{SubName}" to 158 "urn:xmpp:{ShortName}" and "urn:xmpp:{ShortName}:{SubName}". 160 The XMPP Registrar shall ensure the uniqueness of all 161 XMPP URNs by checking such names against the list of 162 existing namespace names, as documented in XEP-0053 163 (the controlling specification for the XMPP Registrar 164 function). The XMPP Registrar shall in all cases directly 165 ensure the uniqueness of the assigned strings and shall 166 not assign secondary responsibility for management of any 167 sub-trees. However, the XMPP Registrar may assign URNs 168 in sub-trees below the level of the ShortName or SubName 169 as needed for use in various XMPP extensions. The 170 resulting URNs shall not be re-assigned. 172 Identifier Persistence Considerations: 174 The XMPP Registrar shall provide clear documentation of 175 the registered uses of the "xmpp" NID in the form of 176 XMPP Extension Protocol (XEP) specifications published 177 at , as well as a 178 registry of the namespace names themselves at 179 . 181 Process of Identifier Assignment: 183 The XMPP Registrar's processes and procedures for 184 identifier assignment are documented in XEP-0053, 185 which is the controlling specification for the XMPP 186 Registrar function. In particular, identifiers shall 187 be issued only upon advancement of the relevant protocol 188 specification to a status of Draft within the standards 189 process followed by the XMPP Standards Foundation (as 190 specified in XEP-0001). The XMPP Registrar shall check 191 all identifiers against the list of existing namespace 192 names to ensure uniqueness and to encourage relevance 193 and memorability. Assignment of URNs within the "xmpp" 194 tree is reserved to the XMPP Standards Foundation, 195 specifically to its XMPP Registrar function. 197 Process for Identifier Resolution: 199 The namespace is not currently listed with a Resolution 200 Discovery System (RDS), but nothing about the namespace 201 prohibits the future definition of appropriate resolution 202 methods or listing with an RDS. 204 Rules for Lexical Equivalence: 206 No special considerations; the rules for lexical 207 equivalence specified in RFC 2141 apply. 209 Conformance with URN Syntax: 211 No special considerations. 213 Validation Mechanism: 215 None specified. 217 Scope: 219 Global. 221 3. Namespace Considerations 223 The XMPP Standards Foundation has been developing Internet protocols 224 since August 2001 and that work is expected to continue for the 225 foreseeable future. The old-style "jabber:*" namespace names 226 originally used in the Jabber open-source community were not proper 227 URNs or URIs and thus were deprecated in early 2002. Since then, the 228 namespace names assigned by the XMPP Registrar function of the XMPP 229 Standards Foundation have been (equivalent to) specialized HTTP URLs 230 whose authority component is "jabber.org". While that domain is 231 currently under the control of the XMPP Standards Foundation, there 232 is no guarantee that it will always remain so, thus potentially 233 threatening the reliability and permanence of the assigned namespace 234 names. The use of Uniform Resource Names with an appropriate 235 Namespace ID will enable the XMPP Standards Foundation to assign 236 cleaner, more general, more permanent, more reliable, and more 237 controllable namespace names related to the XMPP extensions it 238 defines, while keeping the tree of XMPP extensions produced by the 239 XMPP Standards Foundation properly separate from the IETF tree used 240 to define some of the core XMPP namespaces as well as namespaces 241 related to XMPP extensions that may be produced in the future by the 242 IETF. 244 4. Community Considerations 246 The XMPP standards development community will benefit from 247 publication of this namespace by having more permanent and reliable 248 names for the XML namespaces defined in XMPP Extension Protocol 249 specifications produced by the XMPP Standards Foundation. 251 The standards process followed by the XSF is open to contributions 252 from any interested individual; such a contribution takes the form of 253 a proposal submitted to the XMPP Extensions Editor 254 , accepted by the XMPP Council 255 , and published in the XSF's XMPP 256 Extension Protocol (XEP) series at . 257 Use of the proposed space for a particular XML format or protocol 258 extension will be contingent upon advancement of the appropriate 259 specification within the XSF's standards process (as documented in 260 [XEP]) and issuance of a namespace name within the "xmpp" tree by the 261 XMPP Registrar (as documented in [REGISTRAR]). 263 5. Security Considerations 265 This document introduces no additional security considerations beyond 266 those associated with the use and resolution of URNs in general. 268 6. IANA Considerations 270 This document defines a URN NID registration of "xmpp", which shall 271 be entered into the IANA registry located at 272 . 274 7. References 276 7.1. Normative References 278 [MECHANISMS] 279 Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 280 "Uniform Resource Names (URN) Namespace Definition 281 Mechanisms", BCP 66, RFC 3406, October 2002. 283 [URN] Moats, R., "URN Syntax", RFC 2141, May 1997. 285 7.2. Informative References 287 [REGISTRAR] 288 Saint-Andre, P., "XMPP Registrar Function", XSF XEP 0053, 289 December 2006. 291 [XEP] Saint-Andre, P., "XMPP Extension Protocols", XSF XEP 0001, 292 December 2006. 294 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 295 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC- 296 xml, October 2000, . 298 [XML-NAMES] 299 Bray, T., Hollander, D., and A. Layman, "Namespaces in 300 XML", W3C REC-xml-names, January 1999, 301 . 303 [XMPP-CORE] 304 Saint-Andre, P., "Extensible Messaging and Presence 305 Protocol (XMPP): Core", RFC 3920, October 2004. 307 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 308 Protocol (XMPP): Instant Messaging and Presence", 309 RFC 3921, October 2004. 311 Author's Address 313 Peter Saint-Andre 314 XMPP Standards Foundation 315 P.O. Box 1641 316 Denver, CO 80201 317 USA 319 Email: stpeter@jabber.org 320 URI: xmpp:stpeter@jabber.org 322 Full Copyright Statement 324 Copyright (C) The IETF Trust (2007). 326 This document is subject to the rights, licenses and restrictions 327 contained in BCP 78, and except as set forth therein, the authors 328 retain all their rights. 330 This document and the information contained herein are provided on an 331 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 332 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 333 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 334 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 335 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 336 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 338 Intellectual Property 340 The IETF takes no position regarding the validity or scope of any 341 Intellectual Property Rights or other rights that might be claimed to 342 pertain to the implementation or use of the technology described in 343 this document or the extent to which any license under such rights 344 might or might not be available; nor does it represent that it has 345 made any independent effort to identify any such rights. Information 346 on the procedures with respect to rights in RFC documents can be 347 found in BCP 78 and BCP 79. 349 Copies of IPR disclosures made to the IETF Secretariat and any 350 assurances of licenses to be made available, or the result of an 351 attempt made to obtain a general license or permission for the use of 352 such proprietary rights by implementers or users of this 353 specification can be obtained from the IETF on-line IPR repository at 354 http://www.ietf.org/ipr. 356 The IETF invites any interested party to bring to its attention any 357 copyrights, patents or patent applications, or other proprietary 358 rights that may cover technology that may be required to implement 359 this standard. Please address the information to the IETF at 360 ietf-ipr@ietf.org. 362 Acknowledgment 364 Funding for the RFC Editor function is provided by the IETF 365 Administrative Support Activity (IASA).