At Sat, 29 Jun 2019 22:55:07 +0000,
Paul Hoffman <paul.hoff...@icann.org> wrote:
> > - I think the RESINFO RDATA specification (at least its wire format,
> > and preferably also the presentation format) should be more clearly
> > specified. At least to me it was not very clear, and I'm afraid
> > this can lead to interoperability problems.
>
> It is a JSON object. What beyond that description would help?
For example, if it can be a part of a standard zone file, what's the
expected presentation format? Is it a la TXT character string (but
there's no length limitation) or something special? How do we handle
non-ascii characters?
Also, how do we compare RESINFO RDATAs? Should they be compared as
opaque binary, or should two semantically identical JSON objects
considered equal as RESINFO RDATA too (even if, for example, they are
different regarding white spaces)?
> > - The last sentence of Section 2 doesn't make sense to me:
> >
> > they only need code to handle the RESINFO RRtype that is not in
> > <reverse-ip>.{in-addr,ip6}.arpa/IN or a subdomain of <reverse-
> > ip>.{in-addr,ip6}.arpa/IN .
> >
> > Should it actually be "that is in" instead of "that is not in"? If
> > it's really "not in", I don't know how to interpret this in this
> > context...
>
> The whole sentence is confusing, and we can remove it. Thus, that whole
paragraph can go away.
It may depend on the original intent of the NODATA/NXDOMAIN
restriction, but I'm personally fine with that.
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
