[Standards] mutual authentication and XEP 178

Peter Saint-Andre stpeter at jabber.org
Sun Jul 22 20:33:58 UTC 2007


Peter Saint-Andre wrote:
> Justin Karneges wrote:
>> On Wednesday 18 July 2007 12:31 pm, Peter Saint-Andre wrote:
>>> Server1 realizes that it needs an XML stream to Server2 in order to
>>> route some stanzas. So Server1 completes address resolution via SRV or
>>> whatever and opens a TCP connection to Server2. That happens on
>>> TCPconn1. Then Server1 sends a stream header to Server2. So far so good.
>>>
>>> RFC3920 says that for s2s there are 2 TCP connections. So in order to
>>> send a response stream header to Server1, I assume that Server2 opens a
>>> second TCP connection, which we'll call TCPconn2, and then sends the
>>> response stream header over TCPconn2.
>>>
>>> Correct?
>> Absolutely not. :)
>>
>>> I don't know if the spec needs to talk about this, but it couldn't hurt
>>> (since it's different for c2s vs. s2s).
>> It's the same.  One XML document for each direction in the TCP connection.  
>> However, with s2s, only the initiator of a TCP connection can send stanzas 
>> (e.g. 'message', 'presence', and 'iq').
> 
> I'll have to do some research on this so that I can specify it correctly. :)

I woke up at 3:30 this morning and realized that my previous email was
horribly wrong.

An XML stream always goes in one direction, it's just that in the c2s
case both streams go over the same TCP connection, whereas in the s2s
case there are two TCP connections. However, as Justin says, the
directionality matters only for the sending of stanzas, not for the
sending of XML elements that are used to establish the stream. I'll
clarify this in the -04 version of rfc3920bis, and will post to the list
once I have proposed text.

/psa


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070722/91338204/attachment.bin>


More information about the Standards mailing list