W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: I revised the pro/contra document

From: Eliot Lear <lear@cisco.com>
Date: Mon, 25 Nov 2013 07:39:18 +0100
Message-ID: <5292F096.2030505@cisco.com>
To: Tim Bray <tbray@textuality.com>, Mike Bishop <Michael.Bishop@microsoft.com>
CC: Alexandre Anzala-Yamajako <anzalaya@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Tim,

On 11/23/13 11:07 PM, Tim Bray wrote:
> I’m just enumerating the arguments that have been expressed a
> critical-mass number of times on-list.  I personally think the notion
> that you don’t need to encrypt media files is completely wrong, but it
> has been repeatedly asserted.

The point is- this is other people's money you're talking about. 
Consider a large producer of such media content who derives no benefit
from the additional encryption.  Why would they deploy TLS?  There may
be those who produce similar media content who decide they WANT TLS. 
But it's their choice.

As to home printers, it's not that encryption is the problem- it's that
generating a valid cert in those environments is hard.

And as to Mike's statement:

> I doubt you would bother to install a valid certificate; you'd just
> use a self-signed cert or something, and because you've said you don't
> care about it, you'd ignore the warnings.

This is precisely the behavior you don't want to encourage, not to
mention it may not even work at all because of a lack of UI (this is one
generates a lot of broken software behavior).

A reasonable answer to all of this is for printers to stick with
HTTP/1.1.  Another reasonable approach would be to develop specific
solutions for this use case.  THAT is an area where some sort of "OE"
might in fact be appropriate.  But we don't have to do all of this at
once, and one design consideration I'd suggest we consider is that we
have appropriate hooks – if at all possible (and it may not be) – to
deal with some of this stuff later.

Eliot
Received on Monday, 25 November 2013 06:39:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC