Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199505311918.PAA15344@CS.UTK.EDU>
Date:        Wed, 31 May 1995 20:48:04 +0200
From: Eric Thomas <ERIC@SEARN.SUNET.SE>
Subject:     Re: mail name rules
To: drums@CS.UTK.EDU
In-Reply-To: Message of Wed, 31 May 1995 14:20:48 -0400 from Dave Barr
             <barr@math.psu.edu>

On Wed, 31 May 1995 14:20:48 -0400 Dave Barr <barr@math.psu.edu> said:

>This ``what's  in a name?''  confusion really  has to be  clarified, and
>IMHO relaxed.  It apparently was  the intention  from the start  to work
>towards relaxing  the naming  requirements. Unfortunately some  big name
>companies write  software which  is really anal  to the  standards which
>makes such relaxations very hard. One  of the tenets of the ``be liberal
>in  what  you accept...''  philosophy  is  that  it  opens the  way  for
>relaxation of the  rules. (that's one reason why the  leading digit rule
>was able to be changed, for example)

The leading digit rule could be  relaxed because all name servers already
had to support it for the  IN-ADDR.ARPA domain, so there was no technical
problem. We knew it already worked.

Commenting on  the rest  of your message,  I will just  say that  this is
exactly the  kind of attitude  that makes vendors reluctant  to interface
their  products  to  the  Internet.  In the  real  world,  standards  are
standards. If the standards  say X you do X. If your  program is found to
do X' and X' is not allowed by  the standard, you apologize and fix it to
do X. This is the way the industry at large operates, and this has worked
successfully for  decades. On  the Internet,  if the  standards say  X it
seems  you are  expected to  do  X' or  X'' or  whatever other  variation
strikes your fancy. If it then turns out that your variation violates the
standard and your product can't interoperate  with the rest of the crowd,
you flame the compliant programs for doing what the standards say and not
having thought in advance that there would be people doing X' or X''. You
call them  "anal retentive" when  you're the  one who doesn't  follow the
specs. You  also make sure  to tell  this to the  users so they  call the
vendor's hotline and complain about fictitious "standard violations". The
vendor's hotline gets saturated and all this nonsense costs money for the
vendor, who  really doesn't  understand what  the heck  is going  on, not
being used to the "flexible" nature of Internet standards. All this costs
money and irritates people in a totally counter productive way.

For  better  or for  worse,  the  underscore wasn't  allowed  originally.
Personally I think  it was a stupid restriction, along  with 7-bit ASCII,
symmetric TELNET and  a long list of  other things, but I accept  it as a
given. Whether we  like it or not,  there's a lot of  software that won't
accept it. This means that if you use it today, many people won't be able
to talk to you. I don't see  any compelling reason why people HAVE to use
the underscore. The dash is allowed and seems good enough for the purpose
of separating  two words.  I'm not entirely  against relaxing  rules, but
then allowing national  characters seems a LOT more important  to me than
allowing the  underscore, which  is cute but  serves no  critical purpose
(unlike national characters - try spelling  your hostname without E, O or
U and  let me know how  it sounds). As a  vendor I would say  that a move
towards  allowing unicode  in host  names, while  expensive and  possibly
unwelcome, would at least bring enough  end user benefits that a business
case could be made for it. I'm  afraid I can't think of any business case
supporting  software  changes  to  allow the  underscore.  Companies  and
organizations don't have underscores in their name, so unlike the leading
digit change I don't see any concrete benefit for Joe Q. User.

  Eric