Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199505301214.IAA22394@CS.UTK.EDU>
Date:        Tue, 30 May 1995 13:48:57 +0200
From: Eric Thomas <ERIC@SEARN.SUNET.SE>
Subject:     Re: getting started
To: drums@CS.UTK.EDU
In-Reply-To: Message of Mon, 29 May 1995 18:15:59 -0400 from moore@CS.UTK.EDU

One feature that  I think needs to  be clarified in both 821  and 822 (et
seq) is whether underscore and leading numbers are accepted in hostnames.

Right now we have a nice  mess where 822 allows underscores, 821 doesn't,
and neither  does the DNS,  but then bind does  and so does  sendmail, so
major  vendors (like  IBM) have  been  rioted into  modifying their  SMTP
software to  allow it.  Due to the  lack of a  clear statement  about the
underscore, it is harder for vendors to defend their position.

For leading numeric characters we  have another mess where the (modified)
DNS standards allow  it, but 821 doesn't. So in  principle they should be
rejected, but then we  all know they're used. I think  the intent of 1123
was to  modify 821 to  allow it, but  this hasn't been  stated explicitly
enough.

In general  it would  make life  a lot  easier to  have a  clear, central
definition of what characters are acceptable  in an Internet host name. A
new  standard that  would start  with "This  replaces and  supersedes all
former standards about  Internet host names". The problem  really is that
there are so many  places to look at that we  (software vendors) get hate
mail regularly from people who've read X but not the Z-amended version of
Y. They  bring this to  their bosses who don't  understand any of  it and
genuinely  think we're  violating standards.  Answering these  complaints
takes  a  lot  of  time  and is  counter  productive.  The  hard  reality
concerning for  instance the underscore  is that many mail  systems don't
support it. So the real question is do you want an address that will work
everywhere, or  one that  works on most  unix systems?  Pragmatically the
only sensible answer is to avoid the underscore. But these things need to
be  explained in  vendor-neutral  RFCs  that people  can  be pointed  to.
Customers  just don't  believe statements  from vendors  when they're  in
defense  of  the  current  behaviour  :-)  So  why  don't  we  allow  the
underscore? Well speaking only for myself,  one of the main products that
we have  to interface to  rejects the entire  transaction if it  sees one
underscore  in  it. Yes,  it  probably  should  be  fixed, but  it's  not
technically  a  bug so  their  support  people will  only  take  it as  a
suggestion for a  future release (good luck). The reason  they reject the
whole transaction  is that the people  who wrote the code  didn't have 10
years  of Internet  experience. They  figured  that an  underscore was  a
protocol violation,  because it sounded  this way from the  standards. So
they thought protocol violation = logic  error = big trouble ahead, abort
and notify system manager. Coming from an environment where standards are
*scrupulously* adhered to, it made sense to them. In their world it would
certainly be the correct thing to do.

All in all this business of having  10+ year old RFCs that get updated by
new RFCs from time  to time is a big source  of trouble. Implementors and
support people need a single document  with all the edits applied, with a
clear mechanism  to find  out whether the  document has  been superseded.
Many companies are  getting into the Internet,  implementing 82x gateways
without prior experience. They'll get 822 and implement it, and then when
a customer whines  that one of the  change in 1123 isn't  in the product,
they'll get confused  or upset and this is  generally counter productive.
If you put  all the stuff in  one document life will be  much simpler for
everyone.

  Eric