%ents; ]>
Jabber MIME Type This document specifies a MIME type for launching a Jabber client as a helper application from most modern web browsers, and for completing basic use cases once the client is launched. &LEGALNOTICE; 0081 Retracted Standards Track Standards JIG XMPP Core XMPP IM RFC 2045 RFC 3023 XEP-0045 XEP-0077 None None mimetype &hildjj; &stpeter; 0.5 2005-07-19 psa Retracted the proposal (again) in favor of draft-saintandre-xmpp-iri. 0.4 2005-01-05 psa Reinstated the proposal since it fills a need not met by RFC 3923 and draft-saintandre-xmpp-uri; specified XML schema; specified IANA considerations, including content-type registration; further specified security considerations; removed use cases for service discovery, directory search, vCard lookup, and authentication; added more detailed descriptive text to remaining use cases. 0.3 2004-07-26 psa Formally retracted this proposal in favor of the relevant Internet-Drafts. 0.2 2003-08-18 psa Added authentication example. 0.1 2003-04-21 psa Initial version.

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 &rfc4622; 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:

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

These use cases are defined below.

In order to send a message to a contact, the user opens an XMPP file of the following form:

]]>

The browser passes this file to the helper application, which shall instantiate an appropriate interface for sending a single message to the JID defined in the file. If the user completes the interface, the helper application shall then send a message stanza of type='normal' as specified in &xmppim;, first authenticating with the user's Jabber/XMPP server if necessary.

]]>

The browser passes this file to the helper application, which shall instantiate an appropriate interface for chatting with the JID defined in the file. If the user completes the interface, the helper application shall then send a message stanza of type='chat' as specified in XMPP IM, first authenticating with the user's Jabber/XMPP server if necessary.

]]>

The browser passes this file to the helper application, which shall instantiate an appropriate interface for sending a presence subscription request to the JID defined in the file (e.g., specifying a name and/or group for the contact). If the user completes the interface, the helper application shall then send a presence stanza of type='subscribe' as specified in XMPP IM, first authenticating with the user's Jabber/XMPP server if necessary. The helper application SHOULD perform a "roster set" before sending the presence subscription request, as described in XMPP IM.

]]>

The browser passes this file to the helper application, which shall instantiate an appropriate interface for joining the conference room associated with the JID defined in the file. If the user completes the interface, the helper application shall then send a directed presence stanza to the JID (appending a room nickname to the JID as the resource identifier) as described in &xep0045;, first authenticating with the user's Jabber/XMPP server if necessary.

]]>

The browser passes this file to the helper application, which shall send an IQ stanza of type='get' to the service associated with the JID defined in the file in order to determine the registration requirements (first authenticating with the user's Jabber/XMPP server if necessary), as described in &xep0077;. The helper application shall then instantiate an appropriate interface for registering with the service. If the user completes the interface, the helper application shall then send an IQ stanza of type='set' to the JID as described in XEP-0077.

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:

Intended usage: COMMON Author/Change controller: JSF, XMPP Registrar ]]>

The ®ISTRAR; shall include 'http://jabber.org/protocol/mimetype' in its registry of protocol namespaces.

The XMPP Registrar shall interact with the IANA in order to register the media type defined herein.

]]>
  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).