Robert Edmonds wrote on 2023-06-29 14:58:
Tim Wicinski wrote:
...
Feedback Welcome
tim
...
I originally developed one of the implementations named in this draft
[1] and if I recall correctly it did not occur to me that the API I was
developing should ever be standardized, let alone the underlying data
model being used to generate API responses, which I don't think this I-D
has ever touched on. E.g., the 'rdata' field may return a string or an
array of strings; if you have an array of length 1, does this mean a
resource record or a resource record set is being represented? ...
the implementation you pioneered eventually started an industry, and all
of us wanted compatibility across access formats. it likely will never
be extended to include the REST portion of the API, but the JSONL format
is most convenient to accessors if it's not useless different.
rdata is now described as an array, since that's what all
implementations now return. we added a note that it may be a string and
that accessors should be prepared for this for backward compatibility. i
think that could be removed at this stage (years later.)
So, it seems a bit odd to me to try to put a particular narrowly scoped
idiosyncratic consensus format used by a few particular API services
through the RFC process. There are many kinds of databases, API
services, and formats that do not have RFC documents describing them.
For instance, the pcap savefile format is widely used and presumably a
lot of governments buy a lot of products that support the pcap format,
and as far as I can tell the canonical specification for that format is
a file in a particular Git repository [2] maintained by a group of open
source contributors. Why isn't that approach feasible for this
particular use case, which is much more of a niche use case than packet
capture in general?
i'll be happy to host the specification on
https://github.com/dnsdb/dnsdbq if that's the IETF's preference. this
command-line API client (in C) intends to speak to as many API servers
as possible. it was inspired by the API client you pioneered (in
Python). i also wrote a Go version but it's not open source. in any
case, SIE Europe U.G., a non-profit in Germany where i am a founder and
director, hopes that some document somewhere will describe the format of
our API server's output. we are a partner of farsight/domaintools so our
format is the same as theirs. but we want our members to be sure that
any processing they wish to do with our database output has no "lock-in"
properties. therefore, documenting this only on the domaintools web site
would not be adequate.
--
P Vixie
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
