Re: [arch-d] deprecating Postel's principle

Re: [arch-d] deprecating Postel's principle - considered harmful

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 10 May 2019 22:20 UTC

MIME-Version: 1.0
References: <4255f805-9d9e-10a0-e6be-309779a33d26@network-heretics.com> <CAMm+LwgrVQtjLuwCyeyFpEzNzLwnYhoMjc0POdZSE8MwtetioA@mail.gmail.com> <20190510214417.GY21049@localhost>
In-Reply-To: <20190510214417.GY21049@localhost>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 10 May 2019 18:20:45 -0400
Message-ID: <CAMm+LwgXPzF0K08jN2y4yY+Uv1879vU1PxJTOoa9y4Jhu5G_Cg@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Keith Moore <moore@network-heretics.com>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f03d6005888ffa1e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/4iSMfhqtzMmrYWCgU9emqhcg-ck>
Subject: Re: [arch-d] deprecating Postel's principle - considered harmful
Precedence: list

On Fri, May 10, 2019 at 5:44 PM Nico Williams <nico@cryptonector.com> wrote:

> On Fri, May 10, 2019 at 04:47:34PM -0400, Phillip Hallam-Baker wrote:
> > On Thu, May 9, 2019 at 10:00 PM Keith Moore <moore@network-heretics.com>
> > wrote:
> > > p.s.  I've often said that "the web" was optimized for deployability.
> > > [...]
> > >
> >
> > Damn right it was. Deployability was the primary consideration. We did
> not
> > use SGML because any of us liked it or considered it to be a solid
> > technical specification. We hated it and we though it was crap. The
> reason
> > we went there was that we needed buy-in from the publishing world.
> >
> > But equally importantly, we broke a lot of what people thought were the
> > rules. I knew that there wasn't a Content-Length header in MIME when I
> > added it to the HTTP spec and so did Tim. But we pretended it did because
> > we needed to make the POST method work and we were not going to introduce
> > mandatory content body framing or SMTP type escaping.
>
> Thankfully you did add chunked transfer-encoding.
>

Chunked came after keep alive which I proposed at the first Web Conference
together with a different chunking and was told it wasn't needed. Then
people started going heavy on images and TCP teardowns started to be the
limiting issue.

Is that so?  Caching proxies merely need to become MITM proxies.  Those
> exist, and in many corporate environments that require web access and
> data loss protection (DLP), they must exist.  I know because I use one,
> and also I maintain one (though the one I maintain is not a caching
> proxy).  Middleboxen will be with us forever.
>

Of course. The part that is going away though is the part we were focused
on in 1994-1996 because the Internet was melting under the load.

MITM proxies introduce their own horrors and they are an example of the
cost of trying to remain principled in an unprincipled world. We could do
MITM in a much better way than we have ended up with. But we can't come to
consensus on a protocol of that sort.

Re: [arch-d] deprecating Postel's principle - con… Keith Moore
Re: [arch-d] deprecating Postel's principle - con… Phillip Hallam-Baker
Re: [arch-d] deprecating Postel's principle - con… Nico Williams
Re: [arch-d] caches, was deprecating Postel's pri… John Levine
Re: [arch-d] deprecating Postel's principle - con… Phillip Hallam-Baker
Re: [arch-d] deprecating Postel's principle - con… Nico Williams