Subject: RE: Last Call: 'Domain Name System (DNS) Case Insensitivity Clari fication' to Proposed Standard

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 4 Feb 2005 05:16:53 -0800

> [mailto:[email-masked]] On Behalf Of D. J. Bernstein

> Mark Andrews writes:
> > The convention applies whereever domain names are entered.
> 
> Oh, really? I entered http://www.is\067.org into a browser 
> using your libresolv. Your web server responded with a ``Bad 
> Request'' message, rather than the www.isc.org web page.
> 
> I have no objection to this document _if_ it is limited to zone files.

This is exactly how it should be according to the HTTP URI specification.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Feb 2005 09:59:14 -0500

Please advance this draft.  It's concise, clear, defines the scope, 
and lays out the incompleteness of the original specification.  This 
document makes no changes.

My coding experience is in line with this draft.  This is how I 
interpreted case insensitivity.  I have no substantive disagreements 
with the draft.

Others have mentioned that the DNS style of representing non-ASCII 
printable (whatever you might want to call them) is not in line with 
other systems.  I do not believe that this is a germane issue.  The 
draft is not proposing a means to express these octets, merely 
describing the method in place since the 1980's.

The document is clear that it applies to the definition in RFC 1034 
and 1035, which is sufficient to limit the scope.  That URI's have 
what appear to be domain names in them is not an issue for DNS, it is 
an issue for that application area.

As for process, I have read this document before, and now again. 
Using my judgement, there is nothing innocuous in the draft, nothing 
that would make me want to go back and "diff' it to see if the editor 
changed something "behind the WG's back."  Given the simple nature of 
the document, it would take just a quick read of it to discover any 
"hidden" or "slipped in" problems.

PS.  I do somewhat agree that there is an editorial issue with "MAY" 
and may.  I would suggest completely dropping the reference to RFC 
2119 altogether.  The original documents (1034 and 1035) don't use 
the terms, trying to retrofit formality is difficult.  I have found 
this when editing the wildcard clarification document.

However, this is not an issue that should (SHOULD?) hold up progress.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

---

From: Roy Arends <[email-masked]>
Date: Fri, 4 Feb 2005 16:16:13 +0100 (CET)

On Fri, 4 Feb 2005, Edward Lewis wrote:

> Please advance this draft.

I concur.

Roy

---

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Feb 2005 10:24:14 -0500

As astute reader reported...

At 9:59 -0500 2/4/05, Edward Lewis wrote:
>judgement, there is nothing innocuous in the draft, nothing that would make

s/there is nothing innocuous in the draft/the draft is innocuous/

or something to that extent. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Feb 2005 23:21:50 -0000

> This is exactly how it should be according to the HTTP URI specification.

But Mark just told us that \067 means c ``wherever domain names are
entered.'' That's inconsistent in two ways with what actually happened:

   * The server did _not_ accept \067 as a substitute for c.
   * The client did _not_ convert \067 to c---which would have worked
     around the server's failure to accept \067.

I think that the client and server are just fine, and that Mark's
comment was a wild exaggeration.

I now see that the draft under discussion makes the same wild
exaggeration---it talks about all ``human readable and writable ASCII
contexts'' rather than just zone files. Consequently I object to the
draft as being blatantly inconsistent with (1) other IETF protocols,
notably HTTP and SMTP, and (2) many existing user interfaces, such as
the Firefox URL line and the qmail rcpthosts configuration-file format.

I also object to the entire notion of the IETF trying to constrain user
interfaces. If the IETF wants to define a zone-file format that can be
transferred by FTP, fine---and I'll be happy to defend the goofy use of
decimal in zone files for backwards compatibility---but the IETF has no
business making declarations regarding _all_ formats.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Feb 2005 23:21:23 -0500

>comment was a wild exaggeration.

Perhaps Mark's words are an overstatement.  Looking at RFC 2396 
(Uniform Resource Identifiers (URI): Generic Syntax), section 3.2.2 
(Server-based Naming Authority), this text is found (chopped up):

#   URL schemes that involve the direct use of an IP-based protocol to a
#   specified server on the Internet use a common syntax for the server
#   component of the URI's scheme-specific data:
#
#      <userinfo>@<host>:<port>
...
#   The host is a domain name of a network host, or its IPv4 address as a
#   set of four decimal digit groups separated by ".".  Literal IPv6
#   addresses are not supported.
...
#      host          = hostname | IPv4address
...
#   Hostnames take the form described in Section 3 of [RFC1034] and
#   Section 2.1 of [RFC1123]: a sequence of domain labels separated by
...
#   To actually be "Uniform" as a resource locator, a URL hostname should
#   be a fully qualified domain name.  In practice, however, the host
#   component may be a local domain literal.

I find it interesting that section 3 of 1034 is called out here.  The 
"\DDD" is not defined there, it is defined in RFC 1035 in section 5 
(MASTER FILES), specifically in 5.1 (Format).

 From this I would take it that an implementation operating on URLs 
would not be required to parse the \DDD.  An implementation could, 
under the mantra "liberal on receipt, conservative on send."

Still, there is no requirement that an implementation make the entire 
syntax available to the GUI.  An implementation is free to restrict 
what it allows to happen in a protocol, so long as it can speak 
(listen) the entire protocol.

>the Firefox URL line and the qmail rcpthosts configuration-file format.

"Wild exaggeration" is a bit melodramatic.  It's not like the draft 
is claiming it would cure the common cold.  But you have a point that 
it ought to stick to what is in zone files.  Overall, I think this is 
a rather inconsequential point though, as this abstract and 
introduction do refer to RFC 1034 and 1035 (and not 2396, for 
example).

>business making declarations regarding _all_ formats.

I can't make this leap in the argument.  I cannot see that the draft 
talks about user interfaces, just a (the original, standard) 
presentation format for DNS.

You are right that there should never be an IETF effort to restrict 
what can be in an implementation.  We should stick to what is needed 
for interoperability, while meeting requirements for functionality, 
operability, and simplicity.

With that in mind, there's a protocol reason I can think of for 
having a master file format defined.  The reason is this offers an 
alternative to zone transfers via port 53.  At one time (and may 
still be true) the root zone was "file transferred" and not 
[A|I]XFR'd.  The root servers are a mix of BIND and NSD, this 
wouldn't have been possible if NSD didn't have a Master File format 
to build to.  (One can argue that such an arrangement is outmoded I 
guess, with VPNs, TSIG, etc.  But changing an institutional practice 
is sometimes beyond the control of protocol wonks.)

Beyond the on-the-wire protocol, there are two reasons for specifying 
a master file formats.  It gives us a common language for discussing 
the protocol on a list like this.  It also makes it easier to staff a 
DNS operations center - because there is a pool of people (or firms) 
that will be able to start "right away."

Other than that, I don't think master files are important as they do 
not get passed around on port 53.

It is important to remember that IETF specifications are for 
interoperability.  An implementation is free to exceed the 
specifications, but exceeding it without extending the specification 
does not guarantee interoperability.

As a customer for DNS software, I want to know that any 
implementation I decide to deploy would be compatible with my 
installed base so that I do not need to have a flag day should I 
choose to migrate.  I wouldn't object to an implementation with 
non-standard features, but I would refrain from using them unless it 
was really compelling to do so.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 07 Feb 2005 10:14:58 +1100

> (Server-based Naming Authority), this text is found (chopped up):

	I stand by my words.  URLs take hostnames.  RFC 2396 just
	described the subset of hostnames that are representable in
	the DNS.

	The encoding applies to applications which take domain
	names.  Most applications, including web browsers, take
	hostnames.  The fact that you can represent most (but not all)
	hostnames in the DNS just adds to the confusion.

	Hostnames of length 254 and 255 cannot be represented in the DNS.

	I don't expect a application that takes a hostname to accept
	\DDD.  I do expect a application that takes a domain name to
	accept \DDD.

	Mail clients take hostnames and/or mail domains (which are
	syntactically identical to hostnames).

	Telnet, ssh, ftp etc. take hostnames.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 7 Feb 2005 07:11:53 -0000

This document specifies \065 as a synonym for capital A---not just in
zone files, but in all ``human readable and writable ASCII contexts.''

That specification is plainly erroneous. Nobody is willing to defend the
notion that this screwy decimal system should be allowed in URLs, SMTP
RCPT, etc.

The obvious fix is to limit the document to zone files.

---

From: Peter Koch <[email-masked]>
Date: Tue, 08 Feb 2005 14:33:56 +0100

Mark Andrews <[email-masked]> wrote:

{IESG removed from Cc}

> 	described the subset of hostnames that are representable in

RFC 2396 has recently been obsoleted by RFC 3986. That now uses a Thingy
Formerly Known As Hostname.

> 	Hostnames of length 254 and 255 cannot be represented in the DNS.

Yes, but "domain names" of length 254 or 255 cannot either - due to the fact
that the wire format needs two more octets than the FQDN text representation.

> 	\DDD.  I do expect a application that takes a domain name to

Now it may be time to dig out your long since expired Internet Draft again ...

> 	Telnet, ssh, ftp etc. take hostnames.

Weird enough they should use IDNs - at a different layer, though.

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Feb 2005 11:33:51 -0500

>Formerly Known As Hostname.

Thanks.  (I wish they'd note "obsoleted-by" on the older RFCs. 
Googling often misses the new ones.)

The updated text isn't materially different than the old, although 
it's a lot more specific, "section 3.5" instead of just 3.  Getting 
into document lawyering (i.e., career preservation), I'm more 
convinced that \DDD isn't intended to be legal URI syntax.

Looking at this, which is the comment that is prolonging the thread...

>The obvious fix is to limit the document to zone files.

Here is the text in the document:

# 2.1 Escaping Unusual DNS Label Octets
#
#    In Master Files [STD 13] and other human readable and writable ASCII
#    contexts, an escape is needed for the byte value for period (0x2E,

Note that the draft does not say "all" but rather "and other."  I 
don't see a need to edit this.  It's not an exclusive statement.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Feb 2005 07:52:34 +1100

> that the wire format needs two more octets than the FQDN text representation.

	The length of domain names has always been defined in terms of the
	uncompressed wire length.  The presentation format can go to 1004
	characters.
 
> Weird enough they should use IDNs - at a different layer, though.

	What this document is talking about is the DNS (that big replicated
	distributed database) and how you represent domain names in
	it.  In the tools that manipulate it.

	It has NOTHING to do with how hostnames are represented.
	The fact that you can store and retrieve hostnames from it
	is irrelevent as it is at a totally different layer.

	IDN exist at a layer about the DNS.  They are transformed to
	and from DNS labels.

---

From: Danny Mayer <[email-masked]>
Date: Tue, 08 Feb 2005 21:50:56 -0500

At 11:33 AM 2/8/2005, Edward Lewis wrote:
>Thanks.  (I wish they'd note "obsoleted-by" on the older RFCs. Googling 
>often misses the new ones.)
>
>The updated text isn't materially different than the old, although it's a 
>lot more specific, "section 3.5" instead of just 3.  Getting into document 
>lawyering (i.e., career preservation), I'm more convinced that \DDD isn't 
>intended to be legal URI syntax.

URI's are described in RFC 1808 Section 2.1 and 1738 Section 3.1 which
describes the host part of the URI this way:

     host
         The fully qualified domain name of a network host, or its IP
         address as a set of four decimal digit groups separated by
         ".". Fully qualified domain names take the form as described
         in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
         [5]: a sequence of domain labels separated by ".", each domain
         label starting and ending with an alphanumerical character and
         possibly also containing "-" characters. The rightmost domain
         label will never start with a digit, though, which
         syntactically distinguishes all domain names from the IP
         addresses.

I happened to have grabbed it today to deal with another unrelated
matter.

Looks like escaped digits are not allowed in host names and domain
names. There's nothing in either Section 3.5 of RFC 1034 or Section 2.1
that mentions it.

Does that clarify things?

Danny

---

From: Alex Bligh <[email-masked]>
Date: Wed, 09 Feb 2005 10:36:39 +0000

> Does that clarify things?

Not really as going back to the previous question, that leaves domain
names having case "in them", but being compared case insensitively for
DNS applications, but (unless it's elsewhere) no such prescription on
the host part of URI's. I think all you've shown is that DJB's
"typing things into browser bar"'s example is insufficient to prove
his point, as the escape sequence itself may have been (correctly)
passed in the wire-format URI rather than the capital letter he (I think)
intended.

Alex

---

From: Danny Mayer <[email-masked]>
Date: Wed, 09 Feb 2005 22:01:18 -0500

>passed in the wire-format URI rather than the capital letter he (I think)

I agree, but then you didn't need my reference for this observation as it
has nothing to do with DNS, just with browsers and perhaps http servers.

Danny