[Standards] secure s2s multiplexing

Philipp Hancke fippo at goodadvice.pages.de
Tue May 5 06:38:05 UTC 2009

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.

>>>>>     * 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.

>>>>>     * If the addition of a new domain to an existing domain-to-domain
>>>>> stream fails, the existing stream must not be terminated.
>>>> if the addition of a new domain to an existing stream fails, is it
>>>> allowed to retry after x minutes?
>>> Sure, why not.
>> An alternative would be that a failure is considered permanent -
>> blocking communication with that domain - and the remote end notifies
>> the initiator if this situation changes.
> That puts the burden on the receiver, which seems wrong.

push vs poll... but that approach is flawed anyway. Retry!


More information about the Standards mailing list