The value of a URI scheme (see &rfc3986;) for Jabber/XMPP communications has long been recognized within the Jabber community, and such a scheme has been formally defined in &rfc5122; as a way of identifying entities that adhere to &xmppcore; or its antecedents. Unfortunately, URI schemes are slow to be accepted on the Internet, such that it might be years (if ever) before widely deployed software such as web browsers will support addresses of the form <xmpp:user@domain>.

Thankfully, it is not necessary for the large existing base of deployed software to support the xmpp: URI scheme in order to integrate Jabber/XMPP support. A well-accepted alternative approach See, for instance, <http://www.mozilla.org/docs/web-developer/mimetypes.html> for information about MIME support in the Mozilla family of web browsers. is to define a MIME type (in accordance with &rfc2045;) and then reconfigure the relevant server and client software to correctly handle the new MIME type.

Therefore, this document defines a MIME type of "application/jabber+xml" (in particular, an XML media type in accordance with &rfc3023;). Files of this MIME type would commonly be accessed with a web browser via HTTP, although other access methods are possible (e.g., attachment of the MIME type to an email message). On opening a file of this type, a browser would (by configuration) invoke an appropriate "helper" application (i.e., an external Jabber client, plugin, or internal module) that would enable the user to interact with a Jabber/XMPP server. If the user is not currently connected to a server, the invoked program would be responsible for connecting the user with appropriate prompting for authentication credentials. The file passed to the helper application would define parameters needed to complete a certain use case, such as sending a message to another user.

Note: The "application/jabber+xml" MIME type defined herein is not to be confused with the "application/xmpp+xml" MIME type defined in &rfc3923;; the two MIME types address different requirements and do not overlap or conflict.

The solution MUST enable a user to complete the following use cases, support for which is REQUIRED:

• Send a single message to another user.
• Initiate a one-to-one chat session with another user.
• Subscribe to another user's presence.

In addition, the solution SHOULD enable a user to complete the following use cases, support for which is RECOMMENDED:

• Join a groupchat room.
• Register with a service.

These use cases are defined below.

Detailed security considerations for instant messaging and presence protocols are given in &rfc2779; (Sections 5.1 through 5.4), and for XMPP in particular are given in RFC 3920 (Sections 12.1 through 12.6). In addition, all of the security considerations specified in RFC 3023 apply to the "application/jabber+xml" media type.

When a helper application has finished processing a file of type "application/jabber+xml", it SHOULD discard the file; this helps to prevent security-related problems that may result from HTTP caching.

This document requires registration of the "application/jabber+xml" content type with &IANA;. The registration is as follows:

1. Add implementation notes for server MIME type registration and HTTP Content-Type output.
2. Add implementation notes for client handling on various platforms (e.g., DDE messages in Windows).