Subject: Re: I-D ACTION:draft-josefsson-dns-url-09.txt

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Sep 2004 02:23:46 +0200

Zefram <[email-masked]> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf