Note: This proposal has been superseded by the MIME type defined in draft-ietf-xmpp-e2e and the URI scheme defined in draft-saintandre-ietf-xmpp-uri; please refer to those documents for the successor protocols.
WARNING: This JEP has been retracted by the author(s). Implementation of the protocol described herein is not recommended. Developers desiring similar functionality should implement the protocol that supersedes this one (if any).
Status: Retracted
Type: Standards Track
Number: 0081
Version: 0.3
Last Updated: 2004-07-26
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name: N/A
Email: jhildebrand@jabber.com
JID: hildjj@jabber.org
Email: stpeter@jabber.org
JID: stpeter@jabber.org
This Jabber Enhancement Proposal is copyright 1999 - 2004 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.php>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
Given that this JEP normatively references IETF technologies, discussion on the JSF-IETF list may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/jsf-ietf> for details).
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core and XMPP IM specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocols defined in this JEP have been developed outside the Internet Standards Process and are to be understood as extensions to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Note: This JEP has been superseded by the MIME type defined in XMPP E2E [1] and the URI scheme defined in XMPP URI [2]; please refer to those documents for the successor protocols.
The potential value of a URI scheme (see RFC 2396 [3]) for XMPP/Jabber has long been recognized within the Jabber community. The traditional consensus was captured in Jabber URI Scheme [4]. 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 would support addresses of the form <xmpp:user@domain>.
Thankfully, it is not necessary to define a URI scheme in order to integrate XMPP/Jabber support into the large existing base of deployed software. A well-accepted alternative approach is to define a MIME type (in accordance with RFC 2045 [5]) and then reconfigure the relevant server and client software to correctly handle the new MIME type. The latter approach is the one taken in the current proposal.
A MIME type of "application/xmpp+xml" is defined (in accordance with RFC 3023 [6]). Files of this MIME type would commonly be accessed with a web browser via HTTP, although other access methods are possible. On opening a file of this type, a browser would (by configuration) invoke an appropriate external software program (i.e., a Jabber client, or potentially an internal module) that would enable the user's interaction with an XMPP/Jabber 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 Jabber client would define parameters needed to complete a certain use case, such as starting a chat session with another user.
The solution must enable a user to complete the following use cases:
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:
<?xml version='1.0' encoding='UTF-8'?>
<jabber>
<message jid='stpeter@jabber.org'/>
</jabber>
The browser passes this file to the helper application, which instantiates an appropriate interface for sending a message to the JID defined in the file.
<?xml version='1.0' encoding='UTF-8'?>
<jabber>
<chat jid='stpeter@jabber.org'/>
</jabber>
The browser passes this file to the helper application, which instantiates an appropriate interface for chatting with the JID defined in the file.
<?xml version='1.0' encoding='UTF-8'?>
<jabber>
<groupchat jid='jdev@conference.jabber.org'/>
</jabber>
The browser passes this file to the helper application, which instantiates an appropriate interface for joining the conference room associated with the JID defined in the file.
<?xml version='1.0' encoding='UTF-8'?>
<jabber>
<subscribe jid='stpeter@jabber.org'/>
</jabber>
The browser passes this file to the helper application, which instantiates an appropriate interface for subscribing to the presence of the JID defined in the file.
<?xml version='1.0' encoding='UTF-8'?>
<jabber>
<vcard jid='stpeter@jabber.org'/>
</jabber>
The browser passes this file to the helper application, which instantiates an appropriate interface for requesting the vCard of the JID defined in the file.
<?xml version='1.0' encoding='UTF-8'?>
<jabber>
<register jid='headlines.shakespeare.lit'/>
</jabber>
The browser passes this file to the helper application, which instantiates an appropriate interface for registering with the service associated with the JID defined in the file.
<?xml version='1.0' encoding='UTF-8'?>
<jabber>
<search jid='users.jabber.org'>
<nick>stpeter</nick>
</search>
</jabber>
The browser passes this file to the helper application, which instantiates 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).
<?xml version='1.0' encoding='UTF-8'?>
<jabber>
<disco jid='shakespeare.lit'>
<items/>
<info/>
</disco>
</jabber>
The browser passes this file to the helper application, which instantiates an appropriate interface for sending a service discovery request to the JID defined in the file.
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).
<connect>
<host>somehost</host>
<ip>10.1.1.1</ip>
<port>5222</port>
<ssl/>
<authenticate>
<username>foo</username>
<password>test</password>
<resource>Work</resource>
</authenticate>
</connect>
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.
The receiver SHOULD delete the XMPP file when done with it. This will help prevent certain HTTP caching problems.
This JEP requires registration of the "application/xmpp+xml" MIME type with the Internet Assigned Numbers Authority (IANA) [8]. Details to follow.
No namespaces or parameters need to be registered with the Jabber Registrar [9] as a result of this JEP.
To follow.
1. RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) <http://www.ietf.org/rfc/rfc3923.txt>.
2. XMPP URI Format <http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-uri-05.txt> (work in progress).
3. RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax <http://www.ietf.org/rfc/rfc2396.txt>.
4. JEP-0032: Jabber URI Scheme <http://www.jabber.org/jeps/jep-0032.html>.
5. RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies <http://www.ietf.org/rfc/rfc2045.txt>.
6. RFC 3023: XML Media Types <http://www.ietf.org/rfc/rfc3023.txt>.
7. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
8. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
9. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
END