Thats good to know Mark. I took a dark view of change in DNS, but I do
recall believing that for some problems, with tractable volumes of
change-effectors, you can move on them. So, thanks for pushing: it
helps.
Things like client capability signalling, I suspect are in a harder
bucket. I won't sa
In message
, George Michaelson writes:
> I think you missed the point John. Its a manifesto, and it can take
> radical positions. If you read Shanes markup its clear a lot of things
> which are implicit in 'UDP/EDNS0' are up for grabs.
>
> I for one, would welcome versioning models closer to HTT
I think you missed the point John. Its a manifesto, and it can take
radical positions. If you read Shanes markup its clear a lot of things
which are implicit in 'UDP/EDNS0' are up for grabs.
I for one, would welcome versioning models closer to HTTP. I'd also
welcome client-capability signalling a
I think you missed the point John. Its a manifesto, and it can take
radical positions. If you read Shanes markup its clear a lot of things
which are implicit in 'UDP/EDNS0' are up for grabs.
I for one, would welcome versioning models closer to HTTP. I'd also
welcome client-capability signalling an
In article <037201d1db19$78c3ac90$6a4b05b0$@cn> you write:
>When I first looked into DNS, I was recommended with a complex figure of DNS
>protocol family describing the dependency and activeness of many RFC
>documents. I'm wondering if it is possible to attach versions to DNS
>protocol similar like
When I first looked into DNS, I was recommended with a complex figure of DNS
protocol family describing the dependency and activeness of many RFC
documents. I'm wondering if it is possible to attach versions to DNS
protocol similar like IPv4 and IPv6, http/1.1 and HTTP/2 which can give
clear path o
