Hi,
While refactoring the connection management code in telepaty-salut, we came
accross some issues that we like to clear up.
First we'd like to add to section 7 (Initiating a Messaging Session):
After the recipient sent <stream:features> to the iniator, it MUST wait for
the initiator to send a stanza before sending any other stanza's over the
connection.
Rationale: It might be the case that the initiator wants to negotiate for
example an encrypted/secure session after receiving the <stream:features>. If
the recipient would start sending stanza's immediately, then at least some
stanzas would go over the link unencrypted and probably confuse the
initiators negotiation process.
Waiting on the initiator to send the first stanza would make it immediately
clear whether or not it wants to do further negotiations.
The other thing i want to add is that there should be only _one_ tcp
connection between two contacts. Mainly to ensure that client implementation
don't have to cope with multiple connection and possibly weird semantics as a
result.
First if someone initiates a connection while there is already one, the
recepient MUST send a <stream:error /> with conflict as error condition
instead of sending <stream:features />. Thus for example:
<stream:error>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams' />
</stream:error>
Now with correct implementations this should only happen if both contacts
start connecting to each-other at same time. To break the contention here,
_only_ on the connection where the initiators jid is lexicographical smaller
the recipient MUST send a <stream:error>.
In a simple example: If [EMAIL PROTECTED] and [EMAIL PROTECTED] open a
connection to
eachother at the same time. Then the connection that juliet initiated to
romeo should get a <stream:error /> and gets dropped, while the connection
from romeo to juliet continues normally.
As a side node. Implemenations should take care to also implement this
properly when a existing tcp stream is closing. Thus they shouldn't open new
connection untill either both sides have sent </stream:stream> or the tcp
connection is dropped.
Comments ?
Sjoerd
--
Science may someday discover what faith has always known.
