[Standards] NEW: XEP-0409 (IM Routing-NG)

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


Section 3.3:

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

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.

Two reasons:

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

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 
xsf@:

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

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
    user.
  - CSN would become such a use-case where <transient/> is mandatory on
    the stanzas.

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

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.



---


kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180608/baa3f357/attachment.sig>


More information about the Standards mailing list