Subject: Call For Adoption HTTPbis BCP56bis

From: Patrick McManus <[email-masked]>
Date: Wed, 11 Oct 2017 13:51:06 -0400

Folks, I'm going to open up a 2 week call for adoption period to see if the
group has consensus for adopting work on a bis version of BCP56 (aka RFC
3205; On the use of HTTP as a Substrate).

Mark introduced this work both on the general ART list and with a
presentation at IETF 99.

His draft, which is the subject of the adoption call, can be found
https://mnot.github.io/I-D/bcp56bis/

The ART discussion is archived here:
https://www.ietf.org/mail-archive/web/art/current/msg00303.html

The presentation at IETF 99 is here:
https://datatracker.ietf.org/meeting/99/materials/slides-99-httpbis-sessb-bcp56bis/
(That's a pdf - trust your content-types!)

The minutes from IETF 99 are here:
https://tools.ietf.org/wg/httpbis/minutes?item=minutes-99-httpbis-00.html

Personally, I think this is an important document to update, and
contemporaneous efforts like JMAP and DOH illustrate the relevancy.

We'll leave the CfA open until October 27. I'm looking for arguments pro or
con and especially expressions of interest in collaborating and reviewing
the document. Thanks. Please weigh in.

-Patrick

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Oct 2017 08:49:44 +1100

Adopt.

BCP 56 hasn't just been overtaken by events, it's reached the point
where it is an active hazard.  I'm glad that Mark started this effort.
I definitely think that this is worth doing.

I have some reservations about some of the document as proposed; the
advice on using HTTP is excellent, but I don't think that the framing
works especially well.  It's too close to the original BCP 56 text.
In particular, the introduction seems to make it clear that there is
more choice and flexibility in terms of how much of HTTP can be used,
where the document later mandates a clear cut: either use it properly
or define a new protocol entirely (aka protocols based on HTTP).  I'd
like to see this reframed.  I'd also like to see a little more text on
the "protocols based on HTTP" part.  At least to the point that the
reader is able to gain a better appreciation for how awful that choice
truly is.

Of course, that's just from a brief read.  Adopting the work is a good
way to get started on fixing those sorts of things.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 12 Oct 2017 04:21:05 +0200

Hi Patrick,

> the document. Thanks. Please weigh in.

I wasn't aware of this doc and it's really nice and an important piece in the
puzzle. I support adoption as well. I'm often explaining to people who do
whatever with HTTP that they're probably using HTTP as an alternative to TCP
because it supports meta-data, states and proxying but that it's not a reason
for reinventing their own variation of the protocol otherwise they lose all
the benefits. At least now we have a doc listing such bad practices an
explaining how to use the protocol correctly.

Thanks,
Willy

---

From: Michael Sweet <[email-masked]>
Date: Thu, 12 Oct 2017 08:57:08 -0400

Pro

I also think we should do more to highlight existing (good/bad) uses of HTTP as the substrate/transport (IPP, CoAP, etc.) and to make specific recommendations about implementing authentication and access control (including the use of Expect: 100-continue in POST requests).

Particularly for IPP, we have 20 years of implementation experience with billions of printers - there have definitely been some bumps in the road and some implementers still grumble about using HTTP, but HTTP has served us well and allowed us to grow and adapt.

> On Oct 11, 2017, at 1:51 PM, Patrick McManus <[email-masked]> wrote:
> 
> Folks, I'm going to open up a 2 week call for adoption period to see if the group has consensus for adopting work on a bis version of BCP56 (aka RFC 3205; On the use of HTTP as a Substrate).
> 
> Mark introduced this work both on the general ART list and with a presentation at IETF 99.
> 
> His draft, which is the subject of the adoption call, can be found https://mnot.github.io/I-D/bcp56bis/
> 
> The ART discussion is archived here: https://www.ietf.org/mail-archive/web/art/current/msg00303.html
> 
> https://datatracker.ietf.org/meeting/99/materials/slides-99-httpbis-sessb-bcp56bis/ (That's a pdf - trust your content-types!)
> 
> The minutes from IETF 99 are here: https://tools.ietf.org/wg/httpbis/minutes?item=minutes-99-httpbis-00.html
> 
> Personally, I think this is an important document to update, and contemporaneous efforts like JMAP and DOH illustrate the relevancy.
> 
> We'll leave the CfA open until October 27. I'm looking for arguments pro or con and especially expressions of interest in collaborating and reviewing the document. Thanks. Please weigh in.
> 
> -Patrick
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: Mike Bishop <[email-masked]>
Date: Thu, 12 Oct 2017 17:41:42 +0000

+1 on all of this.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2017 2:50 PM
To: Patrick McManus <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: Call For Adoption HTTPbis BCP56bis

Adopt.

BCP 56 hasn't just been overtaken by events, it's reached the point where it is an active hazard.  I'm glad that Mark started this effort.
I definitely think that this is worth doing.

I have some reservations about some of the document as proposed; the advice on using HTTP is excellent, but I don't think that the framing works especially well.  It's too close to the original BCP 56 text.
In particular, the introduction seems to make it clear that there is more choice and flexibility in terms of how much of HTTP can be used, where the document later mandates a clear cut: either use it properly or define a new protocol entirely (aka protocols based on HTTP).  I'd like to see this reframed.  I'd also like to see a little more text on the "protocols based on HTTP" part.  At least to the point that the reader is able to gain a better appreciation for how awful that choice truly is.

Of course, that's just from a brief read.  Adopting the work is a good way to get started on fixing those sorts of things.

On Thu, Oct 12, 2017 at 4:51 AM, Patrick McManus <[email-masked]> wrote:
> Folks, I'm going to open up a 2 week call for adoption period to see 
> if the group has consensus for adopting work on a bis version of BCP56 
> (aka RFC 3205; On the use of HTTP as a Substrate).
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmnot.
> github.io%2FI-D%2Fbcp56bis%2F&data=02%7C01%7CMichael.Bishop%40microsof
> t.com%7C4e5f1f43e0db4a75a22208d510f279ca%7C72f988bf86f141af91ab2d7cd01
> 1db47%7C1%7C0%7C636433555965286760&sdata=9J%2FgUGV5QUF0bfEqrsxQxx5OwNR
> jq2rQLzZkwZwnVcg%3D&reserved=0
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmail-archive%2Fweb%2Fart%2Fcurrent%2Fmsg00303.html&data=02%7
> C01%7CMichael.Bishop%40microsoft.com%7C4e5f1f43e0db4a75a22208d510f279c
> a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636433555965286760&sdat
> a=9du2%2FfGsyAXM6e31G25SIqDHRVew9COwXBWeHVVCYTM%3D&reserved=0
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fmeeting%2F99%2Fmaterials%2Fslides-99-httpbis-sessb-b
> cp56bis%2F&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C4e5f1f43e0d
> b4a75a22208d510f279ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636
> 433555965286760&sdata=t8xE4hA8yVqZW%2BSTtBWHGphUzyHuYi2YtCN1xlcco5A%3D
> &reserved=0 (That's a pdf - trust your content-types!)
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools
> .ietf.org%2Fwg%2Fhttpbis%2Fminutes%3Fitem%3Dminutes-99-httpbis-00.html
> &data=02%7C01%7CMichael.Bishop%40microsoft.com%7C4e5f1f43e0db4a75a2220
> 8d510f279ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364335559652
> 86760&sdata=XeE4F8fSBqL3URkgQaCNIXMdSUD7OXlOwMJaIm9Gtu0%3D&reserved=0
>
> We'll leave the CfA open until October 27. I'm looking for arguments 
> pro or con and especially expressions of interest in collaborating and 
> reviewing the document. Thanks. Please weigh in.
>
> -Patrick
>

---

From: [email-masked]
Date: Thu, 12 Oct 2017 20:15:56 +0200 (CEST)

Hi,

I'd say that 4.3.3. Transport Ports is overly lax and outdated.

One would be most insane to rely on transport ports to distinguish application’s traffic for operational reasons nowadays. It's just too easy for Joe random developper (or Bill random hacker) to squat any given port with something else, vendors always think you should only buy their stuff so it's not a problem if they reuse the competitor's port for something else, all of them feel 8080, 9443 or variations on those is completely innovative with no collision risk and so on.

Relying on special ports only works in strongly controlled networks. But if you control the network to this level, you can use specific DNS rules, separate VLans or IP ranges without breaking all the HTTP(s) infrastructure by switching ports.

Regards,

-- 
Nicolas Mailhot

---

From: Leif Hedstrom <[email-masked]>
Date: Fri, 13 Oct 2017 11:03:09 -0600

> On Oct 11, 2017, at 11:51 AM, Patrick McManus <[email-masked]> wrote:
> 
> His draft, which is the subject of the adoption call, can be found https://mnot.github.io/I-D/bcp56bis/ <https://mnot.github.io/I-D/bcp56bis/>
> 
> The ART discussion is archived here: https://www.ietf.org/mail-archive/web/art/current/msg00303.html <https://www.ietf.org/mail-archive/web/art/current/msg00303.html>
> 
> https://datatracker.ietf.org/meeting/99/materials/slides-99-httpbis-sessb-bcp56bis/ <https://datatracker.ietf.org/meeting/99/materials/slides-99-httpbis-sessb-bcp56bis/> (That's a pdf - trust your content-types!)
> 
> The minutes from IETF 99 are here: https://tools.ietf.org/wg/httpbis/minutes?item=minutes-99-httpbis-00.html <https://tools.ietf.org/wg/httpbis/minutes?item=minutes-99-httpbis-00.html>

Absolutely agree. It’s an important, but somewhat outdated, document. We should adopt this, and make it reflect current best practices and protocol improvements.

Cheers,

— Leif