Alexey Melnikov wrote:
[snip]
We see the following requirements:
One prerequisite: when to multiplex? This might be possible both
out-of-band (same ho:po via SRV) and in-band (subject contained in
certificate).
* 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 :-)
* 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.
* Multiplexing shall depend on presentation of a valid digital
certificate for the multiplexed domain.
* The certificate for a multiplexed domain should not be the same
(i.e., have the same subject) as a certificate that has previously been
accepted for the stream; however, if it is the same then it shall
replace the previous certificate with the same subject (e.g., to present
a new certificate with a different expiry time).
PSA: I am not sure why this is a requirement. I think this is a part of
the solution you and Joe have in mind.
Might be alternatively solved by removing the domain and re-adding it
with a new certificate? Domain removal is missing from the list btw.
philipp
