On 4 Jun 2015, at 10:38, Thijs Alkemade <[email protected]> wrote: > > >> 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" /> >> >> 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. /K > > 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 >
