Let's archive FUD.

We can draw a parallel between protocols and men: confidence comes with maturity. I believe the latest versions of the public key publishing and message archiving extensions to XMPP are to be interpreted as a concrete sign of maturity. In which way would you ask? In leveraging other existing protocols to their own advantage, in this case the established XML digital signature and encryption.
The process of standardizing a protocol often implies walking a narrow path between the "not invented here" (let's redo everything) and the "narcissistic elitism" (we can do everything) precipices.  In my opinion, when protocol's extensions authors rely on somebody else's work, it gives a strong signal they, and by consequence the protocol, have reached an "adult" level of confidence. And in turn, the early natural fears and doubts linked to this kind of endeavor are clearing out.

Going back to the proposed extensions, although I find the public key publishing proposal ready for implementation, I believe the message archiving proposal requires further improvement. Don't get me wrong, I am in no way diminishing the great work provided by the authors. I am just saying that, with few modifications, this archiving proposal could open a much wider perspective in our days of hyper communication.

From the JEP-136 introduction, I read the purpose of the extension.

Many XMPP clients implement some form of client-side message archiving. However, it is not always convenient or even possible to archive messages locally, e.g., because it is easier to keep all archives in one universally accessible place (not scattered around on multiple computers or devices) or because the client operates in a web browser or resides on a mobile device that does not have sufficient local storage for message archiving. In addition, server-side archiving makes it possible to offer new services such as integration of IM and email. Therefore it is beneficial to define methods for server-side archiving of XMPP messages.

In essence, this describes an application process, either manual or automatic, where different conversation threads are recorded to a store for later processing. When you think of it, this is a very natural extension to any communication system. It is also a typical storage application, with typical application subsystems:

• Recording rules management (preferences)
• Conversations management (collections)
• Conversations' items management (messages)
• Content replication management

In the end, this is not very different from a mail box or a blog post management application. The transport protocol for interacting with the application will have to be adapted to the appropriate client, but the operations will remain identical: modify, add, delete collections, modify, add, delete items, list store content. And all this is independent of the actual content of the messages or collections. To re-enforce this point, just note how the JEP describes the two cases of clear and encrypted content, and provide adequate methods for both content types. I believe the JEP would greatly benefit using Atom and its extensions instead of an home grown content format. 
From a functional stand point, there is no difference between using the JEP proposed content format, and a standardized Atom content, as represented bellow.

<iq type="set" to="montague.net" id="up2">
 <store xmlns="http://jabber.org/protocol/archive"
        with="juliet@capulet.com/chamber"
        start="1469-07-21T02:56:15Z"
        subject="She speaks!">
  <feed xmlns="http://www.w3.org/2005/Atom"
        xmlns:thr="http://purl.org/syndication/thread/1.0">
   <title type="text">She speaks!</title>
   <updated>1469-07-21T02:56:15Z</updated>
   <generator uri="romeo@montague.net" version="1.0">
      Verona client
   </generator>
   <id>60a76c80-d399-11d9-b91C-0003939e0af6</id>
   <entry>
    <id>60a76c80-d399-11d9-b91C-0003939e0af6:0</id>
    <published>1469-07-21T02:56:15Z</published>
    <author>
     <name>Juliet</name>
     <uri>juliet@capulet.com/chamber</uri>
    </author>
    <content type="xmpp" xml:lang="en">
     <body>Art thou not Romeo, and a Montague?</body>
    </content>
   </entry>
   <entry>
    <id>60a76c80-d399-11d9-b91C-0003939e0af6:1</id>
    <published>1469-07-21T02:56:26Z</published>
    <author>
     <name>Romeo</name>
     <uri>romeo@montague.net/orchard</uri>
    </author>
    <thr:in-reply-to ref="60a76c80-d399-11d9-b91C-0003939e0af6:0"/>
    <content type="xmpp" xml:lang="en">
     <body>Neither, fair saint, if either thee dislike.</body>
    </content>
   </entry>
   <entry>
    <id>60a76c80-d399-11d9-b91C-0003939e0af6:2</id>
    <published>1469-07-21T02:56:29Z</published>
    <author>
     <name>Juliet</name>
     <uri>juliet@capulet.com/chamber</uri>
    </author>
    <thr:in-reply-to ref="60a76c80-d399-11d9-b91C-0003939e0af6:1"/>
    <content type="xmpp" xml:lang="en">
     <body>How cam'st thou hither, tell me, and wherefore?</body>
    </content>
   </entry>
   <entry>
    <id>note:60a76c80-d399-11d9-b91C-0003939e0af6:0</id>
    <published>1469-07-21T03:04:35Z</published>
    <author>
     <name>Romeo</name>
     <uri>romeo@montague.net/orchard</uri>
    </author>
    <content type="xhtml" xml:lang="en">
     <div xmlns="http://www.w3.org/1999/xhtml">
       I think she might fancy me.
     </div>
    </content>
   </entry>
  </feed>
 </store>
</iq>

I believe in re-using what has already been thoroughly and critically discussed when it comes to standards covering the same field of application. In this case, with all due respect for the JEP authors, I think most aspects related to expressing web contents are already incorporated in the Atom specification, including standardized extension methods. In comparison, an XMPP specific content format will almost certainly be limitative. I am not certain the JEP authors have had the time to consider all the possible content use cases, which is perfectly understandable. On the other hand, they know XMPP well, and they came up with a good management envelope around the content. I have no doubt they would find adapting the query part of the extension to an Atom content easy.

I know that some of the JEP authors are particularly cautious with the size of what is sent over the network when it comes to wireless clients, and they may object as to the increased size of the XMPP payload. In this precise case, this would not apply, as the JEP is meant initially to provide a service to such limited local storage capacity client. In practice, the kind of content I describe will never be transmitted to these clients.

In the end, the same content information is conveyed, with a much greater content extensibility built into Atom, and the flexibility of XMPP for the transport. And this alone offers a number of possible applications beyond message archiving. For example, the exact same protocol can be used to post to a blog. Using Atom as the exchange format immediately increases the complementarities between XMPP servers and traditional web servers. XMPP servers could expose conversations as feeds. Etc… The end-user imagination only becomes the limit, and not the JEP. And this in turn is invaluable.

Technorati Tags: XMPP, Jabber, Atom, Interoperability, Instant messaging, Antecipate