Joe Hildebrand wrote:
Any reactions to this? This is intended to be instead-of mine-ing, so I
would expect the anti-mine-ing folks to have some reaction one way or
another.
Some comments:
"The receiving server SHOULD NOT modify the 'to' address of the forked
messages."
The receiving server is not entitled to modify that, at least with 3920
behaviour (11.1 rule 4, case 1, must not rewrite).
"and MUST also be sent to all of the Carbons-enabled resources for the
receiving user."
This is for backward compability?
"The 'to' address not matching the JID of the session is somewhat
unprecedented in XMPP,"
s/the JID of the session/"full or bare JID of the user"/ ?
What you mean is that the client gets that stanza and is the intended
recipient even though the JID given in 'to' is neither the clients full
or bare JID? This is a rather drastic reinterpretation of 'to' and
probably deserves a more detailed explanation.
You did not use XEP 0033 for that because that does not work with Chat
State Notifications?
philipp
