Re: [art] Revising BCP56: On the use of HTTP as a Substrate

> On Jul 15, 2017, at 11:20 AM, Adam Roach <adam@nostrum.com> wrote:
> 
> I found 4.3.2 particularly interesting, as there doesn't seem to have been consensus in this space in the past. For example, the ws(s) and ipp(s) schemes made a different decision. I presume your assertion is that, were we defining these protocols today, they would be using http(s) instead?
> 
> I don't see anything wrong with that; I just want to probe the edges of this advice by seeing how it would have applied to decisions we made in the past, since that's a pretty good predictor for how it might apply in the future.
> 
> The advice in 4.3.3 seems a bit strong, in that it will require whatever process listens on port 443 to take on an ever-increasing role. If we're going to keep this advice, I think the document needs some treatment of the software architecture implications: functionally, whatever listens to port 443 will need to be able to delegate sub-trees of the URL space to other processes. I know that some web servers have mechanisms to handle this kind of thing today; but we're effectively saying that this will become required base functionality for web servers moving forward.\
> 
> I wonder, in that context, whether the current advice strikes the right balance.
> 

Also, while I recognize the difference between protocols “using HTTPS” on 443 vs non-HTTPS protocols using 443 for NAT traversal purposes, the recent controversy over CORE's use of 443 suggests that this discussion will need to go beyond ART. At least, I think some TSV and OPS people may have opinions. Maybe those opinions will be “it’s HTTPS, use HTTPS”, but we should verify. (I suspect network management people may have concerns.)

Ben.

> /a
> 
> On 7/11/17 06:14, Mark Nottingham wrote:
>> A number of folks have recently noted that BCP56 addresses the problems of using HTTP for protocols in the early 2000's, but we've moved on considerably since then.
>> 
>> Given the number of IETF protocols being build upon HTTP these days, it seems timely to reconsider it. I've been working on a candidate for replacing it for a little while; see:
>>   https://tools.ietf.org/html/draft-nottingham-bcp56bis
>>   https://mnot.github.io/I-D/bcp56bis/
>> 
>> I have a small-ish slot in the HTTP WG session on Wednesday to discuss this.
>> 
>> Cheers,
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
>> _______________________________________________
>> art mailing list
>> art@ietf.org
>> https://www.ietf.org/mailman/listinfo/art
> 
> 
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art