<abstract>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.</abstract>
<remark>Retracted the proposal (again) in favor of draft-saintandre-xmpp-iri.</remark>
</revision>
<revision>
<version>0.4</version>
<date>2005-01-05</date>
<initials>psa</initials>
<remark>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.</remark>
</revision>
<revision>
<version>0.3</version>
<date>2004-07-26</date>
<initials>psa</initials>
<remark>Formally retracted this proposal in favor of the relevant Internet-Drafts.</remark>
<p>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>.</p>
<p>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
<note>See, for instance, <<linkurl='http://www.mozilla.org/docs/web-developer/mimetypes.html'>http://www.mozilla.org/docs/web-developer/mimetypes.html</link>> for information about MIME support in the Mozilla family of web browsers.</note>
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.</p>
<p>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.</p>
<p>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.</p>
</section1>
<section1topic='Use Cases'anchor='usecases'>
<p>The solution MUST enable a user to complete the following use cases, support for which is REQUIRED:</p>
<ul>
<li>Send a single message to another user.</li>
<li>Initiate a one-to-one chat session with another user.</li>
<li>Subscribe to another user's presence.</li>
</ul>
<p>In addition, the solution SHOULD enable a user to complete the following use cases, support for which is RECOMMENDED:</p>
<p>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.</p>
<p>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 <cite>XMPP IM</cite>, first authenticating with the user's Jabber/XMPP server if necessary.</p>
</section2>
<section2topic='Subscribing to Presence'anchor='subscribe'>
<p>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 <cite>XMPP IM</cite>, 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 <cite>XMPP IM</cite>.</p>
</section2>
<section2topic='Joining a Groupchat Room'anchor='groupchat'>
<p>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.</p>
<p>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 <cite>XEP-0077</cite>.</p>
<p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for sending a service discovery request to the JID defined in the file.</p>
</section2>
<section2topic='Searching a Directory'anchor='search'>
<p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for searching the directory associated with the JID defined in the file, including pre-populated information as specified (e.g., nick, first name, last name).</p>
</section2>
<section2topic='Requesting a vCard'anchor='vcard'>
<p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for requesting the vCard of the JID defined in the file.</p>
</section2>
-->
</section1>
<!--
<section1topic='Authentication'anchor='auth'>
<p>The solution should also enable a user to authenticate with a server using parameters defined in the file, e.g., for the purpose of single-sign-on (SSO).</p>
<p>The username, password, and resource are not required if there is some other extension inside authenticate, that, e.g. does SSO. Authenticate is mostly useful only for these SSO situations, anyway. If the user is already connected, the application SHOULD ignore the <connect/> block.</p>
<p>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 <cite>RFC 3920</cite> (Sections 12.1 through 12.6). In addition, all of the security considerations specified in <cite>RFC 3023</cite> apply to the "application/jabber+xml" media type.</p>
<p>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.</p>