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

[Mark Nottingham <[e-mail]>]

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

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://www.mnot.net/