Zefram <zefram@xxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf