[Standards] XEP-0174 (Link-Local Messaging): Session initiations

Sjoerd Simons sjoerd at luon.net
Tue Jul 10 12:19:21 UTC 2007


  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

  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

  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:
      <conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams' />

  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 romeo at montague and juliet at capulat 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 ?

Science may someday discover what faith has always known.

More information about the Standards mailing list