Eric,
>>> However, for ease of implementation, a
>>> +server MAY close the connection rather than entering transmission
>>> +phase if, at the end of option haggling, the client has negotiated
>>> +another command that requires a structured reply but did not also
>>> +negotiate Stru
On 03/30/2016 12:50 AM, Alex Bligh wrote:
> Eric,
>
> There's a lot in common between our two proposals now (unsurprisingly).
> You've highlighted the differences in the other mail and I'll
> comment on them there. You may want to steal some of my wording as
> I think there are bits I've got that
Eric,
There's a lot in common between our two proposals now (unsurprisingly).
You've highlighted the differences in the other mail and I'll
comment on them there. You may want to steal some of my wording as
I think there are bits I've got that you haven't (as well as vice versa).
But I'm inclined
On 03/29/2016 05:01 PM, Eric Blake wrote:
> The existing transmission phase protocol is difficult to sniff,
> because correct interpretation of the server stream requires
> context from the client stream (or risks false positives if
> data payloads happen to contain the protocol magic numbers). It
The existing transmission phase protocol is difficult to sniff,
because correct interpretation of the server stream requires
context from the client stream (or risks false positives if
data payloads happen to contain the protocol magic numbers). It
also prohibits the ability to do efficient sparse
