On 2018-06-01 23:15, Patrick McManus wrote:
Hi Julian, I apologize this got a little bit forgotten. I will issue a
new draft with the last call comments included.
...
No worries.
... > 4. The Extended CONNECT Method
...
o A new pseudo-header :protocol MAY be included on request HEADERS
indicating the desired protocol to be spoken on the tunnel
created
by CONNECT. The pseudo-header is single valued and contains a
value from the HTTP Upgrade Token Registry defined by [RFC7230].
I believe it would be good to add a short explanation why it is ok
to defined a new pseudo header field despite this not being an
HTTP/2 extension point.
I realize that using the SETTINGS mechanism one can make
incompatible changes (and this should be mentioned here), but I'm
still unconfortable with the consequences, for instance: what if a
different extension wants to define the same pseudo header field
with different semantics?
The latest iteration of that discussion is here:
https://www.ietf.org/mail-archive/web/secdir/current/msg08134.html
<https://www.ietf.org/mail-archive/web/secdir/current/msg08134.html> ..
the wg also considered the question.
It is an interesting question for everyone reviewing the documents, but
I don't really think its a very interesting question for someone
implementing this protocol. The general question of semantic conflict is
something the WG has to handle for all proposed extensions (and
registries are never going to cover the full semantic set of potential
conflicts.. I would argue that the change in interpretation of
:authority is more significant than a new header value) - nothing
particular about this one. Maybe we should consider a general document
on the topic.
Based on these comments I added a bit more detail to the existing
discussion in section 3:
The use of a SETTINGS Parameter to opt-in to an otherwise
incompatible protocol change is a use of "Extending HTTP/2" defined
by Section 5.5 of [RFC7540]. Specifically, the addition a new
pseudo-header ":protocol" and the change in meaning of the
":authority" pseudo-header in Section 4 require opt-in negotiation.
+1
And thank for the other changes.
Best regards, Julian
