Hi, To start a link-local conversation with XEP-0174 between two clients, any of the 2 clients can initiate the stream. If the 2 contacts start to chat at the same time, we may have 2 streams initiated in both directions. It seems this case does not happen often because users usually don't start to chat precisely at the same time.
You suggested that having several streams between 2 clients was not a problem: Le Thu, 14 Aug 2008 10:51:06 -0600, Peter Saint-Andre <[EMAIL PROTECTED]> a écrit : > Alban Crequy wrote: > > If we want the XEP to say there can be only one stream between two > > clients, we should define the correct behaviour when two clients > > initiate a TCP connection to each other at the same time. Do we > > want one connection to win and the second to be closed? > > I don't think we need to restrict clients to one stream at a time. However, if the 2 clients both implement XEP-030 Service Discovery and XEP-0115 Entity Capabilities, they will both initiate a stream in order to send a discovery request as soon as they appear online via DNS-SD, without user intervention. Do we want this to happen? Sjoerd suggested on IRC to add random slack time before initiating a stream to avoid it. XEP-0174 can spec some guide-lines. Either how to avoid it, or spec that implementations MUST handle several streams correctly. Should statefull stanza (iq requests/replies) always use the same stream, if there is several streams? When a stream is closed because a timeout is reached, can we open a new stream to send the <iq type="result"> corresponding to the <iq type="get"> from the previous stream? When someone joins a local network, we may receive plenty of TCP connections from local contacts. The XEP-00174 suggests that the implementation can wait user approval before accepting to open the stream: XEP-0174: > Your client then responds with a response stream header (perhaps > subject to user approval -- it's not always safe to chat with > strangers!). It seems undesirable to ask user approval just to send contact capabilities. -- Alban
