a web services version of dns-via-http(s) would use restful queries and
json results. so,
GET http://util.redbarn.org/dns/v1/query/www.google.com/in/aaaa
{
"rcode": "noerror",
"question": [
{ "qname": "www.google.com", "qclass": "in", "qtype": "aaaa" }
],
"answer": [
{ "name": "www.google.com",
"class": "in",
"type": "aaaa",
"ttl": "154",
rdata = [ "2607:f8b0:4005:802::2004" ]
}
]
}
here, ancount/qdcount/nscount/adcount are expressed by the size of
arrays, rrsets are slabbed, and empty sections are omitted. there are a
million ways to do the json part. the restful part would need some kind
of &opt= to express edns parameters, or just more positional parameters.
you'd use POST for UPDATE and NOTIFY.
but that's a web services thing, which ought to exist, but which this
proposal is not. this proposal is about taking binary DNS messages and
slopping them around inside POST payloads and responses. you mentioned
MIME but frankly my expectation is that it'll mostly be binary data
since HTTP is 8-bit clean -- this isn't e-mail here.
the folks who think this proposal ought to use RESTful JSON are missing
the point. this is not that. both should exist. but, this is not that.
paul
re:
George Michaelson wrote:
Bearing in mind that I like being a purist and could understand the
GET/POST thing in terms of architecture, I'm asking myself if it makes
sense to use GET URL semantics which require super-encoding things to
fit into URL norms, or to use POST semantics where the block of data
might be constrained by what we want to say, but the MIME encodings
are there to make it easier to say what it is, and why its encoded
that way.
I'd also ask myself: what to VPN's do, which use HTTPS as a transport?
I'm pretty sure they use POST. Happy to be proved wrong.
-G
On Thu, Mar 3, 2016 at 5:36 AM, Paul Vixie<p...@redbarn.org> wrote:
Paul Hoffman wrote:
On 2 Mar 2016, at 2:05, Davey Song wrote:
For pure "Aesthetics" reason, If I was designing a toy protocol or a
custom
tool, then I might insist on GET. but I should choose POST to work around
broken software and proxy in the networks.
Just to be clear: it's not just aesthetics. There are many other systems
that make the assumptions about GET and POST.
We talked about this in Yokohama. Your design is "I want to put the
message in the body" instead of "I can easily encode the request as a
URL". If you want this protocol to be standardized in the IETF, you
really should consider the decades of work that have gone into HTTP by a
community much larger than the DNS community, and use that community's
long-standardized semantics.
it is very common to use POST to transmit data in ways that do not change
the state of the server. even in the most common "web forms" case, many web
forms are lookups that only return information, rather than changing server
state based on form data.
i do not believe that using POST will slow down standardization on this.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
