[Standards] Added elements (was: Proposed XMPP Extension: Unique and stable message IDs)

Thijs Alkemade thijs at xnyhps.nl
Thu Jun 4 09:38:22 UTC 2015


> On 4 jun. 2015, at 11:26, Matthew Wild <mwild1 at gmail.com> wrote:
> 
> I would probably go for the same approach as the original <archived/>
> element in MAM, and have a 'by' attribute (similar also to <delay/>):
> 
>   <message-id id="1234-0000-...." by="example.com <http://example.com/>" />
> 
> This would also allow clients to use it if they really wanted to, by
> putting their JID in the 'by'.

I fully admit that this is going to sound like an over-engineered solution to
a rare and unimportant problem, but anyway.

Servers adding elements to stanzas is tricky because the client needs to
determine whether it was actually that server that added them, not the sender
or some other server along the line, and I fear clients might mess up that
check. <delay> has the exact same problem.

Your server can't strip out elements that it knows nothing about. But instead
of adding "stripping" support for every new XEP to all servers, how about
making a new, general, XEP to indicate who added elements? For example, adding
a single attribute 'by' in a new namespace:

<delay
   xmlns='urn:xmpp:delay'
   stamp='2002-09-10T23:41:07Z'
   added:by='conference.example.lit'
   xmlns:added='urn:xmpp:added' />

<message-id
   xmlns='urn:xmpp:mid:0'
   id='de305d54-75b4-431b-adb2-eb6b9e546013'
   added:by='muc.capulet.lit'
   xmlns:added='urn:xmpp:added' />

This means the server does not need to know the XEP used to strip those
elements out, it can just remove all elements that have a 'added:by' value
that is "obviously" incorrect. As they are in a new namespace, the original
XEPs don't need to be updated and clients that don't understand this
specification can easily ignore them.

Alternatively, we could give 'from', as it is already used by Delayed
Delivery, extra meaning, (like <required/> in stream features), but I fear
that may have unintended consequences.

Of course this doesn't protect clients from servers maliciously adding,
removing or changing elements, it only protects users from others
impersonating their own server.

Regards,
Thijs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150604/3f354a7c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150604/3f354a7c/attachment.sig>


More information about the Standards mailing list