> On 4 jun. 2015, at 11:26, Matthew Wild <[email protected]> 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to