RE: WGLC comment on draft-ietf-httpbis-encryption-encoding-03, was: Encryption content coding simplification

Well, I can point at one, though it's not exactly a model of perfect HTTP C-E integration design....  Looking at https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-PCCRTP/[MS-PCCRTP].pdf, there are additional headers that carry the client's parameters (which the server will need if it chooses that coding) and then carry the server's selections back.

Most notable (and probably the worst choice :-) ) is that rather than defining a new C-E value for v2, the parameters include the client's min/max supported versions, and the server tells the client which version it used in a response header.

-----Original Message-----
From: Poul-Henning Kamp [mailto:phk@phk.freebsd.dk] 
Sent: Thursday, October 13, 2016 12:40 AM
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Martin Thomson <martin.thomson@gmail.com>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: WGLC comment on draft-ietf-httpbis-encryption-encoding-03, was: Encryption content coding simplification

--------
In message <49a8c514-5a39-d4f6-7012-01977cbefb9c@gmx.de>, Julian Reschke writes
:

>With that, I actually end up with something similar to one of PHK's
>proposals:
>
>	Content-Encoding: aesgcm, aesgcm
>	CE-params: aesgcm;key="csPJEXBYA5U-Tal9EdJi-w";
>		    salt="NfzOeuV5USPRA-n_9s1Lag",
>                    aesgcm
>
>...where the only difference is that any content coding that *can* have 
>parameters MUST have an associated entry in CE-params.

I have a hard time dreaming up C-E's other than encryption which will require parameters, but I'm all for taking the general approach up front, rather than wait for my limited imagination to be exposed.

+1 from here

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Thursday, 13 October 2016 17:46:38 UTC