Davey Song wrote:
Of all your observations, this one is the trickiest. :(
Right now the protocol is clearly based on HTTP/1.1, although we
have
an implementation that works fine with HTTP/2 since the Go HTTP
library
supports it (basically) transparently.
Let me talk with my co-authors and see what they think!
as a named co-author, i think the http version number is irrelevant,
and that we should not describe http/1.1 in our spec. that is, we
should not mention headers, lines, or bodies. those are syntactic
elements meant to be parsed to find semantic elements: request
action, request headers, and request body. (or similar.) how those
elements are encoded is not important to proxy-dns, nor to any other
web-carried app.
we should restate our specification in terms that are portable to
http/2 and every http protocol thereafter. the encoding of our blobs
into http, and the decoding of an http message into the blobgs we
need, is an implementation detail.
The HTTP version is mentioned because the difference of http/1.1 and
http/2 is relevant to DNS performance, if http is used as an alternative
transport protocol. It is worthwhile to encourage people to use modern
HTTP protocol.
the best RFC documents are timeless, having as much meaning and
sensibility in year 10 than in year 1. i really think that we have no
role in recommending a 1.1 -> 2.0 transition, and that our document
should describe our protocol as an http client/server protocol, and make
sure that the document makes as much sense in an HTTP/2 world as in an
HTTP/1.1 world.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
