Domain Name System (DNS) Case Insensitivity Clarification
RFC 4343

Note: This ballot was opened for revision 06 and is now closed.

(Margaret Cullen) Yes

(Brian Carpenter) No Objection

(Bill Fenner) No Objection

(Sam Hartman) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

Comment (2005-03-30 for -)
No email
send info
Comment from the Ops directorate by (Pekka Savola) (Mar 30 17:47:13 PST 2005):

Allison raises a good point about whether we want to force this
behaviour on all the future CLASSes as well or not.  I don't have
strong opinion either way, but it would seem that differently aged
implementations would probably result in inconsistent behaviour if the
type case insensitivity (or not) was CLASS-specific (because
implementations don't require changes to serve new CLASS types, while
the case insensitivity per class would break that model).

Major issue:

 - the document seems to be suggesting very dubious procedures,
leading to inconsistent results.  Unless I'm misunderstanding
something, we should NOT accept something like this.  Section 4.2

"Thus the case of ASCII
 labels is preserved if they are for nodes being created. However,
 when a name label is input for a node that already exist in DNS data
 being held, the situation is more complex. Implementations may retain
 the case first input for such a label or allow new input to override
 the old case or even maintain separate copies preserving the input

If I read this correctly, the zone file could include "
A" and " A", and depending on the case
of the query, the results could be very inconsistent.  This problem is
amplified by the fact that the output case insensitivity is not
preserved.  So, for example, caching resolvers or root/xTLD servers
could end up changing the case pretty arbitrarily, without the stub
resolver being able to do anything about it.

This appears to be an unacceptable situation.  Instead, the existing
case should be kept or updated, but there never ever should be two
different casings for the same name.  This may call for a MUST NOT.


Not quite as major:

 - section 2 is a nice introduction to the topic but left me
wondering.. because the text has very little to do with case
insensitivity as such.
It seems that maybe thename of the document be changed to something
more generic like "DNS Name Presentation and Processing
Clarifications", and ripple through the abstract and introduction ?

This is important particularly because the document is not clear
enough which parts of the document are meant as normative (updating
1034/1035) and which parts are just informative text.  If section 2
has normative elements, the fact should be more clearly presented in
the name of the document as well.

Editorial issues:

 - the document uses a number of
   addresses/names, but in this case this seems justifiable
 - the IPR boilerplates and disclosures at the end are missing
 - the historical note in section 3 could probably be removed.  This
   is not the 70's anymore, and the original specs also talk about
   character case.  Or if you want to keep it because that's why it may
   be written in the [ASCII] reference, just say something like "upper
   case ("majuscule" in [ASCII]) ..."
 - this sentence in 4.1, especially the start of it, is difficult to
   follow.  Consider rephrasing:
   ASCII output is as
   if a name was marshaled by taking the label on the node whose name is
   to be output, converting it to a typographically encoded ASCII
   string, walking up the tree outputting each label encountered, and
   preceding all labels but the first with a period (".").
 - in references, draft-ietf-dnsext-unknown-rrs-05.txt has been
   published 18 months ago as RFC 3597. (Kinda speaks of the amount of
 - the changelogs at the end should be clearly marked to be removed by
   the RFC-editor before publication.

(Allison Mankin) (was Discuss) No Objection

Comment (2005-09-10)
No email
send info
My Discuss was written 3/30, the revision appeared 7/20, and I guess
due to my travel and vacation schedule I did not respond to the tracker
notes of update.  I've cleared my Discuss on a message from Margaret showing
the changed text, 9/9/05.  The changed text handles my concern very well:

    The handling of DNS label case is not CLASS dependent. With the
    original design of DNS, it was intended that a recursive DNS resolver
    be able to handle new CLASSes that were unknown at the time of its
    implementation. This requires uniform handling of label case
    insensitivity. Should it become desireable, for example, to allocate
    a CLASS with "case sensitive ASCII labels" for example, it would be
    necessary to allocate a new label type for these labels.l

My comment from March 30 seems not addressed, have
asked if a note to the RFC Editor is possible:
In the Security Considerations, the term "RP" should
be expanded, and the reference to RFC 1183 (if that's
the best one) given.

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection