idnits 2.17.1 draft-saintandre-xmpp-uri-03.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 == 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 (April 11, 2004) is 7320 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 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2822 (ref. 'IMF') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2718 (ref. 'URL-GUIDE') (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2717 (ref. 'URL-REG') (Obsoleted by RFC 4395) == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-core-22 == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-21 -- Obsolete informational reference (is this intentional?): RFC 2368 (ref. 'MAILTO') (Obsoleted by RFC 6068) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 3 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 Jabber Software Foundation 4 Expires: October 10, 2004 April 11, 2004 6 XMPP URI Format 7 draft-saintandre-xmpp-uri-03 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 October 10, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document defines a URI scheme for use in addressing entities 38 that can communicate via the Extensible Messaging and Presence 39 Protocol (XMPP). 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2.2 Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2.3 Query Component . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. xmpp: URI IANA Registration . . . . . . . . . . . . . . . . . 6 51 3.1 URI scheme name . . . . . . . . . . . . . . . . . . . . . . . 6 52 3.2 URI scheme syntax . . . . . . . . . . . . . . . . . . . . . . 6 53 3.3 Character encoding considerations . . . . . . . . . . . . . . 6 54 3.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.5 Security considerations . . . . . . . . . . . . . . . . . . . 6 56 3.6 Relevant publications . . . . . . . . . . . . . . . . . . . . 6 57 3.7 Person and email address to contact for further information . 6 58 3.8 Author/change controller . . . . . . . . . . . . . . . . . . . 7 59 3.9 Applications and/or protocols which use this URI scheme 60 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 Normative References . . . . . . . . . . . . . . . . . . . . . 7 64 Informative References . . . . . . . . . . . . . . . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 66 A. Revision History . . . . . . . . . . . . . . . . . . . . . . . 8 67 A.1 Changes from draft-saintandre-xmpp-uri-02 . . . . . . . . . . 8 68 A.2 Changes from draft-saintandre-xmpp-uri-01 . . . . . . . . . . 9 69 A.3 Changes from draft-saintandre-xmpp-uri-00 . . . . . . . . . . 9 70 Intellectual Property and Copyright Statements . . . . . . . . 10 72 1. Introduction 74 The Extensible Messaging and Presence Protocol (XMPP) [XMPP-CORE] 75 specifies that within the context of the streaming XML technology 76 that forms the foundation of XMPP, the addresses of XMPP entities are 77 not to be prepended with a URI scheme (as defined in RFC 2396 [URI]). 78 However, many applications external to the existing network would 79 like to address XMPP entities as full URIs; examples are databases 80 that need to store XMPP addresses as URIs and non-native user agents 81 (such as web browsers) that provide an interface to XMPP services. 82 This memo defines an xmpp: URI scheme for use by such applications, 83 and conforms to both the requirements in Registration Procedures for 84 URL Scheme Names [URL-REG] and the recommendations in Guidelines for 85 new URL Schemes [URL-GUIDE]. 87 1.1 Terminology 89 This document inherits terminology described in [XMPP-CORE]. 91 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 92 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in RFC 94 2119 [TERMS]. 96 1.2 Discussion Venue 98 The author welcomes discussion and comments related to the topics 99 presented in this document. The preferred forum is the 100 mailing list, for which archives and subscription 101 information are available at . 104 2. Narrative 106 2.1 Rationale 108 Many types of application can be built using XMPP. The best-known 109 such application is instant messaging (IM) and presence (as described 110 in [IMP-MODEL] and [IMP-REQS] and defined for XMPP in [XMPP-IM]). 111 Therefore it might seem appropriate to use the im: and pres: URI 112 schemes specified by Common Profile for Instant Messaging (CPIM) 113 [CPIM] and Common Profile for Presence (CPP) [CPP], rather than to 114 define an XMPP-specific URI scheme. However, while the im: and pres: 115 URI schemes are appropriate for instant messaging and presence 116 applications and are therefore mentioned normatively in [XMPP-IM], 117 they are not necessarily appropriate for all XMPP applications. 118 Because XMPP is fundamentally an XML streaming technology rather than 119 an instant messaging and presence technology per se, XMPP 120 applications may conform to [XMPP-CORE] but not [XMPP-IM] and thus 121 not implement instant messaging and presence semantics. Indeed, XMPP 122 is already used in applications such as network management, workflow 123 applications, generic publish-subscribe, remote procedure calls, 124 content syndication, gaming, and middleware. These applications 125 require an addressing scheme that is not tied to the particular 126 semantics of the im: and pres: URI schemes. Therefore, this document 127 defines a generic URI scheme that will enable applications to address 128 as a URI any entity that can communicate via XMPP. 130 Note well that on an XMPP network, entities are to be addressed as 131 <[node@]domain[/resource]> (i.e., without a URI scheme) rather than 132 as . The xmpp: URI format is provided 133 for the sake of non-native interfaces and applications only; native 134 applications are strongly encouraged not to prepend XMPP addresses 135 with the xmpp: URI scheme when addressing XML stanzas sent over an 136 XMPP network. 138 2.2 Form 140 The syntax for an xmpp: URI is as follows (where the jid rule is 141 defined in [XMPP-CORE]). 143 "xmpp:" jid [ "?" query ] 145 An xmpp: URI is opaque rather than hierarchical, and thus is similar 146 to a mailto: URI as specified in RFC 2368 [MAILTO]. Because an xmpp: 147 URI is opaque, the JID contained therein SHOULD include only a node 148 identifier (OPTIONAL) and domain identifier (REQUIRED) as defined in 149 [XMPP-CORE]. An xmpp: URI MAY include the resource identifier 150 portion of a JID if the XMPP entity must be addressed as such, but 151 this is not recommended since the delimiter used before a resource 152 identifier in XMPP addresses is the slash character ("/"), which is 153 discouraged by [URI] in opaque URIs. 155 2.3 Query Component 157 If an xmpp: URI is presented in an end-user application that provides 158 a non-native interface to an XMPP service (e.g., a web browser), 159 interacting with such a URI SHOULD trigger the application to present 160 a user with an appropriate interface to complete an action such as 161 sending a message or sending presence. In order to specify the 162 possible actions, two "header" values of the query component are 163 defined: "presence" and "message". Usage is described below. 165 2.3.1 Messages 167 In order to invoke an interface for sending a message, the URI SHOULD 168 be of the form . 170 The query component MAY include parameters that further specify the 171 message to be sent to the intended recipient. The following 172 parameters are OPTIONAL for messages, corresponding to the , 173 , and children of the XML stanza as 174 defined in [XMPP-IM]: 176 o body (the natural-language contents of the message) 178 o subject (the topic of the message) 180 o thread (for grouping of multiple messages into a common thread) 182 The following example illustrates the use of these parameters: 184 Sending a message 186 xmpp:user@host?message&subject=hi&body=Hello%20World&thread=abc123 188 2.3.2 Presence 190 In order to invoke an interface for sending presence information, the 191 URI SHOULD be of the form . The intended 192 scope is the sending of presence notifications about the availability 193 of the sender, not the management of presence subscriptions (for the 194 semantic and syntactic differences between presence notifications and 195 presence subscriptions, see [XMPP-IM]). 197 The query component MAY include parameters that further specify the 198 presence information to be sent to the intended recipient. The 199 following parameters are OPTIONAL for presence, corresponding to the 200 'type' attribute and the , , and children 201 of the stanza as defined in [XMPP-IM]: 203 o type (the only allowable value for presence notifications is 204 "unavailable"; if the type is not specified, the sender is defined 205 to be available) 207 o show (one of "away", "xa", "dnd", or "chat") 209 o status (a user-defined status message) 211 o priority (an integer specifying the rough likelihood of receiving 212 messages at this resource) 214 The following example illustrates the use of these parameters: 216 Sending Presence Information 218 xmpp:user@host?presence&show=dnd&status=taking%20a%20nap 220 3. xmpp: URI IANA Registration 222 This section provides the information required to register the xmpp: 223 URI scheme. 225 3.1 URI scheme name 227 xmpp 229 3.2 URI scheme syntax 231 The syntax for an xmpp: URI is defined below using Augmented 232 Backus-Naur Form as specified by [ABNF]. The jid rule is defined in 233 [XMPP-CORE]. 235 XMPP-URI = "xmpp:" jid [ "?" query ] 237 3.3 Character encoding considerations 239 Representation of non-ASCII character sets in local-part strings is 240 limited to the standard methods provided as extensions to RFC 2822 241 [IMF]. Specifically, for each byte, if the byte is not in the set 242 A-Za-z0-9!$*.?_~+= then transform the byte to %hexhex as described in 243 Section 2.2.5 of [URL-GUIDE]. 245 3.4 Intended usage 247 The xmpp: URI is intended to be used by interfaces to an XMPP network 248 from non-native user agents such as web browsers, as well as by 249 non-native applications that need to address XMPP entities as full 250 URIs. 252 3.5 Security considerations 254 See Security Considerations (Section 5) of this document. 256 3.6 Relevant publications 258 [XMPP-CORE] 260 3.7 Person and email address to contact for further information 261 Peter Saint-Andre [mailto:stpeter@jabber.org] 263 3.8 Author/change controller 265 This scheme is registered under the IETF tree. As such, the IETF 266 maintains change control. 268 3.9 Applications and/or protocols which use this URI scheme name 270 Applications (other than native native XMPP applications) that 271 provide an interface to XMPP services or that need to address XMPP 272 entities as full URIs. 274 4. IANA Considerations 276 This entire document addresses IANA considerations. 278 5. Security Considerations 280 Detailed security considerations for XMPP are given in [XMPP-CORE]. 281 Providing an interface to XMPP services from non-native applications 282 introduces new security concerns. For example, the ability to 283 interact with XMPP entities via a web browser may expose sensitive 284 information to attacks that are not possible or that are unlikely on 285 a native XMPP network. Due care must be taken in deciding what 286 information is appropriate for representing in xmpp: URIs; in 287 particular, passwords MUST NOT be represented. 289 Normative References 291 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 292 Specifications: ABNF", RFC 2234, November 1997. 294 [IMF] Resnick, P., "Internet Message Format", RFC 2822, April 295 2001. 297 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 301 Resource Identifiers (URI): Generic Syntax", RFC 2396, 302 August 1998, . 304 [URL-GUIDE] 305 Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, 306 "Guidelines for new URL Schemes", RFC 2718, November 1999. 308 [URL-REG] Petke, R. and I. King, "Registration Procedures for URL 309 Scheme Names", BCP 35, RFC 2717, November 1999. 311 [XMPP-CORE] 312 Saint-Andre, P., "Extensible Messaging and Presence 313 Protocol (XMPP): Core", draft-ietf-xmpp-core-22 (work in 314 progress), January 2004. 316 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 317 Protocol (XMPP): Instant Messaging and Presence", 318 draft-ietf-xmpp-im-21 (work in progress), January 2004. 320 Informative References 322 [CPIM] Peterson, J., "Common Profile for Instant Messaging 323 (CPIM)", draft-ietf-impp-im-04 (work in progress), August 324 2003. 326 [CPP] Peterson, J., "Common Profile for Presence (CPP)", 327 draft-ietf-impp-pres-04 (work in progress), August 2003. 329 [IMP-MODEL] 330 Day, M., Rosenberg, J. and H. Sugano, "A Model for 331 Presence and Instant Messaging", RFC 2778, February 2000. 333 [IMP-REQS] 334 Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 335 Presence Protocol Requirements", RFC 2779, February 2000. 337 [MAILTO] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL 338 scheme", RFC 2368, July 1998. 340 Author's Address 342 Peter Saint-Andre 343 Jabber Software Foundation 345 EMail: stpeter@jabber.org 347 Appendix A. Revision History 349 Note to RFC Editor: please remove this entire appendix, and the 350 corresponding entries in the table of contents, prior to publication. 352 A.1 Changes from draft-saintandre-xmpp-uri-02 354 o Corrected several small textual errors. 356 o Clarified the scope of allowable presence information. 358 A.2 Changes from draft-saintandre-xmpp-uri-01 360 o Clarified guidelines for escaping of UTF-8 characters. 362 o Specified usage of query component. 364 A.3 Changes from draft-saintandre-xmpp-uri-00 366 o Modified ABNF to track changes to XMPP Core. 368 o Clarified a few matters in the text. 370 Intellectual Property Statement 372 The IETF takes no position regarding the validity or scope of any 373 intellectual property or other rights that might be claimed to 374 pertain to the implementation or use of the technology described in 375 this document or the extent to which any license under such rights 376 might or might not be available; neither does it represent that it 377 has made any effort to identify any such rights. Information on the 378 IETF's procedures with respect to rights in standards-track and 379 standards-related documentation can be found in BCP-11. Copies of 380 claims of rights made available for publication and any assurances of 381 licenses to be made available, or the result of an attempt made to 382 obtain a general license or permission for the use of such 383 proprietary rights by implementors or users of this specification can 384 be obtained from the IETF Secretariat. 386 The IETF invites any interested party to bring to its attention any 387 copyrights, patents or patent applications, or other proprietary 388 rights which may cover technology that may be required to practice 389 this standard. Please address the information to the IETF Executive 390 Director. 392 Full Copyright Statement 394 Copyright (C) The Internet Society (2004). All Rights Reserved. 396 This document and translations of it may be copied and furnished to 397 others, and derivative works that comment on or otherwise explain it 398 or assist in its implementation may be prepared, copied, published 399 and distributed, in whole or in part, without restriction of any 400 kind, provided that the above copyright notice and this paragraph are 401 included on all such copies and derivative works. However, this 402 document itself may not be modified in any way, such as by removing 403 the copyright notice or references to the Internet Society or other 404 Internet organizations, except as needed for the purpose of 405 developing Internet standards in which case the procedures for 406 copyrights defined in the Internet Standards process must be 407 followed, or as required to translate it into languages other than 408 English. 410 The limited permissions granted above are perpetual and will not be 411 revoked by the Internet Society or its successors or assignees. 413 This document and the information contained herein is provided on an 414 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 415 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 416 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 417 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 418 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 420 Acknowledgment 422 Funding for the RFC Editor function is currently provided by the 423 Internet Society.