Subject: On the URI/DNS last calls

From: Robert Elz <[email-masked]>
Date: Wed, 07 Apr 1999 06:51:59 +1000

Three docs related to URIs and their use of the DNS are currently
in last call.   They're all closely related.  This message makes
some comments on all 3.

The first is draft-ietf-urn-net-procedures-02.txt - this specifies
procedures for registering names in the uri.net domain.   I have no
specific comments upon this one, though I'd be surprised if the IANA
were to agree to monitor a mailing list and determine when consensus
has been arrived at.

The others are draft-ietf-urn-naptr-rr-02.txt and
draft-urn-dns-rds-00.txt.

The first of those defines a new (NAPTR) RR for the DNS, and the
second specifies how that is to be used.   Or I think that's the
intent, it actually seems as if both of them do both tasks - there
is considerable duplication of content in the two drafts, not all
of it completely consistent (perhaps partly just by omission of
all of what is in the other draft).   On the other hand, neither
draft really contains enough information to be used alone.   Perhaps
these two should just become one document, it would be much smaller
that the sum of the sizes of the two - much of the text seems to
be identical in both drafts.

I'm sure the IESG will note this anyway, but just for completeness,
both of these drafts contain normative references to rfc2052.  That's
an experimental RFC, these two are aimed at PS - that's a violation
of the who can refer to what rules I believe.   An update to rfc2052
which will be PS is currently in the DNSIND working group (it has
previously undergone IETF last call, and was sent to the IESG for
approval, but was sent back to the working group from there).   I
believe that these drafts need to wait until 2052bis has gained IESG
approval.

In 2052bis the SRV record procedures are defined such that the names
looked up contain underscores ahead of the protocol and transport
fields (as in _telnet._tcp...)   The naptr-rr draft has followed
that convention, the dns-rds draft has not, leading to examples in the
two drafts which are similar, but just that little bit different.

2052 (and 2052bis) assume that a SRV client will know a protocol,
a transport, and a domain at which that protocol/combination is
sought, and will construct the DNS name to be sought from this
information.  The URI drafts instead build the complete DNS label
to be used for a SRV lookup into the NAPTR record.   That's not
necessarily a bad thing, and doing it this way, there is no real
demand for the underscores to be present (there's no real reason for
the components of the label to even contain anything that remotely
resembles protocol (service) and transport protocol labels) - all that
is required is that the appropriate SRV record be present in the DNS.

I believe that the URI draft(s) need to say more about exactly how this
is to be used, especially as it doesn't really fit the assumptions of
the SRV docs about how SRV will be used.

The two drafts are inconsistent about whether DNS name compression can be
used on the domain name field of the NAPTR record.  The naptr-rr draft
says it can't (until some other doc permits it explicitly) which is
correct.  The dns-rds draft suggests it can, if the server has some means
of knowing that the resolver understand it, which is completely bogus,
that simply doesn't work.

One of the less clear parts of both drafts is how the order and preference
fields are to be used.  Both drafts make it quite clear that correct
ordering of the records returned is essential for correct operation
of the protocol.   That's fine.   However, how the order is established
and used is less clear.   The naptr-rr draft suggests that the NAPTR RRset
is simply sorted based upon order, and then preference, and then consumed in
order, stopping at the first match.  It gives no guidance what should be
done when records sort equally.  The dns-rds draft suggests thet the
RRset is sorted based upon the order field, consumed in order until
there's a match, at which point RR's of equal order can be considered
(according to the preference) but no higher order RRs.   These are similar,
but (unless I have been confused, in which case I'd suggest the text needs
some clarification), not quite idential (the difference being exactly when
oine is required to stop looking when a group of records has equal order,
but different preference, and one (with intermediate preference) "matches".

Both drafts say that the way the drafts are ordered based upon preference is
really at the discretion of the client.   I'm not sure exactly how that's
intended to be used, or exactly how a DNS adminstrator could managed to set
preference values in that environment - perhaps the preference field is
really achieving nothing of value, and ought just be deleted?

The naptr draft says that after a substitution, the host name produced
should be checked to see if it is "legal", but gives no clue as to what is
intended to be legal in this context.   That's even assuming that one
can justify calling anything involved in this pocess a "host" name in
any way at all.  All there is really is a series of indirections through
the DNS to produce (eventually) an IP address and port number, given a
URI as input.   There need not necessarily ever be anything which would
normally be considered as a host name (and certainly not in a NAPTR record).
Domain names on the other hand there are by the bucketload, but there's
no concept of a "legal" domain name in the dNS (other than that it must
meet some restrictions upon length).

The naptr-rr draft simply plucks the names "uri.net" and "urn.net" (and
for that matter, "e164.int") out of the air with no explanation.
The dns-rds draft does explain what is going on there (though I have
no idea where the e164.int label comes from - that's supposedly an example
of NAPTR in a non-URI context, but it seems very under done).  Assuming
the drafts aren't simply combined, the naptr-rr needs a reference to
the dns-rds draft at the point where the uri.net and urn.net names are
first mentioned, so the reader can figure out what is going on.   That's
expecially important if the intent of having the drafts separate is so that
the NAPTR record can be used for non-URi purposes - something needs to
explicitly say how the name for the first NAPTR lookup is obtained (in
the naptr-rr doc).   That might simply mean saying "must be defined where
an alternate use of NAPTR is defined, and refer to the dns-rds draft
as an example of how that ius done, for the URI case - but something needs
to be said.

The naptr-rr draft refers to the magic tokens "<domain-name>" and
"<character-string>" without ever defining them.   I believe they're
intended to duplicate the equivalent terms used in rfc1035, but this
doc doesn't actually say that.   Even if it did, 1035 managed to
aviod actually defining those terms in any case, it simply assumes
that the reader can figure out what it means.  This doc also doesn't
seem to even notice the 256 byte limit on a <character-string> in 1035.
That might never be relevant to anything here (certainly it isn't likely
to be for the flags field, and it seems pretty unlikely for the service
field, but regular expressions (with substitution strings) can grow
towards that kind of length - the naptr-rr draft at least needs to note
that the limit exists, and warn users that they need to live within it.

The naptr-rr doc claims that none of the character string fields can
contain spaces.   Since it fully defines the flags and service fields,
that's fine.  But the regular expression is much less defined, there
is certainly no geneal prohibition of spaces in REs.   If NAPTR weas
restricted to URIs, then perhaps, but it seems that the intent is to
allow it to be used for more than URIs - since we don't know what that
more will eventually be, I can't see how anyone can pretend that spaces
will never occur.   Even for URI's, since spaces neevr occur in the
data, it would seem that space would be an ideal delimited character to
use for the regular expression (it meets all the rules).

Further, it is unclear why it matters is space is included in any of
these fields or not - all that means is that the space (or entire string)
needs to be quoted in the DNS master file.   All the examples show the
strings quoted in any case, and wel know that if all the examples show
something done in a particular way, that's what everyone is going to copy.
I see no need for the draft to attach any special significance to spaces
at all.   They're certainly not the only thing that needs to be quoted
in master files.

Fixing that would allow the paragraph that mentions this to be re-written,
whch could not but help improve its clarity.   It currently mentions
"Regexp" twice, and reads as if the two refer to different things.

   The Flags and Services and Regexp
   fields are all <character-string>s that cannot contain spaces and
   thus can be included in their above specified form. While the
   Regexp field is also a <character-string> it can contain
   numerous backslashes and thus should be treated with care.

It first says that the Regexp field is a character string and this can
be included in "the above specified form" (which I am not sure really
is specified, but never mind).  Then "While the Regexp field is also
a <character-string> ..."  Maybe it is just the "also" but to me this
reads very poorly.   It also doesn't say what "treated with care"
really means - which is, backslashes muct be entered twice.   That is
if someone does write them as specified in other places in the doc,
the sequence \1 is going to be turned into a control-A, which isn't
going to be useful, it needs to be written \\1 instead.    It does
say that in the "advice to domain administrators", but this is really
more than advice.

If it wouldn't cause confusion, I'd recommend substituting the \ and .
chars in the regular exp into something with less overloaded meanings
That is perhaps say that for this purpose, ',' matches any single character,
and '&' or something is the escape character.   It would make getting
the syntax in zone files right far easier.   But perhaps it might just be
too confusing, and dealing with all the escaping may actually be less
error prone.   Maybe.

Both docs contain examples written in a format which looks very like DNS
master file format, but in all but one example, omit the required trailing
'.' after a fully qualified domain name in DNS master zone files.  The
dns-rds doc atually mentions that this is being done explicitly, and that
the '.' would have to be added in zone files (the naptr-rr doc, which
contains te oen example that does contain the dots, says nothing about
this at all).   Missing trailing dots are perhaps the most common DNS
configuration error (easily spotted and fixed if an actual DNS exchange
is monitored, but DNS zone admins tend to look only at their master
zone file, and there the missing dot is much harder to spot).   Giving
examples in a doc like this which omit the trailing dot is inexcusable,
and claiming that this is being done as what is being shown is the output
from a query, rather than the master file format is a cop-out that should
not be tolerated.   Having the one example with the dots makes it worse.

Aside from these matters of some substance, there are some errors in the
docs that ought be fixed (more than mere spelling, etc).

The naptr-rr doc contains an example that begins with the line [sic]

	 gatech.edu IN NAPTR

That can't be right, the "IN NAPTR" part looks superfluous.  

The dns-rds draft shows how \ escaping needs to be used to quote all
the \s that need to appear in the regular expressions.   Unfortunately
it gets it wrong, and shows

	"/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i"

as input producing

	/urn:cid:.+@([^.]+\.)(.*)$/\2/i

as the actual string transmitted in the DNS packet (what the client
eventually receives).   What it should be is

	/urn:cid:.+@([^\.]+\.)(.*)$/\2/i

Hwoever, as I understand the RE quoting rules, that \ that was
missing in the output isn't needed in any case, and should probably
just be dropped (the \\) from the input case instead.

I would suggest to the IESG that these two drafts be returned to the
working group for quite a bit more work (I eventually gave up looking
for problems in the drafts, there migt be more thanthis message suggests).

kre

---

From: Keith Moore <[email-masked]>
Date: Tue, 06 Apr 1999 19:11:49 -0400

kre,

thanks for your thoughtful comments.  I will ask that the documents
be sent back to the WG to consider them.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 06 Apr 1999 19:11:49 -0400

kre,

Keith