Re: RFC1918 + localhost

I don't see how that follows from the statement above.
However, given that we can't force people to deploy anything, sticking to
HTTP/1 will always be an option for people who don't like HTTP/2 for
whatever reasons.
-=R


On Tue, Nov 19, 2013 at 2:02 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:

> On Tue, Nov 19, 2013 at 2:28 PM, Roberto Peon <grmocg@gmail.com> wrote:
> > But in many ways we don't have choice today.
> > If you are advocating for choice where both the client and any entity the
> > client connects to explicitly (potentially a proxy) can opt-in or
> opt-out of
> > encryption, then I'm with you.
> > If you are advocating for choice where the user and connected-entity get
> no
> > say in the matter, then I'm firmly in the not-interested camp.
>
> So you would rather leave them in the HTTP/1 world?
>
> >
> > -=R
> >
> >
> > On Tue, Nov 19, 2013 at 12:24 PM, Adrien de Croy <adrien@qbik.com>
> wrote:
> >>
> >>
> >>
> >> ------ Original Message ------
> >> From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
> >> To: "Adrien de Croy" <adrien@qbik.com>
> >> Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
> >> Sent: 20/11/2013 9:20:59 a.m.
> >> Subject: Re: RFC1918 + localhost
> >>>
> >>> In message <em8b9ccf82-905d-4929-8c41-41362b024e61@bodybag>, "Adrien
> de
> >>> Croy" w
> >>> rites:
> >>>
> >>>> we need to forget about using this as a demarcation for allowability
> of
> >>>> plaintext or not.
> >>>
> >>>
> >>> I'd say we need to stop this charade about us being in a position
> >>> to tell people where and when they can use plaintext...
> >>>
> >>> Are you really trying to reintroduce TLS with "NULL" crypto again ?
> >>
> >>
> >> Me?  no, nor did I ever.  That would be a waste of RTTs.
> >>
> >> I'm advocating choice.  Like we currently have.
> >>
> >>
> >>>
> >>> --
> >>> 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.
> >>
> >>
> >>
> >
>