[Standards] LAST CALL: XEP-0313 (Message Archive Management)

Kevin Smith kevin.smith at isode.com
Fri Nov 3 20:35:42 UTC 2017

> On 27 Oct 2017, at 12:19, Florian Schmaus <flo at geekplace.eu> wrote:
> On 16.10.2017 20:38, Jonas Wielicki (XSF Editor) wrote:
>> This message constitutes notice of a Last Call for comments on
>> XEP-0313.
>> Abstract:
>> This document defines a protocol to query and control an archive of
>> messages stored on a server.
>> This Last Call begins today and shall end at the close of business on
>> 2017-10-30.
>> Please consider the following questions during this Last Call and send
>> your feedback to the standards at xmpp.org discussion list:
>> 1. Is this specification needed to fill gaps in the XMPP protocol
>> stack or to clarify an existing protocol?
> I was always under the impression that XEP-0313 started as an effort to
> produce a lightweight alternative to XEP-0136 (which itself states that
> it is "unduly complex"). XEP-0313 may was initially on the right track
> to become the missing lightweight "archive handling" protocol, and,
> while it is luckily only ~50% of the size of XEP-0136 (7268 vs. 13419
> words), it appears to me that it got lost a little bit.
> I'm a big fan of lightweight but dense base specifications stating only
> the absolute minimal requirements which can easily be extended by add-on
> XEPs. Unfortunately XEP-0313 became a little bit bloated in the end. I
> will name a few examples below.
>> 2. Does the specification solve the problem stated in the introduction
>> and requirements?
> I guess so, but archiving shouldn't be considered in isolation. A prime
> example is the "archive catch-up on reconnection" problem, for which we
> have some ideas for solutions (MamSub, …). but no champion yet.

Archive catch-up on reconnection we *can* do with MAM, although there are other parts that still need solving (particularly unread sync).

>> 5. Is the specification accurate and clearly written?
> For most parts yes. But it was recently discovered that it is unclear at
> best how MAM+PubSub should work together. It was even pointed out that
> it may be even impossible to use MAM with PubSub, since MAM-IDs are not
> PubSub Item IDs.

I’m not sure why that makes it impossible. These need to be independent ids, for the obvious id-in-pubsub-reuse reasons, but I don’t immediately see why that breaks anything.

> I think references to PubSub in XEP-0313 should either be removed or
> clarified before this XEP should advance.

I’m happy to clarify things. I don’t see a reason to remove it (it’s needed).

> I'd also like to encourage the authors to strip XEP-0313 to a minimum of
> what is requirement to perform most use cases. How about refactoring §
> 6. "Archiving Preferences" into an extra XEP?

I wholeheartedly agree with this.


More information about the Standards mailing list