Zefram <zefram(_at_)fysh(_dot_)org> wrote almost a year ago:
1. A related issue, which I raised last time this was discussed but
was never addressed: there's a general extension mechanism, but no
reasonable use for it. This URI type should express solely a <class,
name, type> tuple; the extension mechanism should be abandoned.
I've dropped the extension mechanism for -10.
2. There is no reasonable default for the <dnstypeval> element.
This draft specifies a default of type A, which will cause confusion;
explicit specification of the type should be mandatory.
The DNS was presumably built to primarily provide address lookups, so
I don't think it is unreasonable to make A queries the default. This
also match tools like "dig" and "host"; if you don't specify a type,
you get A records in the IN class. I don't see what confusion that
might arise, that don't also arise by making CLASS default to IN. On
the contrary, I think both the IN and A default are useful. Further
thoughts appreciated.
3. Multiple types, or multiple classes, may be specified, but only one
takes effect. Allowing <dns:host.example.org?TYPE=A;TYPE=TXT> to be
valid, and to mean the same thing as <dns:host.example.org?TYPE=A>,
is misleading. It should only be permitted to specify one type and
one class. (This issue was raised last time this draft was discussed,
but has been fixed in the wrong way.)
I've corrected this in -10.
4. Although allowing <dnsname> to be empty is not necessarily wrong,
it is inconsistent with prior practice. It would be clearer, and
more consistent, to require the root domain to be represented by an
explicit ".". (Another issue patched in the wrong way.)
The situation was more complex than what -09 might have led you to
believe. The problem was that -09 didn't discuss the difference
between absolute and relative DNS owner names. -10 do this. As a
consequence, though, it will consider empty <dnsname> as a
degenerative form of a relative owner name, relative to the root,
which incidentally is equal to the root. Explicitly forbidding empty
<dnsname> seem uncalled for, and would add complexity to
implementations.
5. The scheme described to encode a "." within a DNS label is
inconsistent with basic URI syntax. Section 2.3 of RFC2396 says
"Unreserved characters can be escaped without changing the semantics
of the URI". Since "." is unreserved, this means that "." and
"%2e" in a URI must be equivalent. <dns:foo.bar.example?type=TXT>
and <dns:foo%2ebar.example?type=TXT> must refer to the same RRset.
One possible solution is to use a reserved character (perhaps ",") to
separate DNS labels within the URI, but this is pretty ugly. A more
feasible solution is to use another layer of escaping; RFC1035 provides
a perfectly good and familiar (to DNS administrators) escaping scheme
for domain names.
Good catch. -10 will use the RFC 1035 escape mechanism, but since \
cannot occur in URIs, it must be escaped. So "foo\.bar" is thus
encoded as "foo%5c.bar", which is sort of weird but I can't think of a
better solution.
I'm preparing -10 right now, the document reside at:
<http://josefsson.org/draft-josefsson-dns-url.html>. Early comments
appreciated, of course. The rfcdiff isn't all that useful due to the
large changes.
Thanks,
Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf