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

Kevin Smith kevin.smith at isode.com
Tue Oct 20 14:33:09 UTC 2015

On 4 Jun 2015, at 10:38, Thijs Alkemade <thijs at xnyhps.nl> wrote:
>> 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" />
>> 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.

Rare, but not unimportant, probably.

> 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.

There might be merit in this. Although namespaced attributes are not particularly common in XMPP.


> 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

More information about the Standards mailing list