Re: An RFC from the IAB

[Robert Elz <[e-mail]>]

    Date:        Fri, 22 Mar 1996 18:30:13 -0500
    From:        Steve Bellovin <[e-mail]>
    Message-ID:  <[e-mail]>

    These two requirements are rather contradictory...

This was before your time, but we had that discussion already...

    So there's some need to check for syntactic purity
    in the DNS implementations,

no, there's a desire to do it - its absolutely the wrong way
to fix the problem, its just the cheap (and possibly only
manageable, though that's not clear, as the major attack seems
to have been via sendmail, and sendmail has already been fixed).

The DNS is a database, it is (relatively) content free, there's
no reason to impose restrictions for any DNS purpose itself.
The restrictions are just to (attempt to) save applications from
needing to make sanity checks on the data returned before
blindly accepting it, and relying upon it.

Even that can't work, as doing so would require at least one
"fixed" DNS server in the path between the application and the
bogus data, and there's not really much more hope of achieving
that than of simply having the applications fixed - those that
know and care about these problems will fix whatever is needed
to be fixed, the others won't upgrade anything at all.

    But what's a ``letter'' in Unicode?
    What is upper case in Hebrew or Kanji?

These are real problems to some degree, but don't really affect
what is in the draft.

The first point is that unless some wide character set (like
unicode, 10646, or whatever, and however encoded) is specified
to be used - which to the best of my knowledge it isn't in
any of the important standards (yet), we have no way to know
what a character that isn't ascii is supposed to represent.

Is it Hebrew?  Kanji?  Thai?  Sanscrit?   Some kind of tagging
would be needed, and applications like the DNS, 822, etc,
simply don't provide that.   Short of respecifying them, there
is nothing we can do about this, other than to simply state that
ASCII is it, however limited, or frustrating, that might be.
Attempts to (somehow) encode other characters in these places
cannot succeed (without major redefinitions), it is best to
simply not try, and openly admit the problem.

The "what is upper case?" is really a non-problem.   It
doesn't matter that Hebrew (I assume from your message) or
Thai (I know) or Kanji, have no concept of upper/lower case.

What's important here is that when there is a concept of upper
and lower case - or perhaps more generally, whenever there are
different characters that can be used, but which cause no
difference in meaning to the word in which they are used (eg:
a dog and a DOG and a Dog and a dOg are all the same kind of
animal however it is represented) those characters should be
treated the same.

If a character set has no such characters, that's fine, that
one has less work to do...

kre