Re: Call for Adoption: Encrypted Content Encoding

+1 one of the few reasons I get pushback against REST in favor of still
using SOAP is because in SOAP you can encrypt the body without encrypting
the headers. This creates the choice of encrypting the body end-to-end
without encrypting the headers. You might argue that a well formed
architecture wouldn't get to that point, but there are already many
architectures that are.

Grahame


On Fri, Dec 4, 2015 at 10:21 AM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

> Without wading into the morass of arguments already rehashed, +1 on
> adopting this.  It doesn't have much stand-alone value, but it's a
> necessary building block in some things that *are* valuable.
>
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: Tuesday, November 24, 2015 8:53 PM
> To: HTTP Working Group <ietf-http-wg@w3.org>
> Subject: Call for Adoption: Encrypted Content Encoding
>
> We've discussed this document a few times:
>  <https://tools.ietf.org/html/draft-thomson-http-encryption>
>
> WEBPUSH now has a normative requirement upon it in
>   <https://tools.ietf.org/html/draft-ietf-webpush-encryption>
>
> So, I believe that we should adopt this document as a WG product, with a
> target of Proposed Standard.
>
> Please comment on-list; we’ll make a decision about adoption at the end of
> next week.
>
> Regards,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>


-- 
-----
http://www.healthintersections.com.au / grahame@healthintersections.com.au
/ +61 411 867 065