[Standards] LAST CALL: XEP-0313 (Message Archive Management)

Georg Lukas georg at op-co.de
Wed Sep 8 09:10:04 UTC 2021


* Dave Cridland <dave at cridland.net> [2021-09-08 10:50]:
[Spoofing of the Forwarded element]
> I can agree with this in principle, though the query id within MAM
> queries dramatically lessens the scope for an attack here.

I'm aware of this point. However, many implementations process stanzas
in callback functions and might not have the query ID as a context, and
furthermore there is no place in 0313 that requires clients to drop
responses that don't match the initial query-id. I think the
yet-to-write security section should contain that requirement as well as
checking for the appropiate from address.

> I'm unconvinced that trying to "fix" XEP-0045's various deficiencies is a
> useful use of what energy we have.

I would be content with not worsening the status quo of 0045 by
introducing things like "your MAM archive might flood your client with
0045 messages without you asking and without any context".

> For persistent groupchat protocols (MUC-SUB, Muclight, MIX) storing
> groupchat messages in the personal archive is very useful indeed.

That's an excellent point. I would suggest documenting the interop of
these protocols with 0313 in the respective protocol specifications, and
changing the wording in 0313 to something like "SHOULD NOT store and return
type=groupchat messages unless defined by a separate specification", but
the second part is implicit in all our XEPs anyway.

> For XEP-0045, it's complicated, sometimes entirely undesirable, and
> sometimes very useful, and usually weird.

Could you further elaborate when specifically it is useful to have?

> How would a "if you didn't specify, we won't either" model go with you?
> That is, we add a flag in the query to specify whether or not
> groupchat messages are included, but we explicitly do not include a default
> value.

This was exactly what I was thinking about. A feature telling clients
that they may ask for type=groupchat / MUC messages, and a query
parameter (even if it's just the <x/> element from MUC) telling the
archive that the client explicitly wishes for MUC message history.


Thanks,

Georg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3204 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20210908/77030601/attachment-0001.bin>


More information about the Standards mailing list