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

Daniel Gultsch daniel at gultsch.de
Wed Jan 20 19:05:19 UTC 2016

Hi Thijs,

2016-01-20 19:36 GMT+01:00 Thijs Alkemade <me at thijsalkema.de>:

> I sent a proposal for that back in June [1], but that didn't receive a lot
> of
> responses, just Kev noting that namespaced attributes aren't very common in
> XMPP [2].
> There are alternatives to using a namespaced attribute, but I fear those
> won't
> be backwards compatible. Unless there are implementations out there that
> have
> major problems working with namespaced attributes, I don't think we should
> avoid them just for being rare.
> Regards,
> Thijs
> [1] = http://mail.jabber.org/pipermail/standards/2015-June/029847.html
> [2] = http://mail.jabber.org/pipermail/standards/2015-October/030514.html

yeah too bad that this didn't get any attention. I kinda missed that
myself. That's probably not an easy topic to grasp if you never thought
about it before.
Never the less this problem needs a solution and I actually belief it's
careless to just update XEPs like this.

I had a quick off-list discussion about this and for most scenarios  might
have individual solutions available. In this MAM case this could have been
solved by a namespace bump and the requirement for servers to sanitize
those elements.

In case of a server injecting stanza-ids it could probably be solved by
having the server announce the stanza-id namespace in its disco and thus
indicating that it is sanitizing all stanza-ids.

Like you mentioned using an un-namespaced from or by attribute can lead to
some weird consequences.

What ever we agree on we should come up with a solution rather sooner than
later. Because having the server inject information like the original
sender in this case or stanza-ids in another is certainly something
desirable. But without the added security practically worthless.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160120/8efbf751/attachment.html>

More information about the Standards mailing list