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

I generally like this, but have one suggested adjustment

On Tue, Jul 18, 2017 at 12:48 PM, Mark Nottingham <mnot@mnot.net> w


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


>
> ~~~
>
> 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%7C72f988bf86f141af91ab2d7cd011
> db47%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/
>
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>