Subject: concerning draft-josefsson-dns-url-08.txt

From: Paul Vixie <[email-masked]>
Date: Thu, 26 Jun 2003 19:11:47 +0000

> 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 
> [email-masked] or [email-masked] 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".

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.

---

From: Zefram <[email-masked]>
Date: Thu, 26 Jun 2003 21:18:39 +0100

Paul Vixie wrote:
>PQ: the url scheme does not allow the RD bit to be set.

The draft says "A DNS URI designates a DNS resource record set ... by
domain name, type, class and server.".  That is, it identifies a location
within the abstract domain name space, a location which may contain
an RRset.  The setting of the RD bit doesn't affect which RRset is
designated; all it can affect is whether a query succeeds in returning
the requested RRset.  Nothing in the DNS URI so far refers to a specific
query mechanism, and indeed I can see reasonable uses for the URI form
that don't involve making any queries, via the DNS protocol or otherwise.

In summary, adding control of the RD bit would turn the DNS URI into
something else, something that I don't think it should be.

I see a couple of editorial nits, quite separate from the above:

0. The ABNF for <dnsqueryelement> uses "|" instead of "/" characters to
separate branches.

1. The grammar allows <dnsname> to be zero-length.

-zefram
-- 
Andrew Main (Zefram) <[email-masked]>

---

From: Paul Vixie <[email-masked]>
Date: 26 Jun 2003 23:02:09 +0000

> an RRset.

this statement would only be an answer to my concern if there were no way
to direct the query to a particular server using the "hostport" syntax.  if
we're going to give the URL syntax a way to designate a server other than
the one which is authoritatively responsible for the data, or a local caching
resolver (also called a "recursive nameserver"), then we need to be able to
set the RD bit.  personally, i like your answer better, but to reach that
answer we would have to remove the "hostport" syntax from the proposal.
-- 
Paul Vixie

---

From: Zefram <[email-masked]>
Date: Fri, 27 Jun 2003 10:00:58 +0100

Paul Vixie wrote:
>set the RD bit.

What I understand you saying in the above is that when querying a
non-authoritative nameserver we need to have RD=1 in the query so
that we'll get an answer even if the nameserver doesn't have the answer
already cached.  This is true, but it is a detail of the query mechanism;
why does it need to be represented explicitly in the URI?  Or, to put it
another way, what about the current URI definition requires queries to
be made with RD=0?  I'm not sure I've correctly understood what you've
said, so these questions might not make much sense.

My understanding of the hostport part of the syntax is that it allows
one to specify which server's view of the domain name space one will
look at.  (Particularly with split DNS, this makes a difference.)
Where it's not specified, presumably the default will be one's configured
recursive resolver, which actually is not necessarily accessed by the DNS
protocol over UDP as is implied where the hostport part is specified.
(The draft says "Unless specified in the URI, the server ("hostport")
is assumed to be locally known".)  You seem to see the default as being
whatever nameserver is authoritative for the data addressed by the URI,
which suggests that you have a radically different idea of the semantics
of the hostport syntax.  How do you see it working?

-zefram
-- 
Andrew Main (Zefram) <[email-masked]>

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 28 Jun 2003 00:31:05 +0200

Paul,

Thank you for the comments.  Answers inline below.

> are invalid, or by stating that the first or last dnsqueryelement

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.

> 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

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 28 Jun 2003 00:37:07 +0200

Andrew, I have incorporated your first suggestion, and for the second
one added some text to clarify that it was actually intended to allow
for zero length dnsname's (to denote the DNS root).  Let me know if
you believe further modifications would improve the document.  As for
the RD issue, I guess we agree.

   dnsname         = *pchar
                                ; See RFC 2396 for "pchar" definition
                                ; NB! Can be empty.

   dnsqueryelement = ( "CLASS=" dnsclassval ) / ( "TYPE=" dnstypeval ) /
                     ( 1*alphanum "=" 1*alphanum )

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 28 Jun 2003 01:55:28 +0200

Paul Vixie <[email-masked]> writes:

>> ...
>> ...
> very well.  then i request that you remove the "hostport" from the syntax.

The rationale being?

The hostport describes the authority that know the intended DNS
resource.  An authority is useful even for abstract, non-DNS-protocol,
DNS resources.  DNS resources themselves are indexed by (NAME, CLASS,
TYPE), but to distinguish between the answer that entity A
knows/generate, and the answer that entity B knows/generate, an
authority scope like "hostport" is needed.

Most applications probably will not care, and use the "default"
authority, trusting the local server to do the right thing.  But for
internal DNS environments, specifying the authority could be required.

I agree it is less confusing if the word "hostport" was avoided, and
the word "authority" is used instead.  Also, using the word
"authority" instead of "server" elsewhere would also improve matters.
I have made this change for the next revision, a snapshot is available
from <http://josefsson.org/draft-josefsson-dns-url.txt>.

Thanks,
Simon

---

From: [email-masked]
Date: Fri, 27 Jun 2003 17:45:53 -0700

Simon writes:
>or something else.

This is a can of worms at the bottom of a very steep rat-hole.  If you
would like to spend the time from now to Vienna (no sleeping, no breaks
for food!) reading email archives of folks bitterly arguing the finer points of
when a URI is a URL and when it is not, let me know and I'll send you
the pointers.  But let's not go back over that tired ground here.

 From my perspective, the *value* of this proposed URI scheme relates
to how well it can be used to point to things stored in the DNS.   Let's
focus on that, as the other uses are likely to be of marginal utility
compared to that.
			regards,
				Ted Hardie

---

From: Zefram <[email-masked]>
Date: Sun, 29 Jun 2003 19:37:09 +0100

Simon Josefsson wrote:
>for zero length dnsname's (to denote the DNS root).

This is technically correct, according to RFC 1034, but will be confusing.
"dns:" intuitively looks incomplete.  It's more conventional to name
the root domain in absolute form, as ".".  An interesting comparison:
the "dig" DNS lookup tool from the BIND folks doesn't accept "" as a
domain name; it insists on the root domain being specified as ".".

So I argue that requiring the root domain to be represented as "." in the
context of the URI, forbidding a zero-length <dnsname>, will make for a
clearer protocol, more likely to be implemented correctly.  This isn't
an absolute matter, though; both versions of the protocol are workable.

-zefram

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 29 Jun 2003 22:35:24 +0200

> an absolute matter, though; both versions of the protocol are workable.

The current specification allows for both dns: and dns:., and they
refer to the same thing, the root.  People used to dig syntax will
have no problems, and people working with strict RFC 1034 conforming
applications will also have no problems.  Is there a need to forbid
zero length dnsname's?  I don't see what benefit that would bring,
could you please elaborate?

Thanks,
Simon

---

From: Paul Vixie <[email-masked]>
Date: Sat, 28 Jun 2003 00:47:26 +0000

you said it best, earlier:

> >> ... Furthermore, DNS URIs do not require the use of the DNS protocol at
> >> all, it just denote a DNS resource. ...

a dns resource lives where its parent NS RRs say it lives -- and not, as
you also suggest...

> authority scope like "hostport" is needed.

...in the answers that different entities can generate.

> internal DNS environments, specifying the authority could be required.

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.  if you want to represent the query, you need RD and
hostport and lots of other things like the EDNS0 buffer size and so on.
if you want to represent a metatuple, then there can be no hostport since
the name itself gives rise to the places (either through recursion or not)
where the data can be found.

> from <http://josefsson.org/draft-josefsson-dns-url.txt>.

no, that won't fix the problem.  you have fundamentally got to choose whether
you are representing a query (which can have a hostpart but which ought to
also have RD, buffer size, and other options as defined in the future) or
or whether you are representing the data itself by specifying the name,
type, and class.  calling it an authority won't change the layering violation.

dns is a distributed, autonomous, coherent, reliable database.  a syntax
that allows entity A and entity B to speak incoherently about a given <qname,
qtype,qclass> would violate the coherency of the design.  the only exception
would be if you intended to be able to represent all attributes of a dns
query, which i think would be useless, but would allow hostport but require
RD, buffer size, and other EDNS OPT options to be invented later.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 27 Jun 2003 22:59:05 +0000

---

From: Zefram <[email-masked]>
Date: Mon, 30 Jun 2003 17:17:00 +0100

Paul Vixie wrote:
>the query itself.

I recognise what Paul describes as the layering violation, but I don't
think that it is sufficient to require that the <hostport> syntax
should go.  Information from two different layers is being presented
together, but the two layers are adjacent, so they can be treated as a
single layer when looking from the outside.  We have similar features in
other deployed URL types.  (By the way, I see the RD bit, and other things
Paul has mentioned, as being at a third layer, below the authority layer.
We can sensibly have authority location data without giving details of
the DNS query.)

What *is* a concern is that some URI schemes have much worse layering
issues, such as the overloading of the authority component in the http
URL scheme (the authority is used for both location and naming).  It is
arguable that having the <hostport> syntax in URI schemes encourages the
development of this kind of misfeature, and that this mixing of location
and naming data should be avoided for this reason.

This touches on an issue that I've been wondering about.  I'm not entirely
clear on what the <dnsqueryelement> extension mechanism is for.  What kind
of information might it represent?  If the URI scheme is intended purely
to represent a <name,type,class> tuple then there is no possible use for
the extension mechanism -- no additional information that one would ever
want to add to the tuple.  In considering reasonable usage scenarios I
came up with only one additional element that one might want to use: a
flag meaning "insist on the data being cryptographically authenticated".
On reflection, I think such a flag belongs in the authority section:
it's the same layer, and if we are going to include information at both
layers then I'd like to keep them syntactically separate.  Certainly this
flag should exist in the syntax iff the authority section exists.

Outside the context of any specific query elements, it seems that the
primary purpose (though, if there is an authority section, not the
sole purpose) of the URI scheme is to represent a <name,type,class>
tuple -- a location in abstract domain name space -- and, that being
a closed coordinate system, there is no additional element that can
usefully be added to that part of the URI.  I'd like to see a syntax
(either this URI scheme or a syntactically distinct part of it) to
express a pure <name,class,type> tuple, with no general extensibility.
If the URI scheme needs an extension mechanism, it should be separate
from the <name,class,type> syntax.

I have more opinions about how a distinct <name,class,type> tuple syntax
should look, which I'll save for a separate message, since this one is
dealing more with philosophical issues than concrete syntax.

Yet another protocol matter that hasn't been addressed so far: how are
domain name labels other than character labels (e.g., binary labels)
to be represented in the URI syntax?  Most applications that need to
represent these kinds of labels in character strings use the master file
format defined in the RFCs, but draft-josefsson-dns-url is quite clear
that it doesn't use that syntax.  It offers no syntax for binary labels,
and no extension mechanism for future label types.

-zefram

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 01 Jul 2003 03:51:18 +0200

> ...in the answers that different entities can generate.

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.

> using the <qname,qtype,qclass> tuple, or you're trying to represent

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.

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?

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 01 Jul 2003 03:58:23 +0200

> flag meaning "insist on the data being cryptographically authenticated".

The intention was to make sure future extensions aren't disallowed by
the syntax.  It could be used to indicate, e.g., that the RD flag
should be set or cleared, if someone do find it useful in the future,
and document it, and there is consensus for it.

> and no extension mechanism for future label types.

Can you elaborate?  The intention is that, e.g., a binary label with
the ASCII value 0x17 is expressed as dns:%17.  There are some text and
examples for this.

Thanks,
Simon