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

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

See responses below:

On Wed, 2 Feb 2005 [email-masked] wrote:

> Date: Wed, 2 Feb 2005 12:51:40 -0600
> From: [email-masked]
> To: Donald Eastlake III <[email-masked]>
> Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity
>     Clarification' to Proposed Standard
> 
> Not that any of it probably really matters in the whole scheme of things
> but...
>
>> 4.2 DNS Input Case Preservation
>> When a node in the DNS name tree is created by any of
>>   such inputs
>
> This might be a regional thing, but I'd leave the "of" out.

I'm not inclined to make this change.

>> However,
>>   when a name label is input for a node that already exist in DNS data
>>   being held, the situation is more complex.
>
> 'exists' instead of 'exist'?

Yes.

>> 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.
>
> 'MAY' versus 'may'

Yes, seems right to me to be MAY.

>> as the first resourced record under owner name "xyz.BAR.example"
>
> 'resourced' or 'resource'?

Yes, "resource".

>> However, the individual octets of which DNS names consist are not
>>   limited to valid ASCII character codes. They are 8-bit bytes and all
>>   values are allowed.
>
> Which RFC states this?  Should it be referenced?

Well, I could check whether 1034 or 1035 is the best reference but the 
purpose of this document is, afterall to clarify 1034 and 1035 so in 
some sense the influcen is going in the other direction...

> Thanks
>
> Dan Anderson, CISSP, SCSA
> UNIX Team Leader
> DTN
> 9110 West Dodge Road
> Omaha, NE 68114
>
> [email-masked]
> Phone: 1-402-255-8371
> Fax: 1-402-255-8460
> www.dtn.com

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]

--
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: Fri, 04 Feb 2005 12:10:47 +0700

Date:        Wed, 2 Feb 2005 22:51:14 -0500 (EST)
    From:        Donald Eastlake III <[email-masked]>
    Message-ID:  <[email-masked]>

  | > 'MAY' versus 'may'
  | 
  | Yes, seems right to me to be MAY.

I wouldn't bother.    MAY means nothing in 2119, that is, all it means
is that <whatever> is optional.   That's what it would also mean written
as "may", so you gain nothing.   Of course you also loose nothing by the
change, and it perhaps looks more consistent with 2119 to do it as MAY.

The problem comes that people who see MAY for may, start to write MAY NOT
for "may not".   That one doesn't work at all.   First, MAY NOT doesn't
exist in 2119, so that term has no meaning as a term, leaving just the
2119 MAY, together with a "not" in a strange typographical convention.
Since "MAY" means that whatever it applies to is optional, the NOT really
is just noise (you may "do this", or you can chose not to, which is the
same as you may "not do this" or you can chose not to "not do this", that
is, you can choose to do it).   But in English, and in the way people
usually use the phrase, "may not" means something more like "must not",
which it turns out is nothing like what "MAY NOT" means from 2119.

To avoid this, the best thing is to simply discourage use of the 2119 MAY
completely.

kre

ps: as it was uses in 1123 etc, MAY was fine, there it had a specific role.
It is possible in some other doc using 2119 to desire a similar result,
so I am not suggesting that MAY be deleted from 2119 - just that its use
be confined to where there's a particular need, which is not just where
there's something that happens to be optional, we don't need magic words
for that.