Compress away IP and Port using Context IDs

[asingh-g]

Closes #13 Closes #14

clients and proxies may omit IP, Port info, if sending data to the same IP and Port as before

Add compression via context IDs, which are to be registered via capsules

Edit: Also, add the ability to suppress any uncompressed traffic

[asingh-g]

@DavidSchinazi fair point. Should we create another target identifier different from context-ID?

[DavidSchinazi]

I don't think we need to, we can use the context identifiers to indicate the compression. We just need a process to register context IDs so both peers agree on what they mean. A capsule would probably be the best bet here

[asingh-g]

I agree. I have changed the draft, to make it so that we use capsules to enable compression. Please let me know what you think @DavidSchinazi and @tfpauly

[asingh-g]

I remember @tfpauly 's suggestion at IETF about an option to close arbitrary forwarding from the proxy to the client which I think is a great idea and is a decent alternative over adding a permissions mechanism.

I'm thinking we can use the existing compression request capsule by adding an optional field to communicate this option from the client to the proxy

Something like

Capsule:{
TYPE= COMPRESSION_REQUEST,
.
.
.
 disable-uncompressed-forwarding= true,
}

I've added it to the last pushed commit, let me know your thoughts on it

[DavidSchinazi]

Instead of adding a disable-uncompressed-forwarding bool to every COMPRESSION_REQUEST, it would be simpler and more efficient to instead add a COMPRESSION_CLOSE capsule. That would add the new feature of being able to drop compression state that's no longer used, with the benefit of solving this for free - one can disable uncompressed forwarding by sending a COMPRESSION_CLOSE for the uncompressed context ID.

[asingh-g]

As discussed, I've added the COMPRESSION_REJECT and COMPRESSION_CLOSE capsules. I've removed the disable-uncompressed-forwarding field