Re: I-D Action: draft-reschke-http-oob-encoding-00.txt

Some quick comments:

- Several: “contans” -> “contains”

- “encrytion” -> “encryption”

- “encryted” -> “encrypted”

- When the key parameter is used, https high enough security should be mandated for the first request. I suggest something like:
“The Encryption-Key Header MUST only be used with https fulfilling at least the requirements in [RFC7540] Section 9.2”.

Cheers,
John


On 21 Jun 2015, at 19:54, Julian Reschke <julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>> wrote:

On 2015-06-04 18:16, Julian Reschke wrote:
FYI -- see below.

This is another proposed building block for a system in which an origin
server would delegate parts of the content delivery to a secondary
server (usually a cache); it's supposed to work together with Martin's
encryption content coding.

Pretty HTML over here:
<http://greenbytes.de/tech/webdav/draft-reschke-http-oob-encoding-latest.html>


Feedback appreciated,

Julian

One thing I'd like to get people to think about is the way both specs stretch the concept of content codings beyond what has been done before:

1) To undo the content coding defined in draft-thomson-http-encryption-00, the recipient will need encryption related information which is not part of the actual payload; it might be out-of-band, or provided in a response header field.

2) To unwrap the content coding defined in draft-reschke-http-oob-encoding, the client will need to do an additional request to a secondary server.

Feedback appreciated,

Julian