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

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.

/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