HTTP-31: Other Schemes and downref to experimental

[gloinul]

Section 3.2.2 states:

"Prior to making requests for an origin whose scheme is not "https", the client MUST ensure the server is willing to serve that scheme. If the client intends to make requests for an origin whose scheme is "http", this means that it MUST obtain a valid http-opportunistic response for the origin as described in [RFC8164] prior to making any such requests. Other schemes might define other mechanisms."

The first issue is that this text make normative use of RFC8164 to handle "http" scheme. RFC8164 is an experimental RFC. Thus we have a downref issue. I think it would be inappropriate to elevate RFC8164 status by allowing a downref here. I think one option would be to move the specification of the usage of RFC 8164 for the "http" URI scheme in HTTP/3 into its own experimental RFC. Another potential option is to simply inform about the ongoing experiment without specifying that it can be done with HTTP/3.

Secondly, I am uncertain about the scope of the first sentence in that paragraph. Is there any other URI schemes other than "http" that this is applicable for? If it is which type of URI schemes is it applicable for? For clearly it is not applicable to the "rtsp" scheme that isn't using HTTP at all.

[MikeBishop]

Second point first: HTTP doesn't restrict the scheme of URIs a client can request; URI schemes define what protocols can be used to access them, which might or might not include HTTP.

For example, RFC7540 says:

   ":scheme" is not restricted to "http" and "https" schemed URIs.  A
  proxy or gateway can translate requests for non-HTTP schemes,
  enabling the use of HTTP to interact with non-HTTP services.

To the first point, I feel like not mentioning that RFC8164 can be done with HTTP/3 means it's irrelevant to include in this document, and the requirement to verify the peer can serve a scheme is necessary.

Perhaps something like:

Prior to making requests for an origin whose scheme is not "https", the client MUST ensure the server is willing to serve that scheme. For origins whose scheme is "http", an experimental method to accomplish this is described in [RFC8164]. Other mechanisms might be defined in the future.

[gloinul]

The proposed text looks good. I think that resolves it and you can move RFC8164 to be a informational ref.

So I think this resolves my issue.

[larseggert]

Based on this resolution, labeling this as "editorial"