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

[Mark Nottingham <[e-mail]>]

I think we learned that that kind of wallpapering over of application protocol semantics doesn't work well when WS-* failed. People still keep on trying to do it, though.


> On 16 Jul 2017, at 10:18 am, Dave Thaler <[e-mail]> wrote:
> 
> So if you have a resource that is served over multiple other protocols (ftp, coap, whatever) but NOT http,
> W3C would tell people to use the HTTP scheme anyway?  
> 
> http://www.w3.org/2001/tag/doc/SchemeProtocols.html#useNaturalProtocol says:
> 4.2.1 G4. Serve using the protocol associated with the URI scheme
> 
> -----Original Message-----
> From: Mark Nottingham [mailto:[e-mail]] 
> Sent: Sunday, July 16, 2017 10:16 AM
> To: Dave Thaler <[e-mail]>
> Cc: Adam Roach <[e-mail]>; Alexey Melnikov <[e-mail]>; Patrick McManus <[e-mail]>; [e-mail]
> Subject: Re: [art] Revising BCP56: On the use of HTTP as a Substrate
> 
> 
>> On 16 Jul 2017, at 10:11 am, Dave Thaler <[e-mail]> wrote:
>> 
>> 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.
>> 
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3
>> .org%2FTR%2Fwebarch%2F%23uri-aliases&data=02%7C01%7Cdthaler%40microsoft.com%7Cf5e1aabcbc1b4a7a6fb708d4cc22eea2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357897782919498&sdata=klbb40TomYZ216cxDZFHGBh1EiXMaVc2pmT4%2FjsXKv4%3D&reserved=0 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.
> 
> W3C doesn't share the IETF's aversion to using HTTP to identify higher-level concepts. The "Web" way that has emerged is to use HTTP to discover more about the other protocols as necessary (as we see with H2 and now QUIC negotiation).
> 
> 
> 
> --
> Mark Nottingham   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Cf5e1aabcbc1b4a7a6fb708d4cc22eea2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357897782929506&sdata=hLIqYngKJ4NFkbB3zJl6Pf6jeL0dgW%2FkQiFIiWxFtT8%3D&reserved=0

--
Mark Nottingham   https://www.mnot.net/