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.
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. if you want to represent the query, you need RD and
hostport and lots of other things like the EDNS0 buffer size and so on.
if you want to represent a metatuple, then there can be no hostport since
the name itself gives rise to the places (either through recursion or not)
where the data can be found.
I agree it is less confusing if the word "hostport" was avoided, and
the word "authority" is used instead. Also, using the word
"authority" instead of "server" elsewhere would also improve matters.
I have made this change for the next revision, a snapshot is available
from <http://josefsson.org/draft-josefsson-dns-url.txt>.
no, that won't fix the problem. you have fundamentally got to choose whether
you are representing a query (which can have a hostpart but which ought to
also have RD, buffer size, and other options as defined in the future) or
or whether you are representing the data itself by specifying the name,
type, and class. calling it an authority won't change the layering violation.
dns is a distributed, autonomous, coherent, reliable database. a syntax
that allows entity A and entity B to speak incoherently about a given <qname,
qtype,qclass> would violate the coherency of the design. the only exception
would be if you intended to be able to represent all attributes of a dns
query, which i think would be useless, but would allow hostport but require
RD, buffer size, and other EDNS OPT options to be invented later.