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

Florian Schmaus flo at geekplace.eu
Sat Nov 4 09:55:09 UTC 2017


On 03.11.2017 21:35, Kevin Smith wrote:
>> 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.
>>> 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).

I am maybe wrong, since it is been a while that I dealt with the
situation, but wasn't there a mechanism missing allowing you to say
"Send me all archive messages after X *and* start sending the live
messages" (sometimes refereed to as MamSub)?

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

Imagine the following situation: A client subscribed to a PubSub node
wants to catch-up on reconnection. He knows the last item he received a
notification for. How does he request all newer items from the PubSub
node using MAM? From the current state of XEP-0313, I'm unable to
construct an example protocol flow from the last item notification to
the full MAM request-response sequence.

Maybe the only thing missing in order solve this is a (optional)
'start-pubsub-item-id' MAM form field specification?

I note that this situation is the same as the catch-up message archive
situation mentioned above. We possibly should have bullet-proof
solutions for this before we advance MAM.

I am also not sure if I would say that it is obvious that MAM IDs must
be independent from PubSub node IDs. It is clear if you think about it,
but for an average XMPP developer like me it would probably be helpful
to state that explicitly in the XEP.

Related comment: XEP-0313 says that the 'with' form field MUST be
supported by servers. What is the semantic of the 'with' field when used
with PubSub services? Or isn't it a requirement when using with PubSub?

Thinking more about it, I would also suggest refactoring the MAM-PubSub
part into an extra XEP, which nicely lists and explains the particularities.

- Florian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 642 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171104/7470a531/attachment.sig>


More information about the Standards mailing list