JEP-0136: Message Archiving

Justin Karneges

Email: justin@affinix.com
JID: justin@andbit.net

Ian Paterson

Email: ian.paterson@clientside.co.uk
JID: ian@zoofy.com

Jon Perlow

Email: jonp@google.com
JID: jonp@google.com

Peter Saint-Andre

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

1. Introduction

2. Determining Server Support

3. Automated Archiving

3.1. Save Mode

3.1.1. Requirements

3.1.2. Determining Save Mode States

3.1.3. Toggling Default Save Mode State

3.1.4. Toggling Save Mode State for a Contact

3.2. Off-the-Record Mode

3.2.1. Requirements

3.2.2. Determining Off-the-Record Mode for a Contact

3.2.3. Toggling Off-the-Record Mode State for a Contact

3.2.4. Sending Message Stanzas

4. Manual Archiving

4.1. Requirements

4.2. Uploading Messages to a Collection

5. Archive Management

5.1. Obtaining a List of Collections

5.2. Retrieving a Collection

5.3. Removing a Collection

6. File Format

7. Implementation Notes

7.1. Bandwidth Considerations

7.2. Karma Considerations

7.3. Synchronization

7.4. Storage Considerations

7.5. Groupchat Messages

8. Security Considerations

8.1. Encryption of Archived Messages

8.2. Store Headers

8.3. Subject Attributes

9. IANA Considerations

10. Jabber Registrar Considerations

10.1. Protocol Namespaces

10.2. Service Discovery Features

11. XML Schemas

Notes

Revision History

    
<iq type='get' to='montague.net'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

    
<iq type='result'
    from='montague.net'
    to='romeo@montague.net/orchard'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
    ...
    <feature var='http://jabber.org/protocol/archive#manage'/>
    <feature var='http://jabber.org/protocol/archive#manual'/>
    <feature var='http://jabber.org/protocol/archive#otr'/>
    <feature var='http://jabber.org/protocol/archive#save'/>
    ...
  </query>
</iq>

3.1 Save Mode

<iq type='get' id='save1' from='juliet@capulet.com/chamber'>
  <save xmlns='http://jabber.org/protocol/archive'/>
</iq>
      

<iq type='result' id='save1' to='juliet@capulet.com/chamber'>
  <save xmlns='http://jabber.org/protocol/archive'>
    <default save='true'/>
  </save>
</iq>
      

<iq type='result' id='save1' to='juliet@capulet.com/chamber'>
  <save xmlns='http://jabber.org/protocol/archive'>
    <default save='true'/>
    <item jid='romeo@montague.net' save='false'/>
  </save>
</iq>
      

<iq type='set' id='save2' from='juliet@capulet.com/chamber'>
  <save xmlns='http://jabber.org/protocol/archive'>
    <default save='true'/>
  </save>
</iq>
      

<iq type='result' id='save2' to='juliet@capulet.com/chamber'/>
      

<iq type='set' id='savepush1' to='juliet@capulet.com/chamber'>
  <save xmlns='http://jabber.org/protocol/archive'>
    <default save='true'/>
  </save>
</iq>

<iq type='set' id='savepush2' to='juliet@capulet.com/pda'>
  <save xmlns='http://jabber.org/protocol/archive'>
    <default save='true'/>
  </save>
</iq>
      

<iq type='set' item='save3' from='juliet@capulet.com/chamber'>
  <save xmlns='http://jabber.org/protocol/archive'>
    <item jid='romeo@montague.net' save='false'/>
  </save>
</iq>
      

<iq type='result' id='save3' to='juliet@capulet.com/chamber'/>
      

<iq type='set' id='savepush3' to='juliet@capulet.com/chamber'>
  <save xmlns='http://jabber.org/protocol/archive'>
    <item jid='romeo@montague.net' save='false'/>
  </save>
</iq>

<iq type='set' id='savepush4' to='juliet@capulet.com/pda'>
  <save xmlns='http://jabber.org/protocol/archive'>
    <item jid='romeo@montague.net' save='false'/>
  </save>
</iq>
      

3.2 Off-the-Record Mode

<iq type='get' id='otr1' from='romeo@montague.net/castle'>
  <otr xmlns='http://jabber.org/protocol/archive'/>
</iq>
      

<iq type='result' id='otr1' to='juliet@capulet.com/chamber'>
  <otr xmlns='http://jabber.org/protocol/archive'>
    <record jid='priest@church.org' otr='true'/>
  </otr>
</iq>
      

<iq type='set' id='otr2' from='juliet@capulet.com/chamber'>
 <record xmlns='http://jabber.org/protocol/archive'
         jid='romeo@montague.net' otr='true'/>
/iq>
      

<iq type='set' from='juliet@capulet.com' to='romeo@montague.net' id='notify1'>
  <record xmlns='http://jabber.org/protocol/archive' otr='true'/>
</iq>
      

<iq type='set' to='juliet@capulet.com/chamber' id='update1'>
  <record xmlns='http://jabber.org/protocol/archive'
          jid='romeo@montague.net' otr='true'/>
</iq>

<iq type='set' to='juliet@capulet.com/pda' id='update2'>
  <record xmlns='http://jabber.org/protocol/archive'
          jid='romeo@montague.net' otr='true'/>
</iq>
      

<iq type='result' id='otr2' to='juliet@capulet.com/chamber'>
      

<iq type='set' to='romeo@montague.net/orchard' id='update3'>
  <record xmlns='http://jabber.org/protocol/archive'
          jid='juliet@capulet.com' otr='true'/>
</iq>
      

<message from='romeo@montague.net/home' to='juliet@capulet.com'>
  <body>Juliet, can you sneak out tonight?</body>
</message>
      

<message from='romeo@montague.net/home' to='juliet@capulet.com'>
  <body>Juliet, can you sneak out tonight?</body>
  <record xmlns='http://jabber.org/protocol/archive' otr='true'/>
</message>
      

4.1 Requirements

While automated archiving is easy for the client and server to implement, there are contexts in which automated archiving is unacceptable (e.g., because the client does not trust the server) or unworkable (e.g., when messages are encrypted using evanscent keys, as in Encrypted Sessions [4]). Therefore, often a client will want to receive a message, optionally process it (e.g., encrypt it), then ask the server to store the message.

Such messages SHOULD be stored in the form of a "collection", i.e., a set of messages from the same user that are received near each other in time. A collection is intended to mimic the natural flow of human conversations, which in instant messaging (IM) systems tend to occur in bursts (e.g., a five-minute conversation one day, followed by a ten-minute conversation the next). However, sometimes IM message exchange does not follow this conversational pattern; in that case, collections SHOULD be arbitrarily truncated so that transferring them does not violate common rate limiting restrictions (in Jabber systems, often called "karma") or memory limitations for constrained devices.

Messages are stored in message collections on the server. The client uniquely specifies a collection using the pair of attributes: 'with' (the bare JID with which the messages were exchanged) and 'start' (the UTC start time of the conversation thread, which MUST adhere to the DateTime format specified in Jabber Date and Time Profiles [5]).

The content of each individual message MUST be encapsulated in a <to/> or <from/> element. The time in seconds of the message relative to the start-time of the collection SHOULD be specified with a 'secs' attribute. The content SHOULD include a <body/> element. Other elements MAY be included, but they are NOT RECOMMENDED. To conserve bandwidth and storage space, elements qualified by the 'http://jabber.org/protocol/xhtml-im' namespace SHOULD NOT be included. <thread/> elements and elements qualified by the 'jabber:x:delay', 'jabber:x:event' and 'http://jabber.org/protocol/chatstates' namespaces MUST NOT be included.

Complying with XMPP Core, the server MUST respond to all <iq/> element of type 'get' or 'set'. However, most successful responses have been omitted from this document in the interest of conciseness.

All times MUST be set to UTC.

4.2 Uploading Messages to a Collection

The messages to be uploaded are encapsulated in the <store/> element.

Example 21. Storing messages in a collection

<iq type='set' to='montague.net' id='up1'>
  <store xmlns='http://jabber.org/protocol/archive'
         with='juliet@capulet.com'
         start='1469-07-21T02:56:15Z'
         subject='She speaks!'>
    <from secs='0'><body>Art thou not Romeo, and a Montague?</body></from>
    <to secs='11'><body>Neither, fair saint, if either thee dislike.</body></to>
    <from secs='14'><body>How cam'st thou hither, tell me, and wherefore?</body></from>
  </store>
</iq>
    

If the collection does not exist then the server MUST create a new collection. If the collection already exists then the server MUST append the messages to the existing collection.

A friendly name for the collection MAY be specified with a 'subject' attribute. If the collection already has a 'subject' then it is simply replaced. Note the Security Considerations regarding the subject attribute.

Example 22. Successful reply

<iq type='result' to='romeo@montague.net/orchard' id='up1'/>
    

If the server cannot service a store request because the collection is too large then it MUST return a <not-acceptable/> error:

Example 23. Unsuccessful reply

<iq type='error' to='romeo@montague.net/orchard'>
  <error code='406' type='modify'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

The client MAY specify an absolute time for any message by providing a longer 'utc' attribute instead of a 'secs' attribute:

Example 24. Storing offline messages in a collection

<iq type='set' to='montague.net' id='up2'>
  <store xmlns='http://jabber.org/protocol/archive'
         with='juliet@capulet.com'
         start='1469-07-21T02:56:15Z'
         subject='She speaks!'>
    <from utc='1469-07-21T00:32:29Z'><body>Art thou not Romeo, and a Montague?</body></from>
    <to secs='11'><body>Neither, fair saint, if either thee dislike.</body></to>
    <from secs='14'><body>How cam'st thou hither, tell me, and wherefore?</body></from>
  </store>
</iq>
    

5.1 Obtaining a List of Collections

To request a list of collections the client sends an empty <list/> element. The 'start' and 'end' attributes MAY be specified to indicate a date range (the values of these attributes MUST adhere to the DateTime format specified in JEP-0082).

If the 'with' attribute is omitted then collections with any JID are returned. If only 'start' is specified then all collections on or after that date should be returned. If only 'end' is specified then all collections prior to that date should be returned.

Example 25. Requesting a list

<iq type='get' to='montague.net'>
  <list xmlns='http://jabber.org/protocol/archive'
        with='juliet@capulet.com'
        start='1469-07-21T02:00:00Z'
        end='1479-07-21T04:00:00Z'/>
</iq>
    

Example 26. Requesting a list of all collections with a JID

<iq type='get' to='montague.net'>
  <list xmlns='http://jabber.org/protocol/archive'
        with='juliet@capulet.com'/>
</iq>
    

The client MAY limit the number of items returned by the server with the 'maxitems' attribute.

Example 27. Requesting a list of all collections

<iq type='get' to='montague.net'>
  <list xmlns='http://jabber.org/protocol/archive'
        maxitems='50'/>
</iq>
    

The collections (empty <store/> elements) in the result MUST be listed in chronological order.

Example 28. Receiving a list

<iq type='result' id='a1' to='romeo@montague.net/orchard'>
  <list xmlns='http://jabber.org/protocol/archive'>
    <store with='juliet@capulet.com'
           start='1469-07-21T02:56:15Z'
           subject='She speaks!'/>
    <store with='balcony@house.capulet.com'
           start='1469-07-21T03:16:37Z'/>
    ...
  </list>
</iq>
    

If the requested list would be too long to return in its entirety without exceeding karma limits (or any other limit specified by an administrator), then the server SHOULD only return the first part of the list. In this case the server MUST indicate that the list is incomplete by setting the optional 'partial' attribute of the <list/> element to 'true'.

Example 29. Receiving a partial list

<iq type='result' id='a1' to='romeo@montague.net/orchard'>
  <list partial='true' xmlns='http://jabber.org/protocol/archive'>
    <store with='juliet@capulet.com'
           start='1469-07-21T02:56:15Z'
           subject='She speaks!'/>
    <store with='balcony@house.capulet.com'
           start='1469-07-21T03:16:37Z'/>
    ...
  </list>
</iq>
    

If it has received a partial list, the client MAY then request the remainder of the list, taking care to set the value of the 'start' attribute to one second after the time of the last collection in the partial list that it received.

5.2 Retrieving a Collection

The client sends an empty <retrieve/> element to request the download of a collection:

Example 30. Requesting a collection

<iq type='get' to='montague.net' id='down1'>
  <retrieve xmlns='http://jabber.org/protocol/archive'
            with='juliet@capulet.com'
            start='1469-07-21T02:56:15Z'/>
</iq>
    

Example 31. Receiving a collection

<iq type='result' to='montague.net'>
  <store xmlns='http://jabber.org/protocol/archive'
         with='juliet@capulet.com'
         start='1469-07-21T02:56:15Z'
         subject='She speaks!'>
    <from secs='0'><body>Art thou not Romeo, and a Montague?</body></from>
    <to secs='11'><body>Neither, fair saint, if either thee dislike.</body></to>
    <from secs='14'><body>How cam'st thou hither, tell me, and wherefore?</body></from>
  </store>
</iq>
    

If the collection does not exist then the server MUST return an <item-not-found/> error:

Example 32. Unsuccessful reply

<iq type='error' to='romeo@montague.net/orchard'>
  <error code='404' type='cancel'>
    <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

If the collection would be too long to return in its entirety without exceeding karma limits (or any other limit specified by an administrator), then the server SHOULD return only the first part of the collection. In this case the server MUST indicate that the collection is incomplete by setting the optional 'partial' attribute of the <list/> element to 'true'.

Example 33. Receiving a partial collection

<iq type='result' id='a1' to='romeo@montague.net/orchard'>
  <store xmlns='http://jabber.org/protocol/archive'
         partial='true'
         start='1469-07-21T02:56:15Z'
         subject='She speaks!'
         with='juliet@capulet.com'>
    <from secs='0'><body>Art thou not Romeo, and a Montague?</body></from>
    <to secs='11'><body>Neither, fair saint, if either thee dislike.</body></to>
    <from secs='14'><body>How cam'st thou hither, tell me, and wherefore?</body></from>
  </store>
</iq>
    

If it has received a partial collection, the client MAY then request the remainder of the collection, taking care to set the value of the 'start' attribute to one second after the time of the last <from/> or <to/> element in the partial collection that it received.

5.3 Removing a Collection

To request the removal of a collection the client sends an empty <remove/> element.

Example 34. Removing a single collection

<iq type='set' to='montague.net'>
  <remove xmlns='http://jabber.org/protocol/archive'
          with='juliet@capulet.com'
          start='1469-07-21T02:56:15Z'/>
</iq>
    

If the collection does not exist then the server MUST return a Not Found error:

Example 35. Unsuccessful reply

<iq type='error' to='romeo@montague.net/orchard'>
  <error code='404' type='cancel'>
    <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

The client may remove several collections at once. The 'start' and 'end' elements MAY be specified to indicate a date range.

Example 36. Removing all collections with a specified JID between two times

<iq type='set' to='montague.net'>
  <remove xmlns='http://jabber.org/protocol/archive'
          with='juliet@capulet.com'
          start='1469-07-21T02:00:00Z'
          end='1469-07-21T04:00:00Z'/>
</iq>
    

If the 'with' attribute is omitted then collections with any JID are removed.

If the end date is in the future then then all collections after the start date are removed.

Example 37. Removing all collections after a date

<iq type='set' to='montague.net'>
  <remove xmlns='http://jabber.org/protocol/archive'
          start='1469-07-21T02:00:00Z'
          end='2038-01-01T00:00:00Z'/>
</iq>
    

If the start date is before all the collections in the archive then all collections prior to the end date are removed.

Example 38. Removing all collections before a date

<iq type='set' to='montague.net'>
  <remove xmlns='http://jabber.org/protocol/archive'
          start='0000-01-01T00:00:00Z'
          end='1469-07-21T04:00:00Z'/>
</iq>
    

Example 39. Removing all collections

<iq type='set' to='montague.net'>
  <remove xmlns='http://jabber.org/protocol/archive'/>
</iq>
    

<?xml version='1.0'?>
<archive xmlns='http://jabber.org/protocol/archive'
         with='juliet@capulet.com'>
  <store start='1469-07-21T02:56:15Z' subject='She speaks!'>
    <from secs='0'><body>Art thou not Romeo, and a Montague?</body></from>
    <to secs='11'><body>Neither, fair saint, if either thee dislike.</body></to>
    <from secs='14'><body>How cam'st thou hither, tell me, and wherefore?</body></from>
  </store>
</archive>
  

7.1 Bandwidth Considerations

When uploading messages using manual archiving, a client SHOULD NOT store one message at a time on the server since this increases both bandwidth consumption and the total number of transactions. It is instead RECOMMENDED that clients store messages only when the conversation thread appears to be terminated, i.e. when the user closes the chat window. If the user reopens the window and the thread continues then the client should append the new messages to the collection when the user closes the window again.

7.2 Karma Considerations

When appending messages to a collection clients SHOULD try to ensure that the total size of the collection will not exceed karma limits when it is retrieved later. This may be achieved by starting a new collection whenever a message thread becomes too long.

7.3 Synchronization

It is RECOMMENDED for the client synchronize all the times it sends to the server with server time. The client can achieve this using Entity Time [6] to estimate the difference between the server and client clocks.

7.4 Storage Considerations

Server implementations SHOULD give system administrators the option to disable support for both automated and manual archiving, since archived conversations can consume significant storage space.

7.5 Groupchat Messages

A client MAY archive messages that it receives in the context of Multi-User Chat [7] rooms. The client SHOULD include a 'name' attribute to specify the room nickname of all messages:

Example 41. Storing groupchat messages in a collection

<iq type='set' to='montague.net' id='up3'>
  <store xmlns='http://jabber.org/protocol/archive'
         with='balcony@house.capulet.com'
         start='1469-07-21T03:16:37Z'>
    <from secs='0' name='benvolio'><body>She will indite him to some supper.</body></from>
    <from secs='5' name='mercutio'><body>A bawd, a bawd, a bawd! So ho!</body></from>
    <from secs='11' name='romeo'><body>What hast thou found?</body></from>
  </store>
</iq>
    

8.1 Encryption of Archived Messages

Because a server can be compromised, it is RECOMMENDED to encrypt archived messages. Methods for doing so are under development and will be specified in a separate document or in a new section of this document.

8.2 Store Headers

The client that originates a message MAY specify a 'false' value for the 'store' header (see Stanza Headers and Internet Metadata [8]). The recipient MUST NOT archive such a message or any of the information it contains. If the sender plans to use 'store' headers it MUST use Service Discovery to determine whether or not the recipient supports them. If not, the sender MUST warn its human user (if any) before sending the message.

8.3 Subject Attributes

Since the subject of each collection is not encrypted, the client MUST warn its human user (if any) before including 'subject' attributes on encrypted collections.

10.1 Protocol Namespaces

The Jabber Registrar [10] shall include 'http://jabber.org/protocol/archive' in its registry of protocol namespaces (see <http://www.jabber.org/registrar/namespaces.html>):

10.2 Service Discovery Features

The Jabber Registrar shall include the following features in its registry of service discovery features (see <http://www.jabber.org/registrar/disco-features.html>):

• http://jabber.org/protocol/archive#manage
• http://jabber.org/protocol/archive#manual
• http://jabber.org/protocol/archive#otr
• http://jabber.org/protocol/archive#save

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/archive'
    xmlns='http://jabber.org/protocol/archive'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The allowable root element for the namespace defined
      herein are:
        - archive
        - list
        - otr
        - record
        - remove
        - retrieve
        - save
        - store
    </xs:documentation>
  </xs:annotation>

  <xs:element name='archive'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='store' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:attribute name='with' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='list'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='store' minOccurs='0' maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:attribute name='end' type='xs:dateTime' use='optional'/>
      <xs:attribute name='maxitems' type='xs:positiveInteger' use='optional'/>
      <xs:attribute name='partial' type='xs:boolean' use='optional'/>
      <xs:attribute name='start' type='xs:dateTime' use='optional'/>
      <xs:attribute name='with' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='otr'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='record' minOccurs='0' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='record'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='jid' use='optional' type='xs:string'/>
          <xs:attribute name='otr' use='required' type='xs:boolean'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='remove'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='end' type='xs:dateTime' use='optional'/>
          <xs:attribute name='start' type='xs:dateTime' use='required'/>
          <xs:attribute name='with' type='xs:string' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='retrieve'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='start' type='xs:dateTime' use='required'/>
          <xs:attribute name='with' type='xs:string' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='save'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='default' minOccurs='0' maxOccurs='1'/>
        <xs:element ref='item' minOccurs='0' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='store'>
    <xs:complexType>
      <xs:choice maxOccurs='unbounded'>
        <xs:element name='from' type='messageType'/>
        <xs:element name='to' type='messageType'/>
      </xs:choice>
      <xs:attribute name='partial' type='xs:boolean' use='optional'/>
      <xs:attribute name='start' type='xs:dateTime' use='required'/>
      <xs:attribute name='subject' type='xs:string' use='optional'/>
      <xs:attribute name='with' type='xs:string' use='required'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='default'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='save' use='required' type='xs:boolean'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='item'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='jid' use='required' type='xs:string'/>
          <xs:attribute name='save' use='required' type='xs:boolean'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:complexType name='messageType'>
    <xs:sequence>
      <xs:element name='body' type='xs:string' maxOccurs='unbounded'/>
    </xs:sequence>
    <xs:attribute name='secs' type='xs:nonNegativeInteger' use='required'/>
  </xs:complexType>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
  

1. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.

2. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.

3. JEP-0131: Stanza Headers and Internet Metadata <http://www.jabber.org/jeps/jep-0131.html>.

4. JEP-0116: Encrypted Sessions <http://www.jabber.org/jeps/jep-0116.html>.

5. JEP-0082: Jabber Date and Time Profiles <http://www.jabber.org/jeps/jep-0082.html>.

6. JEP-0090: Entity Time <http://www.jabber.org/jeps/jep-0090.html>.

7. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.

8. JEP-0131: Stanza Headers and Internet Metadata <http://www.jabber.org/jeps/jep-0131.html>.

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

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

Version 0.5 (2006-05-03)

Version 0.4 (2005-12-21)

Version 0.3 (2005-10-21)

Version 0.2 (2005-04-18)

Version 0.1 (2004-06-04)