bcp56bis: rich functionality - maybe focus on uri granularity

[mcmanus]

Much of the text of "3.3 Rich Functionality" discusses the merits of granular uris, but in one fell swoop it dismisses post/single-uri pattern as benefiting from only a very short and finite list of features: message framing, and availability of implementations.

I find the former convincing, but the latter dismissal rather unconvincing.. it gives the air of being a complete argument but leaves out a lot of valuable other things even in a mere tunnel case - e.g. proxy support, varied authentication schemes, content negotiation, language negotiation, multiplexing in h2, alt-service routing, coalsecing, and cross-origin policy enforcement in a browser, etc... These are reasonable motivators and you might be underselling the value of high quality available implementations for all aspects of the ecosystem including load balancers.

I wonder if this could be more focused on the merits of URI design rather than saying - if you don't find that a match don't use http.

and the bullet about "The ability to interact with the application easily using a Web browser" might be clarified to mean in a linkable/browsable/discoverable sense rather than excluding a fetch based API for it..

[mnot]

@mcmanus ^^

[mcmanus]

lgtm - thanks