this came up while I pondered on using <message/> instead of <iq/> for
jingle... but I think the problem is a more general one.
definitions first:
caps: xep-0115
caps based architecture: only offer things (in the UI) to the user
after you know via caps that they support it
forking: delivering a message sent to the bare jid to all connected
resources
The concrete scenario i am looking at is 'forking' jingle calls to all
interested resources. Let's assume I have presence... otherwise, using
<message/> is the last resort.
Further, I assume we have a disco#info and therefore a capability for
the hypothetical jingle-using-message xep.
So, if I have two resources implementing both jingle-using-iq and
-message and one that only implements jingle-using-iq...
should a client that wants to initiate a jingle session use <message/>
(because more than one client supports this)
or use the traditional strategy (highest priority resource that supports
jingle)?
I do think that using <message/> and carbons for jingle and multi-device
synchronization is the way to go. But it MUST be integrated into caps.
Thoughts?
There is another issue with <message/> vs <iq/> -- if you receive a
<message type=error/> this doesn't necessarily mean that whatever you
tried did not work. Only if this error comes from the bare jid.
