JEP-0081: XMPP/Jabber MIME Type

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


JEP Information

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

Author Information

Joe Hildebrand

Email: jhildebrand@jabber.com
JID: hildjj@jabber.org

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

Legal Notice

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

Discussion Venue

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

Relation to XMPP

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.

Conformance Terms

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.


Table of Contents

1. Introduction
2. Overview
3. Use Cases
3.1. Sending a Message
3.2. Starting a Chat
3.3. Joining a Groupchat Room
3.4. Subscribing to Presence
3.5. Requesting a vCard
3.6. Registering with a Service
3.7. Searching a Directory
3.8. Making a Service Discovery Request
4. Authentication
5. Security Considerations
6. IANA Considerations
7. Jabber Registrar Considerations
8. XML Schema
9. Open Issues
Notes
Revision History


1. Introduction

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.

2. Overview

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.

3. Use Cases

The solution must enable a user to complete the following use cases:

These use cases are defined below.

3.1 Sending a Message

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.

3.2 Starting a Chat

<?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.

3.3 Joining a Groupchat Room

<?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.

3.4 Subscribing to Presence

<?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.

3.5 Requesting a vCard

<?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.

3.6 Registering with a Service

<?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.

3.7 Searching a Directory

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

3.8 Making a Service Discovery Request

<?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.

4. Authentication

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.

5. Security Considerations

The receiver SHOULD delete the XMPP file when done with it. This will help prevent certain HTTP caching problems.

6. IANA Considerations

This JEP requires registration of the "application/xmpp+xml" MIME type with the Internet Assigned Numbers Authority (IANA) [8]. Details to follow.

7. Jabber Registrar Considerations

No namespaces or parameters need to be registered with the Jabber Registrar [9] as a result of this JEP.

8. XML Schema

To follow.

9. Open Issues

  1. Fully specify invocation process flow.
  2. Define IANA registration.
  3. Add implementation notes for server MIME type registration and HTTP Content-Type output.
  4. Add implementation notes for client handling on various platforms (e.g., DDE messages in Windows).
  5. Add optional support for authentication (e.g., for Single Sign On).


Notes

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/>.


Revision History

Version 0.3 (2004-07-26)

Formally retracted this proposal in favor of the relevant Internet-Drafts. (psa)

Version 0.2 (2003-08-18)

Added authentication example. (psa)

Version 0.1 (2003-04-21)

Initial version. (psa)


END