[Standards] "Chronological" order in XEP-0313 (Message Archive Management)

Georg Lukas georg at op-co.de
Thu May 19 08:21:40 UTC 2016


Hi,

we just had a discussion in the prosody MUC, regarding message ordering
in MAM, and I realized there is some ambiguity in the XEP when handling
incoming <delay> elements.

The XEP explicitly states that messages must be sorted chronologically:

"The collection is ordered chronologically by the time each message was
sent/received." (3.1)

"The archive results MUST be sorted in chronological order" (4.2)

However, it does not make clear how to handle messages that already
contain a <delay> element (i.e. because the client was disconnected when
the user entered the message).

XEP-0203 almost states that there can be only one <delay> element, but
after re-reading it I realized that a server/component may only *add*
one such element, potentially ending up with two or more of them.
However, this is material for a separate post.

In MAM, the storing server needs to decide whether to:

a) discard incoming <delay> elements, worsening the overall UX.

b) accept incoming <delay> as the master timestamp for a message, and
place it somewhere in the middle of the archive, making the message
essentially unretrievable on a typical partial sync.

c) keep the <delay> element in the message, and deliver a message with
multiple <delay>s on a MAM query, potentially breaking clients that
don't anticipate multi-<delay>s.

d) keep the original <delay> element and deliver MAM results without the
MAM server's own <delay> element, potentially breaking time-based query
support.

These are all not shiny, but one way or the other, there should be some
clarification in the XEP regarding what "chronological" actually means
and how incoming <delay> elements should be processed.


Georg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160519/f2c31cc4/attachment.sig>


More information about the Standards mailing list