Vinod Panicker wrote:
On 7/29/05, Justin Karneges <[EMAIL PROTECTED]> wrote:
On Friday 29 July 2005 01:56 am, Vinod Panicker wrote:
I was stating that the RFC is silent about stanza communications
starting as soon as one connection is successful, before the
complementary connection has been established.
Good point, it could be interpretted that you must have both connections
established even if you are only sending in one direction.
Do I need to inform anyone specifically to get this added into the
next version of the RFC or assume that it would be done?
I maintain a page of notes about potential changes to the XMPP RFCs:
http://www.xmpp.org/xmppbis.html
There is no guarantee that any of those changes will be made when the
[email protected] list discusses rfc3920bis and rfc3921bis (which it
won't until I submit the relevant Internet-Drafts, perhaps later this
year or early next year), since any changes will be the result of list
consensus rather than executive fiat. However, I will add a link from
that page to this email thread so that we have a pointer and some
context for the discussion.
Failed s2s connections can happen at any time, SASL or not. I don't
think a failed inbound s2s connection should have any effect on
established s2s connections. So in your example you'd be stuck with a
one-way channel.
Any recommendations / standard practices on what to do in case of a
situation like this?
Do nothing? I'm pretty sure that's what all the existing servers do today.
So can we safely state that if server A needs to send a stanza to
server B, there is no need for server B to establish a connection to
server A unless in the case of an error?
Well, in most cases, bidirectional communications are desired, but yes,
if you just want a uni-directional channel, you would not need to set up
the return channel.
Peter
--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml
_______________________________________________
jdev mailing list
[email protected]
http://mail.jabber.org/mailman/listinfo/jdev
