Paul Vixie <vixie(_at_)fh(_dot_)vix(_dot_)com> writes:
very well. then i request that you remove the "hostport" from the syntax.
The rationale being?
you said it best, earlier:
... Furthermore, DNS URIs do not require the use of the DNS protocol at
all, it just denote a DNS resource. ...
a dns resource lives where its parent NS RRs say it lives -- and not, as
you also suggest...
The hostport describes the authority that know the intended DNS
resource. An authority is useful even for abstract, non-DNS-protocol,
DNS resources. DNS resources themselves are indexed by (NAME, CLASS,
TYPE), but to distinguish between the answer that entity A
knows/generate, and the answer that entity B knows/generate, an
authority scope like "hostport" is needed.
...in the answers that different entities can generate.
This view limit the usefulness of the URI, as it cannot be used to
refer to, e.g., not-yet delegated data. It can be useful to use DNS
URIs to denote DNS data in a delegation request, to indicate where the
new data will be placed, so it can be checked for conformance with
various rules.
Most applications probably will not care, and use the "default"
authority, trusting the local server to do the right thing. But for
internal DNS environments, specifying the authority could be required.
you can't have it both ways. either you're trying to represent dns data
using the <qname,qtype,qclass> tuple, or you're trying to represent
the query itself.
I'm trying, like the document says, to represent dns data using the
<qname,qtype,qclass> tuple together with the authority/server. The
authority was added to be able to denote data that, for some reason,
is not linked into the global DNS. The reason could be multiple
roots, split-view DNS, disconnected operation, efficiency or whatnot.
I could remove the hostport element if the consensus is that doing so
would improve the usefulness of the URI. Anyone else with an opinion?
Remove hostport or keep it?
Thanks,
Simon