[Standards] XEP-0313: pending 0.7 update review

Dave Cridland dave at cridland.net
Tue Apr 21 12:32:55 UTC 2020

On Mon, 20 Apr 2020 at 16:20, Matthew Wild <mwild1 at gmail.com> wrote:

> On Fri, 3 Apr 2020 at 21:51, Matthew Wild <mwild1 at gmail.com> wrote:
>> 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.
> I have just updated the PR in response to feedback here and in the MUC.
> Changes:
>   - Removed the separate iq for fetching a single message by id, this is
> now done via the 'ids' field in the data form and supports multiple ids
>   - Reverted the additional <gone/> error (the RFC defines this to mean
> something else, and the information signaled to the client was of
> questionable value)
>   - Added an iq to query information about the id and timestamps at the
> start/end of the archive, which can provide clients with useful information.
>   - Clarified the intention of the rule surrounding use of the user's bare
> JID in the 'with' query field.
> Thanks to everyone for the feedback and suggestions!
You're going to hate me, but one more thing...

Current MAM says that servers SHOULD include a count. The problem with this
is that it's extremely slow on any system with more than trivial retention
periods, since this tends to degenerate into either a COUNT(*) SQL query
(table-scan-tastic) or a standalone counter (which then drifts and is a
contention point).

The majority of client libraries appear to ignore the count values anyway,
as far as I can tell, so can we relax this to a MAY? (XEP-0059 is
MAY-but-only-if, which is arguably really a SHOULD anyway).

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

More information about the Standards mailing list