Skip to main content

Domain Name System (DNS) Case Insensitivity Clarification
draft-ietf-dnsext-insensitive-06

Revision differences

Document history

Date Rev. By Action
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Allison Mankin
2005-09-19
06 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-09-12
06 Amy Vezza IESG state changed to Approved-announcement sent
2005-09-12
06 Amy Vezza IESG has approved the document
2005-09-12
06 Amy Vezza Closed "Approve" ballot
2005-09-12
06 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2005-09-10
06 Allison Mankin
[Ballot comment]
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 …
[Ballot comment]
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.
2005-09-10
06 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Discuss by Allison Mankin
2005-07-27
06 Margaret Cullen Note field has been cleared by Margaret Wasserman
2005-07-20
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-07-20
06 (System) New version available: draft-ietf-dnsext-insensitive-06.txt
2005-04-06
06 Michelle Cotton IANA Comments:
We understand this document to have no IANA Actions.
2005-04-01
06 (System) Removed from agenda for telechat - 2005-03-31
2005-03-31
06 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2005-03-31
06 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2005-03-31
06 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2005-03-31
06 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-03-31
06 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2005-03-30
06 David Kessens
[Ballot comment]
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 …
[Ballot comment]
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
says,

"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
case."

If I read this correctly, the zone file could include "foo.example.net
A 1.2.3.4" and "FOO.example.net A 5.6.7.8", 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 non-example.com/192.0.2.0
  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
  review..)
- the changelogs at the end should be clearly marked to be removed by
  the RFC-editor before publication.
2005-03-30
06 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-03-30
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2005-03-30
06 Allison Mankin [Ballot comment]
In the Security Considerations, the term "RP" should
be expanded, and the reference to RFC 1183 (if that's
the best one) given.
2005-03-30
06 Allison Mankin
[Ballot discuss]
The document seems to be putting a mandate on potential
future development of CLASSes

  "The handling of DNS label case is not …
[Ballot discuss]
The document seems to be putting a mandate on potential
future development of CLASSes

  "The handling of DNS label case is not CLASS dependent."

Chaos and Hesiod CLASSES appear in the IANA registry; not that it
that it matters to my main point, but maybe someone knows:
is Chaos entirely dead, or just mostly dead?  and
is it case-insensitive?

The real point is that there are occasionally ideas for how
one might use a new CLASS and those might want to consider a format
not to be bound by this document.
(For the pros/cons on CLASS, I see recent guidance in
draft-iab-dns-choices-01.txt).

Can the sentence I've noted be deleted?
It's very terse, does it mean what it seems: that in
any CLASS, ASCII label classes must be case-insensitive,
as described in the document?
Does the working group want this?
If not, what does it mean?
2005-03-30
06 Allison Mankin
[Ballot discuss]
The document seems to be putting a mandate on potential
future development of classes:
 
    The handling of DNS label case …
[Ballot discuss]
The document seems to be putting a mandate on potential
future development of classes:
 
    The handling of DNS label case is not CLASS dependent.

Also the draft incorrectly states that the only CLASS defined is IN.  It
should emulate draft-iab-dns-choices-01.txt and state that the only
one widely deployed is IN.  Chaos and Hesiod both appear in the IANA
registry; not that it matters to my point, but is Chaos entirely
dead or just mostly dead, and is it case-insensitive?
The real point is that there are occasionally thoughts about how one
might use a new CLASS and they might want to consider a format
not to be bound by this document.

Is the right thing to delete the sentence I've quoted? 
What was the working group discussion on this?
2005-03-30
06 Allison Mankin
[Ballot discuss]
The handling of DNS label case is not CLASS dependent.
Why would other not-yet-defined global CLASSes necessarily use the same
handling, which is …
[Ballot discuss]
The handling of DNS label case is not CLASS dependent.
Why would other not-yet-defined global CLASSes necessarily use the same
handling, which is this sentence's implication?
2005-03-30
06 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2005-03-30
06 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-03-29
06 Allison Mankin
[Ballot discuss]
The handling of DNS label case is not CLASS dependent.
Why would other not-yet-defined global CLASSes necessarily use the same
handling, which is …
[Ballot discuss]
The handling of DNS label case is not CLASS dependent.
Why would other not-yet-defined global CLASSes necessarily use the same
handling, which is this sentence's implication?
2005-03-29
06 Allison Mankin [Ballot Position Update] New position, Discuss, has been recorded for Allison Mankin by Allison Mankin
2005-03-27
06 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2005-03-21
06 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-03-20
06 Margaret Cullen Placed on agenda for telechat - 2005-03-31 by Margaret Wasserman
2005-03-20
06 Margaret Cullen State Changes to IESG Evaluation from Waiting for Writeup by Margaret Wasserman
2005-03-20
06 Margaret Cullen [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman
2005-03-20
06 Margaret Cullen Ballot has been issued by Margaret Wasserman
2005-03-20
06 Margaret Cullen Created "Approve" ballot
2005-03-11
06 Mark Townsley Shepherding AD has been changed to Margaret Wasserman from Thomas Narten
2005-02-15
06 (System) State has been changed to Waiting for Writeup from In Last Call by system
2005-02-01
06 Amy Vezza Last call sent
2005-02-01
06 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-02-01
06 Thomas Narten State Changes to Last Call Requested from AD Evaluation by Thomas Narten
2005-02-01
06 Thomas Narten Last Call was requested by Thomas Narten
2005-02-01
06 (System) Ballot writeup text was added
2005-02-01
06 (System) Last call text was added
2005-02-01
06 (System) Ballot approval text was added
2005-01-31
05 (System) New version available: draft-ietf-dnsext-insensitive-05.txt
2005-01-25
06 Thomas Narten [Note]: '2005-01-25: AD review raises some questions, then to IETF LC.' added by Thomas Narten
2005-01-25
06 Thomas Narten
From: Thomas Narten
To: Olafur Gudmundsson , Olaf Kolkman
cc: Rob Austein , Donald.Eastlake@motorola.com
Date: Fri, 21 Jan 2005 07:41:39 -0500
Subject: AD review of …
From: Thomas Narten
To: Olafur Gudmundsson , Olaf Kolkman
cc: Rob Austein , Donald.Eastlake@motorola.com
Date: Fri, 21 Jan 2005 07:41:39 -0500
Subject: AD review of draft-ietf-dnsext-insensitive-04.txt

I just reviewed this and have no major issue. But in reading it, I'm
not sure what the purpose of this  document actually is. Is it
updating/clarifying an existing RFC? If so, which one(s)?

Is there some new requirement specified here (e.g., special handling
of '\' in master files?)

In order for this to  be on standards track, it needs to update a
standards track doc (I think) and/or specify something that folks must
implement, that previously they didn't. Or some such.

Note that the abstract says:

  This clarification should not have any interoperability
  consequences.

That begs the question of is being standardized.

Detailed comments/nits:

>    within a label. The second one show a 5 octet label where the second

s/5 octet/5-octet/

>    The design decision was made that comparisons on name lookup for DNS
>    queries should be case insensitive [STD 13]. That is to say, a lookup
>    string octet with a value in the inclusive range of 0x41 to 0x5A, the

Might be good to clarify: case insensitive for _all_ queries, or for
specific RR types (e.g., "name lookup")? (I assume the latter, and I
guess it would be hard to read the rest of the document otherwise...)

>    folding specified in iso-8859-1 or iso-8859-2. For example, the

Cite these in references?

>    DNS labels in wire encoded names have a type associated with them.

s/wire encoded/wire-encoded/

>    above is done. Thus such optimization MAY easily destroy the output

s/MAY/may/ ? (doesn't seem like  a MAY per 2119 definition)


Thomas
2005-01-21
06 Thomas Narten State Changes to AD Evaluation from Publication Requested by Thomas Narten
2005-01-21
06 Thomas Narten Intended Status has been changed to Proposed Standard from None
2005-01-21
06 Thomas Narten
Email from 2004-11-10:

From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair
To: Thomas Narten
Cc: namedroppers@ops.ietf.org, Margaret Wasserman ,
  ogud@ogud.com, "Olaf M. Kolkman" , iesg-secretary@ietf.org
Date: …
Email from 2004-11-10:

From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair
To: Thomas Narten
Cc: namedroppers@ops.ietf.org, Margaret Wasserman ,
  ogud@ogud.com, "Olaf M. Kolkman" , iesg-secretary@ietf.org
Date: Wed, 10 Nov 2004 11:04:00 -0500
Subject: Document advancement DNSEXT: Case Insensitive


Thomas,

Please advance Case Insensitive clarification on the standards track:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-04.txt.

1. Have the chairs personally reviewed this version of the ID
and do they believe this ID is sufficiently baked to forward
to the IESG for publication?

Yes, we have read this document and it has been reviewed and
revised.


2. Has the document had adequate review from both key WG members
and key non-WG members?  Do you have any concerns about the depth
or breadth of the reviews that have been performed?

Yes, key members of DNSEXT a have read this document.
As this document was created to address a narrow non-controversial
issue that was from identified during the review of RFC3597, this issue
has clear base and purpose.


3. Do you have concerns that the document needs more review from
a particular (broader) perspective?

In theory this document should be reviewed by people that are experts
in non English languages as it border line touches on how these are
represented in DNS. But as IDN has addressed that there is no further
review needed.


4. Do you have any specific concerns/issues with this document
that you believe the ADs and/or IESG should be aware of?

The only concern with the document, is that the educational/background
sections may draw more interest and discussion than the actual DNS
Protocol content of the document.


5. How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The working group consensus is solid. The WG has only raised issues with
the semantics and structure of the document not content.


6. Has anyone threatened an appeal or otherwise indicated
extreme discontent?  If so, please summarize what are they upset about.

No

7. Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).

The document adheres to most of the ID nits with the exception that
some of the IPR statements required by RFC3668 are non compliant.
There are no IPR issues possible with this document.
We request that the editor  fix the IPR statement at the same time as he
addresses any nits brought up during AD review.


8. Does the document a) split references into normative/informative,
and b) are there normative references to IDs, where the IDs are
not also ready for advancement or are otherwise in an unclear state?

References are split, and all normative references are RFCs.

9. For Standards Track and BCP documents, the IESG approval
announcement includes a write up section with the following
        sections:

Technical Summary:
    RFC1034/5 was written when US-ASCII was the only language used on
    on the Internet. For this reason some corner cases related to case
    folding where not thought out. This document nails down these corner
    cases. The action of the document is to explicitly say only
    case folding only applies to letters in the A-Z range.
    This is the only guaranteed 100% inter operable solution.

Working Group Summary

    The document being advanced has been reviewed, it is non-controversial
    and will not change any implementations or practices.

Protocol Quality:
    This is quality document. The protocol change is minimal.


Olafur & Olaf


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
2005-01-21
06 Thomas Narten Intended Status has been changed to Proposed Standard from None
2005-01-21
06 Thomas Narten
Email from 2004-11-10:

From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair
To: Thomas Narten
Cc: namedroppers@ops.ietf.org, Margaret Wasserman ,
  ogud@ogud.com, "Olaf M. Kolkman" , iesg-secretary@ietf.org
Date: …
Email from 2004-11-10:

From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair
To: Thomas Narten
Cc: namedroppers@ops.ietf.org, Margaret Wasserman ,
  ogud@ogud.com, "Olaf M. Kolkman" , iesg-secretary@ietf.org
Date: Wed, 10 Nov 2004 11:04:00 -0500
Subject: Document advancement DNSEXT: Case Insensitive


Thomas,

Please advance Case Insensitive clarification on the standards track:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-04.txt.

1. Have the chairs personally reviewed this version of the ID
and do they believe this ID is sufficiently baked to forward
to the IESG for publication?

Yes, we have read this document and it has been reviewed and
revised.


2. Has the document had adequate review from both key WG members
and key non-WG members?  Do you have any concerns about the depth
or breadth of the reviews that have been performed?

Yes, key members of DNSEXT a have read this document.
As this document was created to address a narrow non-controversial
issue that was from identified during the review of RFC3597, this issue
has clear base and purpose.


3. Do you have concerns that the document needs more review from
a particular (broader) perspective?

In theory this document should be reviewed by people that are experts
in non English languages as it border line touches on how these are
represented in DNS. But as IDN has addressed that there is no further
review needed.


4. Do you have any specific concerns/issues with this document
that you believe the ADs and/or IESG should be aware of?

The only concern with the document, is that the educational/background
sections may draw more interest and discussion than the actual DNS
Protocol content of the document.


5. How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The working group consensus is solid. The WG has only raised issues with
the semantics and structure of the document not content.


6. Has anyone threatened an appeal or otherwise indicated
extreme discontent?  If so, please summarize what are they upset about.

No

7. Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).

The document adheres to most of the ID nits with the exception that
some of the IPR statements required by RFC3668 are non compliant.
There are no IPR issues possible with this document.
We request that the editor  fix the IPR statement at the same time as he
addresses any nits brought up during AD review.


8. Does the document a) split references into normative/informative,
and b) are there normative references to IDs, where the IDs are
not also ready for advancement or are otherwise in an unclear state?

References are split, and all normative references are RFCs.

9. For Standards Track and BCP documents, the IESG approval
announcement includes a write up section with the following
        sections:

Technical Summary:
    RFC1034/5 was written when US-ASCII was the only language used on
    on the Internet. For this reason some corner cases related to case
    folding where not thought out. This document nails down these corner
    cases. The action of the document is to explicitly say only
    case folding only applies to letters in the A-Z range.
    This is the only guaranteed 100% inter operable solution.

Working Group Summary

    The document being advanced has been reviewed, it is non-controversial
    and will not change any implementations or practices.

Protocol Quality:
    This is quality document. The protocol change is minimal.


Olafur & Olaf


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
2005-01-21
06 Thomas Narten WG requested advancement 2004-11-10, but request didn't get added to ID tracker at that time.
2005-01-21
06 Thomas Narten Draft Added by Thomas Narten in state Publication Requested
2004-07-20
04 (System) New version available: draft-ietf-dnsext-insensitive-04.txt
2003-04-30
03 (System) New version available: draft-ietf-dnsext-insensitive-03.txt
2003-02-28
02 (System) New version available: draft-ietf-dnsext-insensitive-02.txt
2003-02-04
01 (System) New version available: draft-ietf-dnsext-insensitive-01.txt
2003-01-29
00 (System) New version available: draft-ietf-dnsext-insensitive-00.txt