sorry to lose momentum on this thread, i got busy with something else briefly: > > 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. i guess we're in different weeds now. because of the high abstractness of your "hostport" definition, there's no guaranty that the dns protocol will even be used by the uri-handler to resolve the pseudoquery. so, the idea of "not-yet-delegated" has no foundation at all. here's the real issue: there are many companies and political movements who think that iana's namespace is not the only namespace. new.net, for example. iab takes a very strong "single unique namespace" view, and as such, the i* organizations (iesg in this case) will probably (and ought to, in my view) take a very dim view of any attempt to standardize a uri that permits a "multiple namespace" fiction to be operable. to me the layering violation of your "hostpart" suggestion is jarring, and obvious, and is approximately equal to extending "hostpart" in normal http: (and telnet: and mail: and so on) uri's to allow one to specify not only a hostname, but also the address of the dns server which ought to be asked to resolve the A or AAAA query. "http://new.net:foo.sex/bar/";, anyone? if you answered "no" then you gotta ask yourself why allow a "hostport" in a dns: uri if you dislike its tangible equivilent in other parts of the spec. > > 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. ah, meat. for multiple roots, the iab has (thankfully) recognized that the dns just doesn't work that way. for split-dns and disconnected operation, the place to put that kind of policy is in the resolver, not in every application who calls it. see http://sa.vix.com/~vixie/proxynet.pdf for an example of how to do this (it's from 1995 but the code still compiles if anybody still wants it.) the tradeoff between efficiency and correctness weighs VERY heavily on the side of correctness, such that the likelihood of getting the wrong data or no data by using "hostport" for efficiency is MUCH HIGHER than the likelihood of a performance problem from not using it. (for user populations of a global size, as ours is.) > 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? for my part, i'd like to hear the iab's input, since this goes to the architecture of the overall internet system.