> On 27 Oct 2017, at 12:19, Florian Schmaus <f...@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@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. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
