[Standards] XEP-0313: pending 0.7 update review

Florian Schmaus flo at geekplace.eu
Tue Apr 21 14:49:58 UTC 2020

On 4/21/20 2:32 PM, Dave Cridland wrote:> On Mon, 20 Apr 2020 at 16:20,
Matthew Wild <mwild1 at gmail.com
> <mailto:mwild1 at gmail.com>> wrote:
>     On Fri, 3 Apr 2020 at 21:51, Matthew Wild <mwild1 at gmail.com
>     <mailto: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).

I think such a relaxation would require a namespace bump.

Alternatively, we could add a flag in the query request to omit the

Also given that <count/> is specified to potentially be approximate,
implementations could just return 0 or 1 as count.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200421/f2425f74/attachment.sig>

More information about the Standards mailing list