Subject: Re: draft-ietf-dnsext-insensitive-02.txt

From: Donald Eastlake 3rd <[email-masked]>
Date: Tue, 1 Apr 2003 09:25:50 -0500 (EST)

Andreas,

Thanks for the comments. See responses below:

On Thu, 20 Mar 2003, Andreas Gustafsson wrote:

> Date: Thu, 20 Mar 2003 16:16:29 -0800 (PST)
> From: Andreas Gustafsson <[email-masked]>
> Subject: draft-ietf-dnsext-insensitive-02.txt
> 
> A couple of issues with draft-ietf-dnsext-insensitive-02:
> 
> First of all, the draft seems much longer than it needs to be.  Keep
> in mind that the draft arose from the following request from Erik
> Nordmark:
> 
>    [...] it would be quite helpful to point out that the DNS servers notion
>    of "case" is limited to octets that are in the ASCII range.
>    Otherwise folks will continue to discuss what case sensitive means
>    for octet values >128.
> 
> That could be said in a single sentence.  The text on classes and
> extended label types in sections 3.1-3.2 are useful additional
> clarifications, but there is no real need for an extended treatment
> that at best repeats what is already said in STD 13 and at worst
> conflicts with it, or for historical notes on the development of
> movable type.

My goal in the draft is to be excruciating clear. If you assume clueful
readers, nothing is needed in addition to STD 13. This draft tries to
fill in some background and explain relevant points as precisely and
clearly as possible, even at the expense of some redundancy, and not
assuming the reader can make any but the most simple deductions from
general principles.

I'll see if I can tighten up the wording a little bit.

>    2.1 Escaping Unusual DNS Label Octets
> 
> The purpose of section 2.1 is unclear.  Is it merely defining the
> notation used for domain names in the remainder of the draft (if so,
> why not simply refer to RFC1035 section 5?), or is it intended as a
> clarification or update to RFC1035 section 5?
>
>    Originally, DNS input came from an ASCII Master File as defined in
>    [STD 13]. DNS Dynamic update has been added as a source of DNS data
>    [RFC 2136, 3007]. When a node in the DNS name tree is created by such
>    input, no case conversion is done and the case of ASCII labels is
>    preserved if they are for nodes being created. However, no change is
>    made in the name label on nodes that already exist in the DNS data
>    being augmented or updated.
>    [...]
>    The same considerations apply when inputting multiple data records
>    with owner names differing only in case. From the example above, if
>    an "A" record is stored under owner name "xyz.BAR.example" and then a
>    second "A" record under "XYZ.BAR.example", the second will be stored
>    at the node with the first (lower case initial label) name.
> 
> I have a problem with this text.  It seems to imply that
> implementations must not, and do not, update the character case of
> existing labels in the database when they receive new data having a
> different character case (e.g., in a dynamic update), but such
> updating is not forbidden by STD 13.  One could even argue that
> updating the case would be desirable since the most recently added
> data are more likely to reflect the administrator's current
> preferences regarding character case than the oldest data.  I would
> like the draft to be changed to say that the final node may have the
> character case of either the initial name or the new name, assuming
> this text needs to be there at all.

OK, that's a good point and I will change the draft there.

> Another issue that needs to cleared up is whether the text in RFC1035
> section 2.3.3 saying
> 
>    In general, this preserves the case of the first label of a domain
>    name, but forces standardization of interior node labels.
> 
> should be interpreted as saying that the character case of interior
> node labels MAY be standardized by the server or that it MUST be
> standardized.  The draft seems to be assuming a MUST, but I would
> strongly suggest an interpretation of MAY.  Making it a MUST would
> severely limit the options of implementers without offering any
> benefit in return.  For example, it would outlaw implementations that
> store a separate copy of the complete owner name with each RRset.

Hummm, it is my impression that all implementations thus far have 
standardized but I believe you are correct in saying this is not 
required by the standard. I'll change that also.

Thanks,
Donald
======================================================================
 Donald E. Eastlake 3rd                       [email-masked]
 155 Beaver Street              +1-508-634-2066(h) +1-508-851-8280(w)
 Milford, MA 01757 USA                   [email-masked]

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