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

[Dave Thaler <[e-mail]>]

I think 4.3.2 is problematic as currently worded.  For example,
> Using other schemes to denote an application using HTTP makes it more
>  difficult to use with existing implementations (e.g., Web browsers),
>   and is likely to fail to meet the requirements of [RFC7595].

The "URI Schemes and Web Protocols" document Henry pointed to argues for separate URI schemes
for different protocols (ftp, http, coap, etc.), e.g. "G4. Serve using the protocol associated with the URI scheme".

I think the "HTTP as a Substrate" document is worded as if the only protocol an app supports is HTTP,
which is not the case.   If an application defines higher layer semantics where HTTP and something else
can both be used as transports (the topic of draft-thaler-appsawg-multi-transport-uris discussion),
than 4.3.2 would imply that one must use multiple URIs for the same transport, rather than having
one higher-layer URI for the application-layer protocol or semantics.

http://www.w3.org/TR/webarch/#uri-aliases discusses multiple URIs for the same resource and has recommendations like
"A URI owner SHOULD NOT associate arbitrarily different URIs with the same resource."

Thus that would argue that apps should have higher-layer URIs for concepts that are not specific to HTTP,
since there may be different URIs that differ by existing protocol (and URI scheme).  As such, 4.3.2
seems problematic since it seems to be saying that that's bad and apps should use different URIs with
the same resource.

Dave

-----Original Message-----
From: art [mailto:[e-mail]] On Behalf Of Mark Nottingham
Sent: Saturday, July 15, 2017 4:09 PM
To: Adam Roach <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>; [e-mail]; Patrick McManus <[e-mail]>
Subject: Re: [art] Revising BCP56: On the use of HTTP as a Substrate


> On 15 Jul 2017, at 11:20 am, Adam Roach <[e-mail]> 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?

AFAICT IPP doesn't use the HTTP port, scheme nor HTTP's registries, so as per section 2, it's not "using" HTTP.

WS(S) uses port 80/443 to bootstrap into another protocol (using Upgrade). There probably needs to be a carve-out for that.

> 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.

I think that's a great conversation to have.

Cheers,

> 
> /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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-nottingham-bcp56bis&data=02%7C01%7Cdthaler%40microsoft.com%7Ca6ddee6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357245624370624&sdata=SXTi6jowkOjw%2FcueFIzjv8pgO6xr2CWNs03T%2FmjC5%2Bo%3D&reserved=0
>>   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmnot.github.io%2FI-D%2Fbcp56bis%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Ca6ddee6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357245624370624&sdata=dfU3abFGiVGy5GoWjP3%2Fqs%2Bz9GA5mDTpkOahKaYHGz0%3D&reserved=0
>> 
>> I have a small-ish slot in the HTTP WG session on Wednesday to discuss this.
>> 
>> Cheers,
>> 
>> --
>> Mark Nottingham   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Ca6ddee6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357245624370624&sdata=aKla74j9QLO02JvWmdd%2BG8ie9U0R9MFKdO1UCDFOOsU%3D&reserved=0
>> 
>> _______________________________________________
>> art mailing list
>> [e-mail]
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fart&data=02%7C01%7Cdthaler%40microsoft.com%7Ca6ddee6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357245624370624&sdata=E7%2F7g5BJkM6FgK0HHSxmflR0oN7zWPfqQRybZ55Eq0Y%3D&reserved=0
> 
> 
> _______________________________________________
> art mailing list
> [e-mail]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fart&data=02%7C01%7Cdthaler%40microsoft.com%7Ca6ddee6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357245624370624&sdata=E7%2F7g5BJkM6FgK0HHSxmflR0oN7zWPfqQRybZ55Eq0Y%3D&reserved=0

--
Mark Nottingham   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Ca6ddee6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357245624370624&sdata=aKla74j9QLO02JvWmdd%2BG8ie9U0R9MFKdO1UCDFOOsU%3D&reserved=0


_______________________________________________
art mailing list
[e-mail]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fart&data=02%7C01%7Cdthaler%40microsoft.com%7Ca6ddee6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357245624370624&sdata=E7%2F7g5BJkM6FgK0HHSxmflR0oN7zWPfqQRybZ55Eq0Y%3D&reserved=0