Paul Vixie <[EMAIL PROTECTED]> 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