Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard

From: [email-masked]
Date: Wed, 2 Feb 2005 04:39:43 +0000

fast track eh?  its very helpful of the IESG to consider this proposed 
standard at this time when the WG has not seen the material.  the ID was
released -today-.... perhaps you would consider that some folks might like
to read said document and consider it -before- placing it on the fast track.
Or is this one in some special way unique so that it is being rushed through?

Olaf/Olafur, whats up w/ this?

On Tue, Feb 01, 2005 at 06:43:09PM -0500, The IESG wrote:
> The IESG has received a request from the DNS Extensions WG to consider the 
> following document:
> 
> - 'Domain Name System (DNS) Case Insensitivity Clarification '
>    <draft-ietf-dnsext-insensitive-05.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2005-02-15.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-05.txt
> 
> 
> --
> 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/>

--
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: Robert Elz <[email-masked]>
Date: Wed, 02 Feb 2005 14:44:03 +0700

Date:        Wed, 2 Feb 2005 04:39:43 +0000
    From:        [email-masked]
    Message-ID:  <[email-masked].>

  |  fast track eh?  its very helpful of the IESG to consider this proposed 
  | standard at this time when the WG has not seen the material.  the ID was
  | released -today-.... perhaps you would consider that some folks might like
  | to read said document and consider it -before- placing it on the fast track.
  | Or is this one in some special way unique so that it is being rushed through?

Huh?

Slow track more likely.   The request for the last call on this was
sent last November, so it has taken almost 3 months for the last call
to get issued.

Of course, events seem to have made clear why - the last call request
was for the -04 version, it seems that someone decided they needed to
wait for a new version to appear - as soon as that appeared, the last
call was dispatched (as I recall, that is even semi-automated - the
fact that the draft appears causes the last call to be transmitted,
without much in the way of oversight of the process).

None of this is unusual at all.

In this case, what may be considered unusual, is that there has been
no mention on the namedroppers list of the need for the -05 draft, nothing
about what required it, and nothing about what has changed in it.   Maybe
the draft says that - but if it is the version that is to be published as
an RFC, it shouldn't (RFCs should not contain info about what changed
in the last few versions of the I-D, nor should they be having that kind
of information editorially deleted after approval).

kre

---

From: Donald Eastlake III <[email-masked]>
Date: Wed, 2 Feb 2005 08:48:27 -0500 (EST)

This draft has fairly clear notes towards the end documenting all the 
changes since version -02. It has been percolating slowly through the 
system for a LONG time, like years, due to other higher priorities in 
DNSEXT. The changes from -04 to -05 are, in my opinion, extremely minor 
and were the changes suggested by our Area Direction. Cutting and 
pasting from the draft they are:

-04 to -05 Changes

    The following changes were made between draft versions -04 and -05:

    1. More clearly state that this draft updates RFCs 1034, 1035 [STD
    13].

    2. Add informative references to ISO 8859-1 and ISO 8859-2.

    3. Fix hyphenation and capitalization nits.

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

On Wed, 2 Feb 2005, Robert Elz wrote:

> Date: Wed, 02 Feb 2005 14:44:03 +0700
> From: Robert Elz <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], IETF-Announce <[email-masked]>,
>     [email-masked]
> Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity
>     Clarification' to Proposed Standard 
>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 02 Feb 2005 09:35:45 -0500

> Or is this one in some special way unique so that it is being rushed

Hi Bill.

The document is hardling being rushed through.

WG asked that it be advanced, like back in November or so. The request
was sent to the secretariat (as is the proper procedure), but the
document didn't get added to ID tracker like it should have, so I
didn't realize it was on my plate. When I noticed (last week), I
reviewed the doc, sent some questions to the author/chairs, and the
result is a new revision. I was waiting for the new version before
starting the last call.

You can see the specific review comments in ID tracker if you want,
but they are pretty unexciting, as are the changes in the new version.

Thomas

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 02 Feb 2005 09:52:23 -0500

>Olaf/Olafur, whats up w/ this?

This draft was processed in the working group, last call announcement:
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01486.html

But due the fact that yours truly dropped the ball, the advancement
notice did not go out for over a year:
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg02064.html

Then there was another delay before AD approved the draft for
LC. So we ended up with 18 months from start of WG last call to
start of IETF LC.

         The fault for this slow process is mostly mine.
         Olafur

PS: moral ping your WG chairs regularly if they have action items.

---

From: [email-masked]
Date: Wed, 2 Feb 2005 17:37:39 +0000

> sent last November, so it has taken almost 3 months for the last call

	Ah... that option I had not considered. Sorry for the
	hasty outburst.

> None of this is unusual at all.

	seems wrong to me, but what do i know.

> of information editorially deleted after approval).

	yes.  thank you for being clear.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 02 Feb 2005 23:34:31 +0100

> of information editorially deleted after approval).

Yes, they should.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 02 Feb 2005 20:36:50 -0500

On Tuesday, February 01, 2005 06:43:09 PM -0500 The IESG 
<[email-masked]> wrote:

> The IESG has received a request from the DNS Extensions WG to consider
> the  following document:
>

The document in question states:

   One typographic convention for octets that do not correspond to an
   ASCII printing graphic is to use a back-slash followed by the value
   of the octet as an unsigned integer represented by exactly three
   decimal digits.

While this is literally true, the _common_ convention is to use a backslash 
followed by the value of the octet as an unsigned integer represented by 
exactly three _octal_ digits.  This is the syntax used by programming 
languages like C and perl.  For example, ASCII ESC (0x1b) is represented as 
\033, not \027.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Feb 2005 14:07:44 +1100

> 
>  [ Moderators note: Post was moderated, either because it was posted by 
>    a non-subscriber, or because it was over 20K.  
>    With the massive amount of spam, it is easy to miss and therefore 
>    delete relevant posts by non-subscribers. Please fix your 
>    subscription addresses. ]
> 
> 
> 

	The C convention also has \t, \r, \f, \n none of which are
	the special in domain labels.

	We are not trying to change conventions here.  It is irrelevent
	that C has a different convention.
	
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Donald Eastlake III <[email-masked]>
Date: Wed, 2 Feb 2005 22:41:43 -0500 (EST)

The context is clearly Master Files where the syntax is as given.
For the purposes of this document, which is clarification of the 
existing DNS conventions, what does it matter what is done elsewhere?

However, unless there is objection, I'd be happy to change the relevant 
sentence by inserting "in Master Files" so it reads:

    One typographic convention in Master Files for octets that do not
    correspond to an ASCII printing graphic is to use a back-slash
    followed by the value of the octet as an unsigned integer
    represented by exactly three decimal digits.

Thanks,
Donald

On Wed, 2 Feb 2005, Jeffrey Hutzelman wrote:

> Date: Wed, 02 Feb 2005 20:36:50 -0500
> From: Jeffrey Hutzelman <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]

---

From: stanislav shalunov <[email-masked]>
Date: 03 Feb 2005 00:54:29 -0500

Jeffrey Hutzelman <[email-masked]> writes:

> [..T]he _common_ convention is to use a backslash followed by the
> value of the octet as an unsigned integer represented by exactly
> three _octal_ digits.  This is the syntax used by programming
> languages like C and perl.  For example, ASCII ESC (0x1b) is
> represented as \033, not \027.

Actually, the convention used in C and Perl is to use \0, followed by
zero, one, or two octal digits (leaving some values of octets without
representation).

I personally think it's a poor convention as it uses varying number of
digits, so it becomes difficult to represent, say, the NUL character
followed by the digit "1".  (I still use the convention in cases when
it is familiar to most from documentation, e.g., "\015\012" in Perl.)

A reasonable convention is hexadecimal: backslash, followed by the
letter x, followed by exactly two hexadecimal digits; e.g., "\x1b" for
ESC.  This notation, while looking familiar, has differences from both
Perl and C hex notations: in Perl, you can have just a single hex
digit following ``backslash x'', while in C you can have arbitrarily
many.

With the common conventions so unnecessarily complex and difficult to
use, it doesn't surprise me that the document authors chose to use a
nonstandard one.  I'd have chosen a different one (hex with exactly
two digits, which won't deceive C and Perl programmers in the same way
"\027" meant for ESC would), but that's just a minor typographic
convention.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed with 0.06479891g of NaCl.

---

From: Donald Eastlake III <[email-masked]>
Date: Thu, 3 Feb 2005 08:45:48 -0500 (EST)

Just to be clear, I didn't make any decisions here. This typographic 
convention for DNS names was adopted long ago. See RFCs 1034, 1035.

Thanks,
Donald

PS: I don't believe it is worth the time of everyone on the IETF list to 
see this stuff so I have been consistently changing [email-masked] to 
[email-masked] as an addressee.
  ====================================================================
  Donald E. Eastlake 3rd                       [email-masked]
  155 Beaver Street              +1-508-634-2066(h) +1-508-786-7554(w)
  Milford, MA 01757 USA                   [email-masked]

On Thu, 3 Feb 2005, stanislav shalunov wrote:

> Date: 03 Feb 2005 00:54:29 -0500
> From: stanislav shalunov <[email-masked]>
> To: Jeffrey Hutzelman <[email-masked]>
> Cc: [email-masked], [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 03 Feb 2005 11:38:56 -0500

> it is familiar to most from documentation, e.g., "\015\012" in Perl.)

ISO/IEC 9899:1990 section 6.1.3.4 has this to say:

    octal-escape-sequence:
      \ octal-digit
      \ octal-digit octal-digit
      \ octal-digit octal-digit octal-digit

    hexadecimal-escape-sequence:
      \x hexadecimal-digit
      hexadecimal-escape-sequence hexadecimal-digit

And...

    Each octal or hexadecimal escape sequence is the longest sequence
    of characters that can constitute the escape sequence.

So, octal escape sequences consist of one, two, or three digits, but never 
more than three, and the first digit is not required to be zero.  Every 
8-bit character can be represented, and every string of 8-bit characters 
can be represented.  The sequence of the NUL character followed by the 
digit "1" can be written as "\0001", or as any of these:

  \0\061 \00\061 \000\061 \0\61 \00\61 \000\61

Interestingly, as you noted, hexadecimal sequences are _not_ length-limted.

Now, let's turn to Perl.  The authoritative reference is from the section 
"Quotes and Quote-like Operators" in 'perldoc perlop':

       The following escape sequences are available in constructs that
       interpolate and in transliterations.

           \033        octal char      (ESC)
           \x1b        hex char        (ESC)
           \x{263a}    wide hex char   (SMILEY)

Unfortunately, this is a little vague, but an examination of the code shows 
that up to three digits are permitted in the octal case, and two in the hex 
case (wide hex chars have no preset length limit), which is pretty much 
what one would expect.

In any case, my original point was not to get into a discussion of the 
finer details of character escapes in particular programming languages, nor 
to suggest that every escape permitted by C or Perl be used in this 
context.  Rather, it was to point out that the existing, commonly-used 
convention for character escapes of this form uses octal digits, not 
decimal, and that differing in this particular way would be likely to lead 
to confusion.

> the special in domain labels.

This is a strawman.  I did not make the argument that C string literal 
syntax should be used; I mentioned the syntax of C and Perl as examples of 
the widespread recognition of octal character escapes.

> that C has a different convention.

The C programming language has precisely defined syntax, not a convention. 
Again, I did not make the argument that C syntax should be used.  What I 
did do was point out that there is a commonly-recognized convention for the 
meaning of a backslash followed by three digits, and that it differs from 
that described in this document, which to my knowledge does not enjoy any 
form of widespread acceptance.  This fact is not "irrelevant"; it is likely 
to lead to significant confusion.

Note that I'm not demanding that the DNS use the same conventions as 
everyone else.  I think they should, but I'm not going to insist on it. 
However, if you're going to be different, you need to call out this fact, 
and preferably explain why.

---

From: stanislav shalunov <[email-masked]>
Date: 03 Feb 2005 16:50:34 -0500

> ISO/IEC 9899:1990 section 6.1.3.4 has this to say:

This differs from my account in not requiring the first octal digit
after backslash to be zero.  Thank you for correcting that; "\61",
indeed, works as "1" in C.  (Thus, there are enough digits to
represent any value of an octet.)

> finer details of character escapes in particular programming
> languages, nor to suggest that every escape permitted by C or Perl be
> used in this context.  Rather, it was to point out that the existing,
> commonly-used convention for character escapes of this form uses octal
> digits, not decimal, and that differing in this particular way would
> be likely to lead to confusion.

Agreed.

> [...] it is likely to lead to significant confusion.

I also agree that "\027" for ESC is unnecessarily confusing.

This message is designed to be viewed in boustrophedon.

---

From: Robert Elz <[email-masked]>
Date: Fri, 04 Feb 2005 11:54:22 +0700

Date:        03 Feb 2005 00:54:29 -0500
    From:        stanislav shalunov <[email-masked]>
    Message-ID:  <[email-masked]>

This is totally irrelevant to the doc in question, but ...

  | Actually, the convention used in C and Perl is to use \0, followed by
  | zero, one, or two octal digits (leaving some values of octets without
  | representation).

that is utter garbage.   \377 is a perfectly valid C (and I assume perl,
though I gave up on perl years ago) representation of the value 255.

  | I personally think it's a poor convention as it uses varying number of
  | digits, so it becomes difficult to represent, say, the NUL character
  | followed by the digit "1".

Not difficult, just ugly ... \0001 works just fine.

  | nonstandard one.  I'd have chosen a different one

You're 20 years too late.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 04 Feb 2005 12:00:48 +0700

Date:        Wed, 02 Feb 2005 23:34:31 +0100
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <88EAAA4611113A9E57A00593@B50854F0A9192E8EC6CDA126>

  | > In this case, what may be considered unusual, is that there has been
  | > no mention on the namedroppers list of the need for the -05 draft, nothing
  | > about what required it, and nothing about what has changed in it.   Maybe
  | > the draft says that - but if it is the version that is to be published as
  | > an RFC, it shouldn't (RFCs should not contain info about what changed
  | > in the last few versions of the I-D, nor should they be having that kind
  | > of information editorially deleted after approval).
  | 
  | Yes, they should.

I'm not sure what you're saying there exactly.    If you mean that if there
are updates notes in a draft that is approved, then the rfc editor should
delete them, then yes, I agree.

On the other hand, if you're saying that that is the proper way to do things,
then I disagree.

The doc proposed (for IETF last call, at the very least) should be as close
as possible (as close as the boilerplate nonsense permits) to the exact RFC
that will be published.

It is entirely possible that some readers may see some technical merit in
the update notes - that the doc is clear, but only because those notes indicate
what is going on, and why.   Without the notes, a valid objection might be
made.   If (non boilerplate) data is deleted after approval, then a doc that
shouldn't have been approved, can avoid objections.

The right way to do this, is to have the final draft of the doc (perhaps the
final version for WG last call, and certainly the version sent for IETF
last call) be the same as what will be the RFC - taht is, a new version of
the I-D should be publiched, where the only change is to delete any extraneous
material like this (and the I-D shouldn't be saying this).

Donald - if, as seems possible from other messages, you're going to publish
a new I-D, please send a version without noise, so that one can be properly
evaluated for IETF last call.

kre

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 04 Feb 2005 08:22:14 +0100

Expanding slightly on the one-liner:

What I am saying is that the version that is put before the IESG for the 
IESG's approval should include notes that track the revision history of the 
document, if these are available.

In very many cases, members of the IESG have followed the document's 
development, seen Last Call comments, have formed opinions on particular 
issues, and may even have given specific feedback on the document in 
previous versions.

A list of "what has changed since the last version of the document" helps 
both to make sure known issues have been addressed and to point out which 
sections of the document have NOT changed since the previous instance 
reviewed.

Of course, such sections SHOULD be clearly marked with "RFC Editor, please 
delete this on publication".

This is my opinion, formed over 8 years of trying to get documents through 
the IESG. You have stated your opinion, but you are not saying anything 
about your reasons for that opinion. Neither opinion is based on a 
published rule of the IETF, AFAIK; there's nothing indicating that the IETF 
has consensus on one of these.

I'll stick to my opinion for now.

                       Harald

--On 4. februar 2005 12:00 +0700 Robert Elz <[email-masked]> wrote:

>   | > no mention on the namedroppers list of the need for the -05 draft,
> nothing   | > about what required it, and nothing about what has changed
> in it.   Maybe   | > the draft says that - but if it is the version that
> is to be published as   | > an RFC, it shouldn't (RFCs should not contain
> info about what changed   | > in the last few versions of the I-D, nor
> should they be having that kind   | > of information editorially deleted
> after approval).
>   |
>   | Yes, they should.
>
> I'm not sure what you're saying there exactly.    If you mean that if
> there are updates notes in a draft that is approved, then the rfc editor
> should delete them, then yes, I agree.
>
> On the other hand, if you're saying that that is the proper way to do
> things, then I disagree.
>
> The doc proposed (for IETF last call, at the very least) should be as
> close as possible (as close as the boilerplate nonsense permits) to the
> exact RFC that will be published.
>
> the update notes - that the doc is clear, but only because those notes
> indicate what is going on, and why.   Without the notes, a valid
> objection might be made.   If (non boilerplate) data is deleted after
> approval, then a doc that shouldn't have been approved, can avoid
> objections.
>
> The right way to do this, is to have the final draft of the doc (perhaps
> the final version for WG last call, and certainly the version sent for
> IETF last call) be the same as what will be the RFC - taht is, a new
> version of the I-D should be publiched, where the only change is to
> delete any extraneous material like this (and the I-D shouldn't be saying
> this).
>
> Donald - if, as seems possible from other messages, you're going to
> publish a new I-D, please send a version without noise, so that one can
> be properly evaluated for IETF last call.
>
> kre
>
>
>