idnits 2.17.1 draft-saintandre-xmpp-uri-00.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 (September 11, 2003) is 7526 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) == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-core-18 ** Obsolete normative reference: RFC 2396 (ref. '2') (Obsoleted by RFC 3986) == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-17 == Outdated reference: A later version (-04) exists of draft-ietf-impp-im-03 == Outdated reference: A later version (-04) exists of draft-ietf-impp-pres-03 ** Obsolete normative reference: RFC 2368 (ref. '6') (Obsoleted by RFC 6068) ** Obsolete normative reference: RFC 2717 (ref. '7') (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2718 (ref. '8') (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2234 (ref. '10') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2822 (ref. '11') (Obsoleted by RFC 5322) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 2 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: March 11, 2004 September 11, 2003 6 XMPP URI Format 7 draft-saintandre-xmpp-uri-00 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 March 11, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document defines a URI scheme to address entities that can 38 communicate via the Extensible Messaging and Presence Protocol 39 (XMPP). 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 45 1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 4 46 1.3 Intellectual Property Notice . . . . . . . . . . . . . . . . . 4 47 2. xmpp: URI IANA Registration . . . . . . . . . . . . . . . . . 5 48 2.1 URI Scheme Name . . . . . . . . . . . . . . . . . . . . . . . 5 49 2.2 URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . . 5 50 2.3 Character Encoding Considerations . . . . . . . . . . . . . . 5 51 2.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . . . 5 52 2.5 Security considerations . . . . . . . . . . . . . . . . . . . 5 53 2.6 Relevant publications . . . . . . . . . . . . . . . . . . . . 6 54 2.7 Person and email address to contact for further information . 6 55 2.8 Author/Change controller . . . . . . . . . . . . . . . . . . . 6 56 2.9 Applications and/or protocols which use this URI scheme 57 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 Normative References . . . . . . . . . . . . . . . . . . . . . 9 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 62 Intellectual Property and Copyright Statements . . . . . . . . 10 64 1. Introduction 66 The Extensible Messaging and Presence Protocol (XMPP) [1] has been 67 adapted by the XMPP WG from the open protocol originally developed by 68 the Jabber community. Currently there exist tens of thousands of 69 servers on the Jabber network, with millions of end users. The 70 addresses of XMPP entities are not specified as full URIs on the 71 network itself, i.e., within the context of the streaming XML 72 technology that forms the foundation of XMPP. However, many 73 applications external to the existing network would like to address 74 XMPP entities as full URIs in compliance with RFC 2396 [2]. 76 Many types of applications can be built using XMPP. The best-known 77 such application is instant messaging (IM) and presence as defined in 78 XMPP IM [3]. Therefore it might seem appropriate to use the 'im:' and 79 'pres:' URI schemes defined in Common Profile for Instant Messaging 80 (CPIM) [4] and Common Profile for Presence (CPP) [5], rather than to 81 define an XMPP-specific URI scheme. Unfortunately, these URI schemes 82 are limited to instant messaging (usually understood as exchanging 83 messages with a single other user) and presence. However, 84 fundamentally XMPP is a technology for near-real-time messaging, 85 presence, and request-response services using streaming XML, rather 86 than only an IM or presence technology. XMPP is already in use in 87 applications quite distinct from IM, including network management, 88 workflow applications, generic publish-subscribe, remote procedure 89 calls, content syndication, gaming, and middleware. These 90 applications require an addressing scheme that is not tied to the 91 particular semantics of the 'im:' and 'pres:' URI schemes. Therefore, 92 this document defines a generic URI scheme that will enable 93 applications to fully address any entity that can communicate via 94 XMPP. 96 On the XMPP network itself, entities must be addressed as 97 rather than . However, some interfaces to XMPP services may 98 be provided by non-native applications (e.g., web browsers), and 99 other applications may want to refer to XMPP entities using addresses 100 that are full URIs. The xmpp: URI format is provided for the sake of 101 such interfaces and applications, and MUST NOT be used by native 102 applications for addressing on the XMPP network itself. 104 An xmpp: URI is opaque rather than hierarchical, and thus is similar 105 to a mailto: URI as defined in RFC 2368 [6]. Because an xmpp: URI is 106 opaque, it SHOULD contain only the node identifier (optional) and 107 domain identifier (required) portions of a JID as defined in Section 108 3 of XMPP Core [1] (including by reference all relevant stringprep 109 profiles). An xmpp: URI MAY include the resource identifier portion 110 of a JID if the XMPP entity must be addressed as such, but this is 111 NOT RECOMMENDED since the delimiter used before a resource identifier 112 in XMPP addresses is the slash character ("/"), which is discouraged 113 by RFC 2396 [2] in opaque URIs. 115 If an xmpp: URI is presented in an interface to an XMPP service 116 (e.g., in a web browser), interacting with such a URI should trigger 117 the application to present a user with an appropriate interface to 118 complete an action such as sending a message, sending presence, 119 managing a subscription, sending an information request (IQ get), or 120 updating relevant information (IQ set). 122 This memo conforms to the requirements in Registration Procedures for 123 URL Scheme Names [7]. This memo also follows the recommendations in 124 Guidelines for new URL Schemes [8]. 126 1.1 Terminology 128 This document inherits terminology defined in XMPP Core [1]. 130 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 131 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in RFC 133 2119 [9]. 135 1.2 Discussion Venue 137 The author welcomes discussion and comments related to the topics 138 presented in this document. The preferred forum is the 139 mailing list, for which archives and subscription 140 information are available at . 143 1.3 Intellectual Property Notice 145 This document is in full compliance with all provisions of Section 10 146 of RFC 2026. Parts of this specification use the term "jabber" for 147 identifying namespaces and other protocol syntax. Jabber[tm] is a 148 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 149 to the IETF for use of the Jabber trademark in association with this 150 specification and its successors, if any. 152 2. xmpp: URI IANA Registration 154 This section provides the information required to register the xmpp: 155 URI scheme. 157 2.1 URI Scheme Name 159 xmpp 161 2.2 URI Scheme Syntax 163 The syntax for the xmpp: URI is defined below in Augmented 164 Backus-Naur Form as defined by RFC 2234 [10]. 166 XMPP-URI = "xmpp:" jid [ "/" resource] 167 jid = [ node "@" ] host 168 node = *( alphanum / escaped / 169 "-" / "_" / "." / "!" / "~" / "*" / "(" / ")" ) 170 host = hostname / IPv4address / IPv6reference 171 hostname = *( domainlabel "." ) toplabel [ "." ] 172 domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum 173 toplabel = alpha / alpha *( alphanum / "-" ) alphanum 174 IPv6reference = "[" IPv6address "]" 175 IPv6address = hexpart [ ":" IPv4address ] 176 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 177 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 178 hexseq = hex4 *( ":" hex4) 179 hex4 = 1*4HEXDIG 180 resource = *( unreserved / escaped ) 181 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / 182 "$" / "," / "[" / "]" 184 2.3 Character Encoding Considerations 186 Representation of non-ASCII character sets in local-part strings is 187 limited to the standard methods provided as extensions to RFC 2822 188 [11]. 190 2.4 Intended usage 192 The xmpp: URI is intended to be used by interfaces to the XMPP 193 network from non-native user agents such as web browsers, as well as 194 by non-XMPP applications in order to address XMPP entities as full 195 URIs. 197 2.5 Security considerations 198 See Security Considerations (Section 4) of this document. 200 2.6 Relevant publications 202 XMPP Core [1], XMPP IM [3] 204 2.7 Person and email address to contact for further information 206 Peter Saint-Andre [mailto:stpeter@jabber.org] 208 2.8 Author/Change controller 210 This scheme is registered under the IETF tree. As such, the IETF 211 maintains change control. 213 2.9 Applications and/or protocols which use this URI scheme name 215 Applications that provide an interface to XMPP services or that need 216 to address XMPP entities as full URIs. 218 3. IANA Considerations 220 This entire document addresses IANA considerations. 222 4. Security Considerations 224 Detailed security considerations for XMPP are given in XMPP Core [1]. 225 Providing an interface to XMPP services from non-native applications 226 introduces new security concerns. For example, the ability to 227 interact with XMPP entities via a web browser may expose sensitive 228 information to attacks that are not possible or unlikely on a native 229 XMPP network. Due care must be taken in deciding what information is 230 appropriate for representing in xmpp: URIs; in particular, passwords 231 MUST NOT be represented. 233 Normative References 235 [1] Saint-Andre, P. and J. Miller, "XMPP Core", 236 draft-ietf-xmpp-core-18 (work in progress), September 2003. 238 [2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 239 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 240 1998, . 242 [3] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging", 243 draft-ietf-xmpp-im-17 (work in progress), September 2003. 245 [4] Crocker, D. and J. Peterson, "Common Profile for Instant 246 Messaging (CPIM)", draft-ietf-impp-im-03 (work in progress), 247 May 2003. 249 [5] Crocker, D. and J. Peterson, "Common Profile for Presence 250 (CPP)", draft-ietf-impp-pres-03 (work in progress), May 2003. 252 [6] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL 253 scheme", RFC 2368, July 1998. 255 [7] Petke, R. and I. King, "Registration Procedures for URL Scheme 256 Names", BCP 35, RFC 2717, November 1999. 258 [8] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, 259 "Guidelines for new URL Schemes", RFC 2718, November 1999. 261 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 262 Levels", BCP 14, RFC 2119, March 1997. 264 [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax 265 Specifications: ABNF", RFC 2234, November 1997. 267 [11] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 269 Author's Address 271 Peter Saint-Andre 272 Jabber Software Foundation 274 EMail: stpeter@jabber.org 276 Intellectual Property Statement 278 The IETF takes no position regarding the validity or scope of any 279 intellectual property or other rights that might be claimed to 280 pertain to the implementation or use of the technology described in 281 this document or the extent to which any license under such rights 282 might or might not be available; neither does it represent that it 283 has made any effort to identify any such rights. Information on the 284 IETF's procedures with respect to rights in standards-track and 285 standards-related documentation can be found in BCP-11. Copies of 286 claims of rights made available for publication and any assurances of 287 licenses to be made available, or the result of an attempt made to 288 obtain a general license or permission for the use of such 289 proprietary rights by implementors or users of this specification can 290 be obtained from the IETF Secretariat. 292 The IETF invites any interested party to bring to its attention any 293 copyrights, patents or patent applications, or other proprietary 294 rights which may cover technology that may be required to practice 295 this standard. Please address the information to the IETF Executive 296 Director. 298 Full Copyright Statement 300 Copyright (C) The Internet Society (2003). All Rights Reserved. 302 This document and translations of it may be copied and furnished to 303 others, and derivative works that comment on or otherwise explain it 304 or assist in its implementation may be prepared, copied, published 305 and distributed, in whole or in part, without restriction of any 306 kind, provided that the above copyright notice and this paragraph are 307 included on all such copies and derivative works. However, this 308 document itself may not be modified in any way, such as by removing 309 the copyright notice or references to the Internet Society or other 310 Internet organizations, except as needed for the purpose of 311 developing Internet standards in which case the procedures for 312 copyrights defined in the Internet Standards process must be 313 followed, or as required to translate it into languages other than 314 English. 316 The limited permissions granted above are perpetual and will not be 317 revoked by the Internet Society or its successors or assignees. 319 This document and the information contained herein is provided on an 320 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 321 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 322 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 323 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 324 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 326 Acknowledgment 328 Funding for the RFC Editor function is currently provided by the 329 Internet Society.