Domain Name System (DNS) Case Insensitivity Clarification
RFC 4343
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
06 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2015-10-14
|
06 | (System) | Notify list changed from ogud@ogud.com, okolkman@ripe.net,Donald.Eastlake@motorola.com to okolkman@ripe.net |
|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Allison Mankin |
|
2006-01-16
|
06 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2006-01-16
|
06 | Amy Vezza | [Note]: 'RFC 4343' added by Amy Vezza |
|
2006-01-11
|
06 | (System) | RFC published |
|
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 <narten@cichlid.raleigh.ibm.com> To: Olafur Gudmundsson <ogud@ogud.com>, Olaf Kolkman <olaf@ripe.net> cc: Rob Austein <sra@hactrn.net>, Donald.Eastlake@motorola.com Date: … From: Thomas Narten <narten@cichlid.raleigh.ibm.com> To: Olafur Gudmundsson <ogud@ogud.com>, Olaf Kolkman <olaf@ripe.net> cc: Rob Austein <sra@hactrn.net>, 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 <ogud@ogud.com> To: Thomas Narten <narten@us.ibm.com> Cc: namedroppers@ops.ietf.org, Margaret Wasserman <margaret@thingmagic.com>, … Email from 2004-11-10: From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> To: Thomas Narten <narten@us.ibm.com> Cc: namedroppers@ops.ietf.org, Margaret Wasserman <margaret@thingmagic.com>, ogud@ogud.com, "Olaf M. Kolkman" <olaf@ripe.net>, 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: <http://ops.ietf.org/lists/namedroppers/> |
|
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 <ogud@ogud.com> To: Thomas Narten <narten@us.ibm.com> Cc: namedroppers@ops.ietf.org, Margaret Wasserman <margaret@thingmagic.com>, … Email from 2004-11-10: From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> To: Thomas Narten <narten@us.ibm.com> Cc: namedroppers@ops.ietf.org, Margaret Wasserman <margaret@thingmagic.com>, ogud@ogud.com, "Olaf M. Kolkman" <olaf@ripe.net>, 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: <http://ops.ietf.org/lists/namedroppers/> |
|
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 |