reserved flags and extensions

Hi,

it has been suggested several times that future extensions could change
the framing. Reserved flags are marked as "must be sent as zero" and "must
be ignored on receipt". However, if some intermediary is designed to only
inspect contents and relay frames as-is (think an anti-virus or so which
only cares about data and ignores everything else), it might very well
end up desynchronized when future extensions affecting the framing are
negociated between the client and the server and it ignores them. This
is exactly the issue TCP has long been facing with window scaling and
middle firewalls which did not support it and would block supposedly
out-of-window packets.

It would be sad to discover 1 year after the protocol is released that
we cannot update the framing to benefit from the wider experience in
field, just because of some dumb components breaking the net again.

And the problem of extensions is that nobody is required to know them in
advance, so nobody knows in advance if leaving them enabled can cause some
breakage or is desirable.

One radical solution to this I'm seeing is to explicitly require that
any unknown extension must be removed from the settings frames by these
"dumb" intermediaries designed to forward everything. This might not be
the easiest thing for them, and would lead to other useful extensions to
be removed.

Another solution would help dumber intermediaries and would avoid getting
rid of all extensions : we can define *right now* that one of the reserved
bits will indicate "alternate framing settings present" and that all
extensions which affect the framing rely on this bit to be set. That way,
the dumber intermediaries which are not capable of updating the settings
could simply clear this bit and force the communication to fall back to
the legacy specification, and the recipient will simply ignore these
extensions.

The last option I'm seeing is to leave things as they are right now and
to add a specific paragraph in the spec for those dumb intermediaries
which we could call "frame sniffers" or so, and indicate what the absolute
minimal amount of processing can be : you can forward everything as-is
but you MUST at least clear all reserved bits [list here].

What do you think ?
Willy

Received on Sunday, 13 July 2014 06:06:32 UTC