Paul,
Thank you for the comments. Answers inline below.
Paul Vixie <paul@vix.com> writes:
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send any comments to the
>> iesg@ietf.org or ietf@ietf.org mailing lists by 2003-7-22.
>
> i have one comment on document quality (DQ) and one protocol quality (PQ).
>
> DQ: the url scheme syntax allows a given dnsqueryelement to be validly
> specified more than once, but does not explain whether the first or last
> instance of a duplicate dnsqueryelement will be the one in effect. this
> ambiguity could be resolved by changing the syntax so that duplicates
> are invalid, or by stating that the first or last dnsqueryelement
> instance "wins".
I have fixed this, by letting the first element win.
dnsquery = dnsqueryelement [";" dnsquery]
; First matching element MUST be used.
; E.g., dns:host.example.org?TYPE=A;TYPE=TXT
; means type A.
Making such URIs invalid seems to be asking for implementation
problems, but I don't have a strong opinion about it. Please suggest
text if this is unsatisfactory.
> PQ: the url scheme does not allow the RD bit to be set. of all the DNS
> and EDNS flags and options which might affect the results of the query,
> only RD can really be thought to be "missing" from this specification,
> and only in the case where the "hostport" is given. however, it may be
> wise to permit the specification of other flags, and EDNS OPT options, so
> that if a future flag or option block is added which affects the results
> of a query in the way RD can do, the URI syntax for it will already be known.
I don't believe this belong in a URI specification. There are many
things which the URI do not allow to be expressed, but which do affect
the answer that is eventually returned. E.g., originator address of
the DNS query, use of IPSEC or no IPSEC, whether your network cable is
plugged in or not.
Furthermore, DNS URIs do not require the use of the DNS protocol at
all, it just denote a DNS resource. DNS URIs can be resolved via HTTP
or something else. Having the RD bit present is a hint to the DNS
protocol; the RD bit has no connection with the DNS resource that the
URI denote.
Leaving the protocol logic up to the implementation using URIs makes
for greater flexibility. A generic implementation, e.g. within a web
browser, might always set the RD bit. Streamlined implementations
could set the RD bit when the default server is used (i.e., no
"hostport"), but clear the RD bit when a specific server is given in
"hostport". Special applications, that only use the URI to trigger
certain requests, could always clear the RD bit.
Other applications, that do not use the DNS protocol at all, could use
DNS URIs when displaying DNS zone files for a DNS administrator, and
need not worry about DNS-protocol specific parts of the URI. For this
application, the "hostport" string is simply used to find the server
view to look for the RR in.
Thanks again,
Simon