[Standards] secure s2s multiplexing

Philipp Hancke fippo at goodadvice.pages.de
Tue May 5 15:58:01 UTC 2009

Peter Saint-Andre schrieb:
> Hash: SHA1
> On 5/5/09 12:38 AM, Philipp Hancke wrote:
>> Peter Saint-Andre wrote:
>>> Do you mean: when does an application decide that it would like to
>>> request multiplexing for a given domain (rather than opening a new XML
>>> stream)?
>> yes. Rather than opening a new TCP connection actually.
> Correct. Isn't that up to the implementation or deployment?

Server implementors might come up with their own interpretations of
"subdomain" and ignore DNS unless you specify it properly ;-)

>>>>>>>     * The multiplexing method must be backwards-compatible with
>>>>>>> existing
>>>>>>> server-to-server connection methods.
>>>>>>>     * Each party to a server-to-server communication must be able to
>>>>>>> determine if the other party supports multiplexing.
>>>>>> unidirectional or bidirectional s2s for this? For bidi we need a
>>>>>> reverse-stream:features feature anyway.
>>>>> I think this should make the stream bidirectional.
>>>> If it is bidirectional, who can add new domains? But that is probably
>>>> digging too deep already :-)
>>> I would think that either side can add domains (if adding domains has
>>> been negotiated).
>> Might result in race conditions. One way to avoid that is a protocol
>> where one side asks the other side to add the domain. Not that
>> difficult to solve.
> What are the race conditions? I can add sending domains for my side and
> you can add sending domains for your side. Now I suppose that if you try

What about adding receiving domains?
Suppose I have domains A, B and you have X and we already have a
stream established with domains A and X. If the stream is bidirectional,
either of us could decide that he wants to open a "channel" for B,
because I want to send as B or you want me to receive as B (for whatever

> to add foo.com as a sending domain for you, and I try to add foo.com as
> a sending domain for me, we have a problem. But presumably only one of
> us will have appropriate credentials to send for foo.com, at least in
> the typical s2s scenario (things might be different inside a cloud).

You make "cloud" sound like "Pandora's box".


More information about the Standards mailing list