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

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Jul 2017 14:14:04 +1000

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://tools.ietf.org/html/draft-nottingham-bcp56bis
  https://mnot.github.io/I-D/bcp56bis/

I have a small-ish slot in the HTTP WG session on Wednesday to discuss this. 

Cheers,

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Jul 2017 10:36:00 +0200

Hi Mark,

There is no question that 3205 could use a dust off.  I would suggest
that document really served two purposes.  The first was to provide best
practices on its use, and the second was more of an applicability
statement.  You've gone to some detail as to best practices, but it
seems to me more attention should be paid to the applicability component.

Good engineering principles dictate not only when a mechanism should be
used, but as important, when it should not.  HTTP's use has GREATLY
expanded thanks in large part to REST, but it also could it might narrow
somewhat, thanks to protocols such as CoAP, or through the further
development of QUIC.  A valuable contribution would be to give guidance
as to what substrate is appropriate and when.

Related, we TCP/UDP port reviewers occasionally see requests for new
ports that make use of HTTP as a substrate.  Personally I always welcome
more guidance as to when to approve those ports.  The standing view is
that we approve them in large part to address non-interference with
existing services, but at some level that seems a bit of a waste, and
perhaps we should come out more strongly to say that if HTTP is really
to be used as a substrate, there must be some form of appropriate
application layer dispatch perhaps tied to .well-known.

I won't be attending the HTTPBIS meeting but I hope you'll consider
these comments as you develop the document.

Eliot

On 7/11/17 6:14 AM, Mark Nottingham wrote:
> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Jul 2017 05:37:05 -0700

Hi, all,

I too look forward to this coordination, especially as Eliot notes its
impact on the IANA ports review team.

I would encourage a look at RFC 7605 on this issue.

Joe

---

From: Adam Roach <[email-masked]>
Date: Sat, 15 Jul 2017 11:20:40 +0200

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?

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.

/a

---

From: Ben Campbell <[email-masked]>
Date: Sat, 15 Jul 2017 11:31:19 +0200

> On Jul 15, 2017, at 11:20 AM, Adam Roach <[email-masked]> 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?
> 
> 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.
> 

Also, while I recognize the difference between protocols “using HTTPS” on 443 vs non-HTTPS protocols using 443 for NAT traversal purposes, the recent controversy over CORE's use of 443 suggests that this discussion will need to go beyond ART. At least, I think some TSV and OPS people may have opinions. Maybe those opinions will be “it’s HTTPS, use HTTPS”, but we should verify. (I suspect network management people may have concerns.)

Ben.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 15 Jul 2017 16:09:06 +0200

> On 15 Jul 2017, at 11:20 am, Adam Roach <[email-masked]> wrote:
> 

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.

> 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 think that's a great conversation to have.

Cheers,

---

From: Ted Hardie <[email-masked]>
Date: Sat, 15 Jul 2017 16:25:43 +0200

On Sat, Jul 15, 2017 at 4:09 PM, Mark Nottingham <[email-masked]> wrote:

> 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?
>
RFC 7472 describes the  HTTPS tranport binding and its relationship to the
ipps scheme (it's a successor to some previous work doing similar things
for HTTP).  It notes:

The IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230
<https://tools.ietf.org/html/rfc7230>]
      (replacing 'ipps' with 'https' and inserting the port number from
      the URI or port 631 if the URI doesn't include an explicit port
      number);

While the default isn't the existing HTTPS port, it's my understanding that
in some deployments the ipps scheme uses the HTTPS port and so ends up with
an HTTPS scheme message over the standard HTTPS port.

regards,

Ted

> WS(S) uses port 80/443 to bootstrap into another protocol (using Upgrade).
> There probably needs to be a carve-out for that.
>
> 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.
> >
> 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.
> >
> >> 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:

---

From: Adam Roach <[email-masked]>
Date: Sat, 15 Jul 2017 16:55:20 +0200

On 7/15/17 16:25, Ted Hardie wrote:
> On Sat, Jul 15, 2017 at 4:09 PM, Mark Nottingham <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     > On 15 Jul 2017, at 11:20 am, Adam Roach <[email-masked]
>     <mailto:[email-masked]>> 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.
>
>
> RFC 7472 describes the  HTTPS tranport binding and its relationship to 
> the ipps scheme (it's a successor to some previous work doing similar 
> things for HTTP).  It notes:
>
> The IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230 <https://tools.ietf.org/html/rfc7230>]
> While the default isn't the existing HTTPS port, it's my understanding 
> that in some deployments the ipps scheme uses the HTTPS port and so 
> ends up with an HTTPS scheme message over the standard HTTPS port.

You don't have to rely on the ipps spec for this -- the original design 
of IPP has a similar transformation for ipp URLs; RFC2910 stipulates:

    Because the HTTP layer does not support the 'ipp' scheme, a client
    MUST map 'ipp' URLs to 'http' URLs, and then follows the HTTP
    [RFC2616][RFC2617] rules for constructing a Request-Line and HTTP
    headers.  The mapping is simple because the 'ipp' scheme implies all
    of the same protocol semantics as that of the 'http' scheme
    [RFC2616], except that it represents a print service and the implicit
    (default) port number that clients use to connect to a server is port
    631.

Mark -- if you think the guidance in your document wouldn't apply in 
these cases, you'll have to be clearer by what you mean when you say 
'The URL scheme "http" or "https" is used': I would have thought this 
qualifies.

/a

---

From: Adam Roach <[email-masked]>
Date: Sat, 15 Jul 2017 17:17:32 +0200

In reading over the current draft a bit more, another specific piece of 
advice stuck out as interesting:

    Another common practice is assuming that the HTTP server's name space
    (or a portion thereof) is exclusively for the use of a single
    application.  This effectively overlays special, application-specific
    semantics onto that space, precludes other applications from using
    it.

It's the "or portion thereof" that sticks out at me. I'll note that this 
*is* consistent with the guidance in RFC7320 section 2.3, but that 
document didn't cross my radar at the time either.

In a similar vein as my questions before -- if this guidance were in 
effect at the time that RFC 4825 (XCAP) were under development, are we 
sure that it would have been appropriate? Semantically, the extension of 
URL paths down into XML documents seems both clean and appropriate; 
however, it is most certainly overlaying "special, application-specific 
semantics" onto the path component.

So, if we were doing XCAP today from scratch, what *would* be the 
preferred mechanism for addressing an element?

/a

---

From: Ira McDonald <[email-masked]>
Date: Sat, 15 Jul 2017 11:22:03 -0400

Hi,

Speaking as the co-editor of both the "ipp" and "ipps" URI schemes and the
successor (RFC 8010) to RFC 2910, using HTTP as a substrate for IPP was
a serious design mistake that has added numerous implementation errors and
no functional value.

One prominent (non-conforming) implementation of IPP does use port 443,
but that's just plain wrong and fails the IEEE-ISTO PWG IPP Everywhere
conformance certification tests.

Please don't use IPP as justification in this discussion.  The use of HTTP
as
a substrate was based on bad advice from IETF regulars who should have
known better.

[ok - back into my cave...]

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

On Sat, Jul 15, 2017 at 10:55 AM, Adam Roach <[email-masked]> wrote:

> that in some deployments the ipps scheme uses the HTTPS port and so ends up
> with an HTTPS scheme message over the standard HTTPS port.
>
>
> You don't have to rely on the ipps spec for this -- the original design of
> IPP has a similar transformation for ipp URLs; RFC2910 stipulates:
>
> Mark -- if you think the guidance in your document wouldn't apply in these
> cases, you'll have to be clearer by what you mean when you say 'The URL
> scheme "http" or "https" is used': I would have thought this qualifies.
>
>
> /a
>

---

From: Martin J. Dürst <[email-masked]>
Date: Sun, 16 Jul 2017 14:42:01 +0900

Hello Ira,

> a serious design mistake that has added numerous implementation errors and

Can you be a bit more specific, or point to something more specific?

Regards,   Martin.

---

From: Dave Thaler <[email-masked]>
Date: Sun, 16 Jul 2017 08:11:52 +0000

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:[email-masked]] On Behalf Of Mark Nottingham
Sent: Saturday, July 15, 2017 4:09 PM
To: Adam Roach <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>; [email-masked]; Patrick McManus <[email-masked]>
Subject: Re: [art] Revising BCP56: On the use of HTTP as a Substrate

Cheers,

>>   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
>> 
>> 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
>> 
>> 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
> 
> 
> 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
[email-masked]
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

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 16 Jul 2017 10:16:14 +0200

> On 16 Jul 2017, at 10:11 am, Dave Thaler <[email-masked]> wrote:
> 

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

---

From: Dave Thaler <[email-masked]>
Date: Sun, 16 Jul 2017 08:18:48 +0000

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:[email-masked]] 
Sent: Sunday, July 16, 2017 10:16 AM
To: Dave Thaler <[email-masked]>
Cc: Adam Roach <[email-masked]>; Alexey Melnikov <[email-masked]>; Patrick McManus <[email-masked]>; [email-masked]
Subject: Re: [art] Revising BCP56: On the use of HTTP as a Substrate

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

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

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 16 Jul 2017 10:20:59 +0200

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 <[email-masked]> wrote:
>

---

From: Ira McDonald <[email-masked]>
Date: Sun, 16 Jul 2017 08:41:28 -0400

Hi Martin,

I'll try to be more specific:

IPP uses a unique binary encoding of its primitive datatypes (integer,
language-tagged string, keyword (registered) as distinct from name
(vendor free-form), etc.).  So the HTTP payload of IPP is opaque.

IPP original authors were told that using an HTTP substrate would make
penetrating firewalls easier - it didn't of course.

IPP "resources" do not correspond to the general HTTP idea of resources,
so the semantics of HTTP Get on an IPP URI are surprising.

IPP uses HTTP POST for the main operation requests.

The fact that the wrapper was HTTP has led to numerous problems
with intermediate entities attempting to optimize/cache/whatever the
IPP operation requests and responses.  HTTP Basic and Digest were
supposed to be good authentication methods - but they're weak and
have been largely replaced by Kerberos, OAuth, etc., in practice.

Printer vendors sometimes re-invented their own HTTP layers
(LOTS of bugs) or pasted in HTTP layers from immature sources
(and then never maintained them).  What IPP needed was a TLS
connection for end-to-end authentication and encryption.  Modern
printers almost universally use TLS "under" their HTTP layer, as is
mandated by IPP Everywhere (IEEE-ISTO PWG 5100.14).

IPP is ubiquitous (over 98% of all printers sold in recent years), but
the HTTP layer was just used as an over-complicated way of getting
a TLS connection.

I hope this helps explain my aversion to the use of HTTP in the IPP
protocol stack.

Cheers,
- Ira

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 16 Jul 2017 16:48:49 -0700

> On Jul 16, 2017, at 5:41 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Martin,
> 

Umm, what advice are you referring to?  I remember

  ftp://ftp.pwg.org/pub/pwg/ipp/minutes/961212-ietf-bof.txt

and being quite explicit about why that plan was bogus. I also remember
advising that HTTP be used as designed, not tunneled through with an
opaque blob of poorly designed vendor-specific options.

Whatever problems IPP may have encountered after that, they weren't due
to the authors following IETF advice, nor were they due to using HTTP
as a substrate (any more than they were due to using TCP as a substrate).
They might have been due to not inventing a completely new protocol that
performed streaming RPC with opaque data through firewalls, but I think
that's a bit fanciful given the lack of successful examples.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Jul 2017 12:48:12 +0200

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?

---

From: Ted Hardie <[email-masked]>
Date: Wed, 19 Jul 2017 06:53:42 +0200

I generally like this, but have one suggested adjustment

On Tue, Jul 18, 2017 at 12:48 PM, Mark Nottingham <[email-masked]> w

> For these reasons, it is preferable to use the message payload to indicate
> the application in use, rather than the URL scheme.
>
I think you cover what the issues are with using URI schemes, but the
preference to use message payload appears pretty suddenly.  There are
trade-offs there too and some of the usual methods (dispatching mime type)
have pretty big gotchas.  I'd suggest you either elide this text or expand
it.

regards,

Ted

> > Cc: Adam Roach <[email-masked]>; Alexey Melnikov <
> [email-masked]>; Patrick McManus <[email-masked]>;
> [email-masked]
> >> for separate URI schemes for different protocols (ftp, http, coap,
> etc.), e.g. "G4. Serve using the protocol associated with the URI scheme".
> >>
> >> 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.
> >>
> >> .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."
> >>
> >> 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%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636357897782929506&sdata=hLIqYngKJ4NFkbB3zJl6Pf6jeL0dgW
> %2FkQiFIiWxFtT8%3D&reserved=0
> >
> >

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 25 Jul 2017 14:16:56 +1000

> On 19 Jul 2017, at 2:53 pm, Ted Hardie <[email-masked]> wrote:
> 
> I think you cover what the issues are with using URI schemes, but the preference to use message payload appears pretty suddenly.  There are trade-offs there too and some of the usual methods (dispatching mime type) have pretty big gotchas.  I'd suggest you either elide this text or expand it.

Yes; I think saying "preferable" here is too strong; it should just refer to the (soon to be exist) section on defining payloads.