XEP-xxxx: Jabber Through DIME

This document defines a protocol that allows Jabber packets to be encapsulated using Direct Internet Message Encapsulation.

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document must not be referred to as an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://www.xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.

Document Information

Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Standards Track
Version: 0.0.1
Last Updated: 2001-08-27
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0001
Supersedes: None
Superseded By: None
Short Name: NOT YET ASSIGNED

Author Information

Peter Saint-Andre

Email: stpeter@jabber.org
JabberID: stpeter@jabber.org

Jonathan Dickinson

Email: chayce.za@gmail.com
JabberID: moitoi@inflecto.org

Legal Notice

This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy (<http://www.xmpp.org/extensions/ipr-policy.shtml>). This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Table of Contents


1. Introduction
2. Requirements
3. Glossary
4. DIME Basics
    4.1. Version
    4.2. Message Begin
    4.3. Message End
    4.4. Chunked Flag
    4.5. Type Type
    4.6. Reserved
    4.7. Options Length
    4.8. ID Length
    4.9. Type Length
    4.10. Data Length
    4.11. Options
    4.12. ID
    4.13. Type
    4.14. DATA
5. DIME Interleaving
6. Use Cases
    6.1. Initiating DIME
    6.2. Referencing DIME in Jabber Stanzas
    6.3. Referencing DIME in Existing Jabber Stanzas
7. Business Rules
8. Security Considerations
9. IANA Considerations
10. XMPP Registrar Considerations
    10.1. Namespaces
11. XML Schema
Notes
Revision History

1. Introduction

DIME is a specification that was submitted to the IETF which details sending SOAP messages along with attachments, like binary files, XML Fragments and even other SOAP messages.

DIME allows you to send attachments of various types along with your SOAP message, even when the attachments in question do not fit conveniently or efficiently into an XML format. DIME is designed to be a fast and efficient protocol to parse, which makes it ideal for Jabber servers.

DIME will rectify the absence of true In-Band Bytestreams, as it defines methods to send multiple payloads in a atomical message. Each payload int the message can reference other playloads in the message.

This will hopefully provide bandwidth reductions, as the length of the data encoded as Base64 tends toward one and a third times the original length of the data.

Furthermore compression methods used by servers (which tend to be fast instead of small) will, at best, return the data to near it's original length. If the data is presented to these algorythms in its original state they may be able to compress it even further.

Ultimately this protocol will smooth out the issues plauging Jabber regarding file sharing.

Almost all the existing XEPs should be able to derive some further benefit from this extension (especially Jingle and SI).

2. Requirements

3. Glossary

Message A DIME message. Payload A DIME payload (i.e. a segment of a DIME message).

4. DIME Basics

Each DIME message has a header which describes it before-hand to the parser.

DIME Structure

|--------------------32 Bits--------------------|
|------------16 Bits-------------|---16 Bits----|
v                                v              v
+-------+--+--+--+------+--------+--------------+
|VERSION|MB|ME|CF|TYPE_T|RESERVED|OPTIONS_LENGTH|
+-------+--+--+--+------+--------+--------------+
|ID_LENGTH                       |TYPE_LENGTH   |
+-----------------------------------------------+
|DATA_LENGTH                                    |
+-----------------------------------------------+
|[OPTIONS]                                      |
+-----------------------------------------------+
|[ID]                                           |
+-----------------------------------------------+
|[TYPE]                                         |
+-----------------------------------------------+
|[DATA]                                         |
+-----------------------------------------------+

4.1 Version

5 bit: This should always be set to Version 1, as it is the only version that Jabber currently supports.

4.2 Message Begin

1 bit: This specifies that the record is the first in the message.

4.3 Message End

1 bit: This specifies that the record is the last in the message.

4.4 Chunked Flag

1 bit:

Previously Unset, Currently Set This is the start of a chunked payload. Previously Set, Currently Set This is part of a chunked payload. Previously Set, Currently Unset This is part of a chunked payload, however, the next payload is not.

4.5 Type Type

4 bit: Specifies the structure and format of the TYPE field. It can be one of three values: 0x00 The type is absent. TYPE_LENGTH must be set to zero in this case. Only the first chunk in a string of chunks SHOULD provide the type. 0x02 Mime: the type is specified using a MIME value. 0x04 Uri: the type is specified using a URI.

4.6 Reserved

4 bit: This MUST NOT be used. If a client or server receives this field set to any other value than 0x00 it SHOULD assume that the stream is erronous and SHOULD immediately terminate the stream.

4.7 Options Length

16 bit: Specifies the length (in bytes) of the OPTIONS field. This excludes the padding that makes the length a multiple of 4 octets. This field MUST NOT be set to 0.

4.8 ID Length

16 bit: Specifies the length (in bytes) of the ID field. This excludes the padding that makes the length a multiple of 4 octets. This MAY be set to 0.

4.9 Type Length

16 bit: Specifies the length (int bytes) of the TYPE field. This excludes the padding that makes the length a multiple of 4 octets. This MAY be set to 0.

4.10 Data Length

16 bit: Specifies the length (in bytes) of the DATA field. This excludes the padding that makes the length a multiple of 4 octets. This field MUST NOT be set to 0. A DIME payload with no data is not a valid DIME payload. It is RECOMMENDED that the data does not exceed (1920 - OPTIONS_LENGTH - ID_LENGTH - TYPE_LENGTH) bytes: use chunking if it does.

4.11 Options

[OPTIONS_LENGTH] bytes: Contains any additional options. This field is used for interleaving, clients MUST NOT use it for other purposes, any additions will be placed in the relevant XEPs. This field is a tight-packed array of ELEMENTs:

ELEMENT_T 16 bit: Integer that specifies the encoding of the element. ELEMENT_LENGTH 16 bit: Unsigned integer that specifies the length of the element, up to 64KB. ELEMENT_DATA [ELEMENT_LENGTH] bytes: contains the data for the element. This field can be up to 64KB in size and must be padded to the nearest 4-byte multiple.

4.12 ID

[ID_LENGTH] bytes: Contains a URI for uniquely identifying a DIME payload. This field will be referenced in other DIME payloads.

4.13 Type

[TYPE_LENGTH] bytes: Contains the type of data in the record. This should be empty for all but the first payload in a chunk or message.

4.14 DATA

[DATA_LENGTH] bytes: Contains the data for the payload.

5. DIME Interleaving

** We will have to see about getting a new ELEMENT for Jabber, I have enquired about an existing ID OPTIONS ELEMENT on the DIME mailing list for the time being. **

This field is set to ID. It must be less than 64KB long.

ID

ID ::= [/stream:stream/@id]<->[unique id]

Thus the following stream:

Example 1. Stream

<stream:stream 
  xmlns:stream="http://etherx.jabber.org/streams" 
  id="stream0">

Would present the following valid IDs:

Example 2. Stream IDs

stream0-0000
stream0-0001
stream0-0002

A new ID MUST be automatically handled. There is no negotiation for new IDs.

Each ID represents one DIME message. The IDs are completely reusable, but MUST only be reused once the terminating payload is received.

If the server receives a payloads from a client that does not own the stream it MUST discard the payloads. Furthermore the server MAY consider disconnecting that client and discontinuing their profile.

6. Use Cases

In the following examples the following rules apply:

6.1 Initiating DIME

The protocol flow is as follows:

Example 3. Receiving Entity Offers DIME Feature

<stream:stream [...]>
  <stream:features>
    <dime xmlns='http://www.xmpp.org/extensions/xep-xxxx.html#ns'>
  </stream:features>
    </example>
OR
<stream:stream [...] 
  xmlns:dime='http://www.xmpp.org/extensions/xep-xxxx.html#ns'>
    <stream:features>
      <dime:dime>
    </stream:features>

The second method is preferable. The initiating entity may then request that DIME is used:

Example 4. Initiating Entity Requests DIME

<dime:dime/>

If the receiving entity fails to initiate DIME, it MUST return a <setup-failed/> error:

Example 5. Receiving Entity Reports That Negotiation of DIME Failed

<dime:failure>
  <setup-failed/>
</dime:failure>

Note: Failure of the negotiation SHOULD NOT be treated as an unrecoverable error and therefore SHOULD NOT result in a stream error. In particular, the initiating entity is free to retry the DIME negotiation if it fails.

If no error occurs, the receiving entity MUST inform the initiating entity that DIME has been successfully negotiated:

Example 6. Receiving Entity Acknowledges Negotiation of Stream Compression

<dime:initiated/>

Both entities MUST now consider the previous (normal) stream to be null and void, just as with TLS negotiation and SASL negotiation (as specified in RFC 3920) and MUST begin DIME encapsulation with a new (DIME) stream. Therefore the initiating entity MUST initiate a new stream to the receiving entity, specifying an empty OPTIONS field:

Example 7. Initiating Entity Initiates New (DIME) Stream

--------------------------------
00001 1 1 0 0000 0000 0000000000100000 
0000000000000000 0000000000100000 
00000000000000000000000010111011 
0000000000000000 
0000000000000000 


http://etherx.jabber.org/streams
<stream:stream
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'
    xmlns:dime='http://www.xmpp.org/extensions/xep-xxxx.html#ns'
    to='shakespeare.lit'>

If compression processing fails after the new (DIME) stream has been established, the entity that detects the error SHOULD generate a stream error and close the stream:

Example 8. Entity Closes Stream Because of a Processing Error

--------------------------------
00001 1 1 0 0000 0000 0000000000101001 
0000000000000000 0000000000000000 
00000000000000000000000010111010 
0000000000000000 
0000000000001001 
stream0-1


<stream:error>
  <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
  <dime:failure>
    <processing-failed/>
  </dime:failure>
</stream:error>
</stream:stream>

Note: once you have specified that TYPE is http://etherx.jabber.org/streams you MAY neglect to provide the type for each stanza. However, attachments still require this to be present.

6.2 Referencing DIME in Jabber Stanzas

The inner text (NOT inner XML) of an element can be referenced in the following way:

Example 9. Referencing DIME using a Tag

--------------------------------
00001 1 0 0 0000 0000 0000000000101001 
0000000000000000 0000000000000000 
00000000000000000000000001000100 
0000000000000000 
0000000000001001 
stream0-2


<someElement>
  <!-- Length of 20KB -->
  <dime:attachment href="image1.jpg" length="20480"/>
</someElement>
--------------------------------
00001 0 0 1 0001 0000 0000000000101001 
0000000000001010 0000000000001010 
00000000000000000000100000000000 
0000000000000000 
0000000000001001 
stream0-2
image1.jpg
image/jpeg
[...x...]
--------------------------------
[...]
--------------------------------
00001 0 1 0 0000 0000 0000000000101001 
0000000000001010 0000000000000000 
00000000000000000000100000000000 
0000000000000000 
0000000000001001 
stream0-2
image1.jpg

[...x...]

6.3 Referencing DIME in Existing Jabber Stanzas

An existing element/tag may have one of its attributes point to a DIME attachment.

Example 10. Referencing DIME using an Attribute

        --------------------------------
00001 1 0 0 0000 0000 0000000000101001 
0000000000000000 0000000000000000 
00000000000000000000000010110110 
0000000000000000 
0000000000001001 
stream0-3


<message [...]>
  <html [...]>
    <body [...]>
      Hello, this is me!
      <img src="image1.jpg" 
           dime:act-apon="src" 
           dime:length="20480"/>
    </body>
  </html>
</message>
--------------------------------
00001 0 0 1 0001 0000 0000000000101001 
0000000000001010 0000000000001010 
00000000000000000000100000000000 
0000000000000000 
0000000000001001 
stream0-3
image1.jpg
image/jpeg
[...x...]
--------------------------------
[...]
--------------------------------
00001 0 1 0 0000 0000 0000000000101001 
0000000000001010 0000000000000000 
00000000000000000000100000000000 
0000000000000000 
0000000000001001 
stream0-3
image1.jpg

[...x...]

Note: Base64 data SHOULD NOT be sent as a failover in case DIME is not active. Negotiating DIME is a declaration that full DIME capabilities are present.

7. Business Rules

8. Security Considerations

A potential hacker may be able to inject DIME payloads into the message, however, this is rectified by checking that the source of the message is also the owner of the stream id.

9. IANA Considerations

IANA may have to assign an STREAMID ELEMENT. This has not been confirmed.

10. XMPP Registrar Considerations

10.1 Namespaces

The XMPP Registrar [10] includes 'http://www.xmpp.org/extensions/xep-xxxx.html#ns' in its registry of protocol namespaces.

11. XML Schema

I will implement this if this takes off.

Notes

Revision History

Version 0.0.1 (2001-08-27)

Proposal.

(jd)

END