Subject: RE: Last Call: ... Case Insensitivity Clarification ...

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

--
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: 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

Hallam-Baker, Phillip writes:
> 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.