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 future. 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 --rr
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
