Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!ames!haven!uvaarpa!randall
From: randall@uvaarpa.virginia.edu (Randall Atkinson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: New Host-Requirement RFCs
Keywords: Host-requirements
Message-ID: <1037@uvaarpa.virginia.edu>
Date: 12 Oct 89 01:39:13 GMT
References: <1949@cmx.npac.syr.edu>
Reply-To: randall@uvaarpa.Virginia.EDU (Randall Atkinson)
Distribution: inet
Organization: University of Virginia, Charlottesville
Lines: 43

In article <1949@cmx.npac.syr.edu> jmwobus@cmx.npac.syr.edu (John Wobus) writes:

>  However, I'm sure a lot of us users were hoping for
>something we could refer to in procurement specifications.  

The new host requirement RFCs are "something we can refer to
in procurement specifications" and I think a lot of vendors
will be seeing them referred to in that fashion in the future.

>Besides requiring some less-than-generally-useful features like source
>routing, it avoids the issue of implementations not meant to include
>all the applications mentioned, i.e., a single-user system which
>wisely makes no effort to offer SMTP service.

I strongly disagree with the notion that RFC-822 source routing
is "not generally useful."  The mail systems I manage for GE all
fully support source routing as specified in RFC-822 and I put use
them in some outgoing mail (e.g. in mail to DECnet gateways that
are less than correctly defined { not GE mind you, our DECnet nodes
can all be reached as "userid@decnet-node-name.DNET.GE.COM" and
don't need the "% hack" of any other non-standard syntax. } ).
My systems do not support the "% hack" popularised by BSD sendmail
and will not as long as I manage their mail systems.  The "% hack"
is ugly, difficult to parse correctly at Internet--othernet gateways,
and not needed.  If your system doesn't support source routing, it
is broken and has been at least since RFC-822 came out.

A single-user, multitasking system should be able to handle SMTP.
IF your single-user system is single-tasking, I'd suggest that it
will never be much more than a very bright terminal to the rest
of the Internet.  Watering down an RFC to account for DOS machines
or the like strikes me as inappropriate.

>We will be happier if either vendors change their attitudes or if
>another paper (RFC?) is developed to fill the gap--I can imagine
>a paper describing everything a host ought to do if it can claim
>to offer "TELNET" service, if it can claim to offer "FTP" service,
>etc.  Perhaps it could also address the different protocols below
>IP too.

I predict that vendors will be moving strongly in towards supporting
the host requirements RFC precisely because I expect sites to cite
those RFCs in procurement requests. (See Above).