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

After this and some offline discussion, my current copy has:

~~~

### URL Schemes {#scheme}

Applications that use HTTP will typically use the "http" and/or "https" URL schemes. "https" is preferred to mitigate pervasive monitoring attacks {{?RFC7258}}.

However, application-specific schemes can be defined as well.

When defining an URL scheme for an application using HTTP, there are a number of tradeoffs and caveats to keep in mind:

* Unmodified Web browsers will not support the new scheme. While it is possible to register new URL schemes with Web browsers (e.g. registerProtocolHandler() in {{custom-handlers}}, as well as several proprietary approaches), support for these mechanisms is not shared by all browsers, and their capabilities can vary.

* Likewise, existing non-browser clients, intermediaries, servers and associated software will not recognise the new scheme, and might fail to operate. For example, a client library might fail to dispatch the request; a cache might refuse to store the response, and a proxy might fail to forward the request. 

* Because URLs occur in and are generated in HTTP artefacts commonly, often without human intervention (e.g., in the `Location` header), it can be difficult to assure that the new scheme is used consistently.

* The resources identified by the new scheme will still be available with "http" and/or "https" URLs to clients. While it is possible to define the relationship between these resources in new new scheme's specification, existing HTTP software (such as clients, caches, intermediaries and servers) will not be available, so there is a danger of confusion when the "wrong" URL is used.

* Features that rely upon the URL's origin {{?RFC6454}}, such as the Web's same-origin policy, will be impacted by a change of scheme.

* HTTP-specific features such as cookies {{?RFC6265}}, authentication {{?RFC7235}}, caching {{?RFC7234}}, and CORS {{CORS}} might or might not work correctly, depending on how they are defined and implemented. Generally, they are designed and implemented with an assumption that the URL will always be "http" or "https".

* Web features that require a secure context {{secure-context}} will likely treat a new scheme as insecure.

For these reasons, it is preferable to use the message payload to indicate the application in use, rather than the URL scheme.

See {{?RFC7595}} for more information about minting new URL schemes.

~~~

Thoughts?

> On 16 Jul 2017, at 10:18 am, Dave Thaler <dthaler@microsoft.com> 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:mnot@mnot.net] 
> Sent: Sunday, July 16, 2017 10:16 AM
> To: Dave Thaler <dthaler@microsoft.com>
> Cc: Adam Roach <adam@nostrum.com>; Alexey Melnikov <alexey.melnikov@isode.com>; Patrick McManus <mcmanus@ducksong.com>; art@ietf.org
> Subject: Re: [art] Revising BCP56: On the use of HTTP as a Substrate
> 
> 
>> On 16 Jul 2017, at 10:11 am, Dave Thaler <dthaler@microsoft.com> 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
> 
> 
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art

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