Paul Vixie <paul(_at_)vix(_dot_)com> writes:
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.
I don't see how this relate to being able to specify the DNS server to
query in a URI to denote DNS data.
Can you describe how the DNS URI with a "hostport" make multiple
namespaces operable?
Having multiple namespaces is not [inter]operable by definition, IMHO.
The DNS URI is not an attempt in this direction.
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.
I see no problem here. A HTTP URI should not contain the DNS server
address to use, since the HTTP specification describe how the server
is found. Same goes for mailto; RFC 821 and 2821 describe how the
SMTP server for a mail address is found. Adding the DNS server to use
would expose details that should be hidden in the application.
The situation is different for a DNS URI, since RFC 1024/1025 describe
how you query a specific DNS server (IP) via the DNS protocol.
I claim it can be useful to specify this information, but acknowledge
that removing the hostport would remove this potential confusion.
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.
The global DNS namespace and the DNS protocol are not the same thing.
I believe the IAB has only recognized that the former, the namespace,
doesn't work with multiple roots, in RFC 2826. And like I say above,
I don't see how the DNS URI further the multiple namespace root cause.
That the DNS protocol can handle multiple roots is a technical
property that can be used for good purposes, in which "hostport" can
be useful. (Of course, it is not only useful for multiple roots.) Do
you have a reference to where the IAB recognize that the DNS protocol
technically doesn't work with multiple roots?
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.
DNS URIs can be used to put this kind of policy in the resolver.
Applications are not generally expected to support DNS URIs.
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.)
Some people still do experiment to improve the efficiency in the DNS.
The DNS URI is not intended to be used widely (see the specification,
and "Intended Usage"), nor will the "hostport" field always be
present; that's why it is optional. People would avoid using the
"hostport" field if it decreased correctness for them.
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.
There hasn't been much input on the DNS URI, so I do appreciate when
anyone looks at it.
I guess we simply have different opinions, so I'm not sure splitting
more hairs over various definitions will be productive, although
hopefully this discussion can be informative for others, when they
form their own opinion.
Thanks,
Simon