[Standards] NEW: XEP-0409 (IM Routing-NG)
jonas at wielicki.name
Fri Jun 8 11:42:57 UTC 2018
So here comes my feedback to this.
> URL: https://xmpp.org/extensions/xep-0409.html
First of all, I like how this worked out. I think the compatibility between
IM-NG and non-IM-NG realms is well-addressed. Kevin really did some good work
distilling the lengthy discussion we had in the weeks around summit about this
topic to a good base specification.
> When an entity wants to send a non-error message to be received exclusively
> by a single resource, they include an <im-ng xmlns='urn:xmpp:im-ng:0'>
> element in the message. An IM-NG server receiving this MUST then send it to
> only the specified resource, if available, or respond with an error
> consistent with RFC-6121 ("return an error stanza to the sender, which
> SHOULD be <service-unavailable/>").
Is there a specific reason why a client which has enabled IM-NG needs to
include the <im-ng/> element? I’d prefer if the server would tack it on any
full-JID-addressed message it receives from the client (just like it stamps
over the @from). Simple clients and so on.
On a similar point in Section 4:
> An IM-NG client SHOULD ignore any IM-related messages that are sent to a
> full-JID with an <im-ng xmlns='urn:xmpp:im-ng:0'> element (see Security
This could be a SHOULD for servers too. Prevents sending them to clients in
the first place. Servers could even reject them with <bad-request/> or
something similar to give feedback.
Again Section 4:
> In order for interoperability with other entities (contacts, remote servers
> etc.) that don't support IM-NG, old-style full-JID messages also need to be
> handled. When a server receives a message with type other than than
> 'groupchat' or 'headline' that does not contain an <im-ng
> xmlns='urn:xmpp:im-ng:0'> element it is to be routed by the above rules as
> if they were sent to the bare JID
Is there any reason to not also re-write the message to look as if it came
from IM-NG? I.e. make the destination JID bare.
More section 4:
> Any message of normal type, or type 'chat', 'groupchat' or 'headline' sent
> to a bare JID is distributed to all IM-NG clients (error messages sent to
> the bare JID are in response to server-generated stanzas, and so are not
> routed to clients).
I would suggest to simplify the wording here, to something along the lines of:
| Any message which is not of type 'error' sent to a bare JID is distributed
| to all IM-NG clients. Messages of type 'error' sent to a bare JID are in
| response to messages sent by the service and so are not routed to clients.
- I think this is much easier to read -- with the original version, I first
had to look up if this covers all message types or not.
- RFC 6121 defines that unknown message types are to be treated like 'normal',
so if we ever extend message types, this provides defined behaviour in that
case which is in line with RFC 6121 (I am only a bit serious with this reason;
the first one is the important one).
More section 4:
> When reflecting an IM-NG client's outbound bare-JID messages, the server
> SHOULD reflect the archived version (i.e. after any transforms have taken
This is a good start. I would suggest to amend it with:
| Specifically, if MAM is supported, the server MUST include the archive
| <stanza-id/> on the reflected message.
And I also put some minute-style notes from discussion which took place in
Archiving Chat State Notifications: As per the current rules, chat states are
archived (because they’re not headline and not groupchat (typically)). Georg
mentions that this is a problem because of the high load on databases this
Kevin mentions three independent solutions:
- Chat State Notifications should move into <presence/>, as discussed at
summit. I raised the point that we might need to look carefully at the uses of
directed presence and how things (e.g. MUC, Invisible Command and possibly
others) interact with clients sending directed presence all the time. (It
would be directed presence because you’d send the CSN to the contact/chat/room
whom it concerns.)
- We could specify a <transient/> hint which would work roughly like <no-
store/> except that:
- It is specified in IM-NG.
- Servers MUST NOT archive anything with <transient/>
- Clients MUST ignore/reject anything with <transient/> which is not
supposed to be transient. I.e. if they receive any stanza with any
payload where the specification doesn’t say that it should be
transient, the client drops it. The effect of that is that the client
behaves as if it had been offline when the stanza was received
(since it’s not going to be archived). This prevents an attacker from
maliciously making stanzas not archived while still being shown to the
- CSN would become such a use-case where <transient/> is mandatory on
- We requisition type='headline' messages for this purpose. Kevin thinks that
this might be even more dangerous than the other two options (but doesn’t
I think we should do the second thing (<transient/> in IM-NG) in any case,
because it seems simple enough to implement on both client and server and
opens us a well-specified loophole down the road which might be very useful.
The loophole can only be watertight if we specify it right away.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards