Re: something I don't get about the current plan...

there are other cases where encryption is a problem.

One that comes to mind is software updaters.  E.g. if you have an 
updater in your software, which uses http, you might want it to be 
visible what is going on, so that your software can't be accused of 
being spyware when really you're just checking for an update.

It's trivial to demonstrate what is being transmitted if it's plain 
text.  Impossible if not.  These systems commonly use OS-provided 
systems (e.g. WinInet), and work over the internet, so that if the 
mechanism is changed out underneath it would be a problem.

I'm sure there are other systems where openness is a distinct 
requirement.


------ Original Message ------
From: "Mark Nottingham" <mnot@mnot.net>
To: "James M Snell" <jasnell@gmail.com>
Cc: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>; "ietf-http-wg@w3.org 
Group" <ietf-http-wg@w3.org>
Sent: 18/11/2013 5:22:36 p.m.
Subject: Re: something I don't get about the current plan...
>
>On 18/11/2013, at 3:19 PM, James M Snell <jasnell@gmail.com> wrote:
>
>>  I'm good with this if, and only if, we also take the step of defining
>>  a separate default port for plaintext http/2 for all other cases.
>
>"all other cases" being...?
>
>At this point in time, I'm looking at this through the lens of 
><https://github.com/http2/http2-spec/issues/314> -- i.e., what we say, 
>if anything, about browsers on the "open" Web.
>
>There are a lot of interdependencies on other things, but I'm not sure 
>I get what's motivating this one for you.
>
>Cheers,
>
>
>P.S. The resolution to that issue *could* come in the form of a 
>separate document, not anything in HTTP/2 itself. E.g., a "how browsers 
>use HTTP" RFC.
>
>
>--
>Mark Nottingham http://www.mnot.net/
>
>
>
>

Received on Monday, 18 November 2013 04:32:41 UTC