[Standards] capabilities vs message "forking"

Philipp Hancke fippo at goodadvice.pages.de
Wed Aug 21 19:33:09 UTC 2013


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.



More information about the Standards mailing list