[Standards] XEP-0313: pending 0.7 update review

Ruslan N. Marchenko me at ruff.mobi
Sat Apr 4 11:32:03 UTC 2020

Am Freitag, den 03.04.2020, 21:51 +0100 schrieb Matthew Wild:
> Hi folks,
> XEP-0313 is a well-established protocol at this point, but didn't yet
> make it to the next stage in the standards process. Time to fix that!
> I have made a final round of updates to incorporate the various
> feedback I have received from people who have implemented the
> protocol over the past couple of years.
> One thing that kept coming up was splitting out some non-
> essential/rougher parts of the document. This I have done:
> preferences and pubsub archives have been split off to be separate
> XEPs.
> Preferences are not widely implemented, and actually implementing and
> using them has the potential to mess up the way many clients use MAM
> for sync today - these days I don't think it's a feature that should
> generally be exposed to users without caution.
> Pubsub archives are something that is conceptually simple, but that I
> think people still have a fair few questions about. So splitting that
> into a new document will hopefully give it some room to grow.
> The core of XEP-0313 that remains has actually gained some new
> features that were repeatedly requested by people to help with
> implementation issues. Importantly the namespace has not been bumped,
> but servers that support the new update will indicate this with an
> extra disco feature.
> The PRs are here:
> XEP-0313: https://github.com/xsf/xeps/pull/922
> MAM Preferences: https://github.com/xsf/xeps/pull/920
> Pubsub MAM: https://github.com/xsf/xeps/pull/921
> Feedback very welcome, but I hope we can get this wrapped up and
> advanced to Draft where it should be soon!
Thanks, that makes perfect sense to me as in my limited _mere p2p
conversation_ use case all those bells and whistles are rather
confusing.I don't understand though the need of _flip-page_ element -
the reverse _page_ order is achieved by <before> element (as specified
here [1]). Is it to reverse _message_ order (contradicting to
section Querying an archive)?
Anyway what I would like to see though is some more love to
synchronisation issue - it is explicitly written that real-time-sync is
out of scope but there's a gap which may lead to more mess in the
The xep mandates archiving entity to attach stanza-id for forward ID
notification, however reverse ID mapping creates a gap in the
specification. While implementing this on the server side I've followed
minimal requirements (only body must be stored) and it worked kind of
ok (there are some occasional dups but mostly in ingress
direction).While implementing this on the client side I've realized I
have no way to resolve message duplication issue following just minimal
specification. So I was forced to look at how other people resolved
this issue to avoid creating YAMTRD (yet another method to resolve
duplicaiton).So why not capture in the specification existing practice
to resolve this - namely* mandate storage of origin-id (and its support
by the client) and * client usage of the oid-to-sid mapping while
retrieving the archiveI understand it would be too much perhaps to
require the *client* to store oid for future use in deduplication but
if the spec mandates server to preserve oid and hints that it to use
for sync - that should  allow client to rely on the fact the oid will
always be there to help.To recap:* Communicating the archive ID: not
sure how to formulate it but something along the lines: if client
expects message synchronisation for outgoing messages it MUST add
origin-ID to the sent message and store the ID locally for future
synchronisation.* Business Rules -> Storage and Retrieval Rules -> User
Archives : At a minimum, the server MUST store the <body>
elements of a stanza. The server also MUST store origin-id element if
that was supplied in outgoing message by archive owner.
[1] - https://xmpp.org/extensions/xep-0059.html#backwards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200404/a28ac19b/attachment-0001.html>

More information about the Standards mailing list