🚀 go-pugleaf

Steve,
  There is a philosophical issue here and let me preface my response with
two observations/qualifications:
 (1) This is not part of a "My network is better than your network"
discussion, it is an attempt to explain the (or "an") Internet point of
view.  If we can understand better why things are thought about differently
in the two contexts, and what concerns enter into that thinking, maybe we
can get on with designing solutions that make the best of both worlds.
 (2) To some extent, the ready existence of some facilities and not others
on the Internet *caused* the design decisions about how to do certain
things, rather than the need to do those things "causing" the low-level
facilities.  The same situation exists for BITNET.  NJE/RSCS does not
support TCP/IP's "one host, multiple sockets, multiple middle- and high-
level protocols" model conveniently, nor does it support virtual circuits
conveniently, and that caused people, looking for ways to do things to
seize on interactive messages and, for example, sender-initiated/password-
free file transfer as much as the need for those things caused the
facilities to be invented.  Similar comments apply about the Internet: both
networks were, to some extent, designed with low-level facilities first,
then applications layered on top of whatever low-level facilities were in
place, not by looking at the applications requirements and desiderata, then
designing the low-level facilities.  I'm not sure whether this is good or
bad; it is a historical reality.

In that context, a few comments on your "exercise".

-> What you consider a virtue--many services, one facility--is historically
considered a vice in TCP/IP-land.  There the tendency has been to assume
that the right model is "one service, one protocol, one well-known-service
and socket set".  There are nearly-technical arguments for this in terms of
neater layering (most of those applications-level protocols use Telnet,
including FTP's command connections, virtually all use either TCP or UDP),
but most of the argument for this strategy rather than the one you prefer
is aesthetic and/or religious.

-> One of the possibilities the Internet model opens up is a lot of
administrative flexibility that is much more difficult on BITNET.  If, for
example, I have a host on which I can permit only trusted programs at the
next layer up to use TCP or UDP directly, and can restrict the use of those
programs or some of their options, to (or from) particular classes of
users, then I can fine-tune network access and facilities.  I don't have
the problem of wondering whether I want to make "SMSG RSCS..." (or even
TELL) restricted access, knowing that, if I don't, I open up the
possibility of certain classes of abuses, and, if I do, I cut off lots of
reasonable network facilities.
   Again, I'm not making a claim about relative importance or merit here,
only trying to identify a way of thinking about the issues.

>a.  to send a command to listserv machine (or other server).
  In this "one service, one protocol..." model, it is hard to make general
"Internet" or "TCP/IP" statements here, but two observations are perhaps
relevant:
    (i) Many of the Internet servers operate in exactly this way and send
interactive messages.  Some -- notably the domain name resolvers themselves
-- typically send out UDP datagrams (as close to BITNET interactive
messages as you can get, including the 'if it does not get through, it
disappears' property) and then wait around to see if anything comes back.
Others, like finger and whois and hostname, open a telnet connection to a
special socket, send a short message (typically one line), and then the
server responds with a burst of information and closes the connection.  Two
-way interactive messages by any reasonable definition, but hidden by the
protocol.  And, again, if the server isn't answering, you don't get
anything but have to try again later.  Fair analogy, what?
    (ii) To my knowledge, no one has ever attempted to do what LISTSERV
does on the Internet, so there isn't going to be a direct analogy.  There
is no real reason why such a thing could not be done, just as there is no
real reason why FTP servers could not be modified on most hosts to accept
sender-initiated, password-free file transfers.  But LISTSERV is a large
and brilliant job, carefully adapted to the character and realities of the
BITNET environment.  A similar facility that was as carefully tailored to
the Internet environment would probably look very different internally, and
might rely on different types of facilities.  From an Internet perspective,
it would probably be argued that having a "LISTSERV-request-protocol"
separate from the "LISTSERV-please-distribute-protocol" would permit better
error messages, better administrative controls at the source (see above),
and *lots* fewer "sub mumble joe smith" messages broadcast to general-
purpose lists.

>b.  to query a remote database.
  Part of this is a LISTSERV-like issue, the rest of it is a finger/whois/
etc-like issue.  It isn't separate.  See above.

>c.  query whether a host is up.
  Your explanation really raises two issues, one of which has to do with
the remote host, and the other has to do with an intermediate host in the
chain.  From an Internet perspective, they get answered separately.
  (i) As you note, you ping the thing or, more specifically, bounce an ICMP
ECHO packet off it.  This is an "interactive message".  It is a little more
resource-conservative than sending an "interactive command", because no
remote database lookup is required (however trivial), unlike a 'who' and
only one packet comes back.
  So the interesting Internet-point-of-view question is "why won't your
system manager let you use it?".  The answer is that, unlike BITNET, you
probably can't get to the low-level facilities--there are good reasons for
not having users bouncing ICMP packets around.  And most "ping" commands
are not designed for "is the remote host up" testing, they are designed for
network metering.  Consequently, they send lots of packets and meter what
comes back and when.  What you would want, in Internet-philosophy, is an
unrestricted "is that responding" command which would send out one echo
packet, of minimal size, wait 10 or 20 seconds for it to come back, and
then possibly repeat the process a few times if it didn't, just to be sure
that you weren't dealing with a high packet loss or corruption rate.  It
would be trivial to write, and would not constitute a large resource load
on anything.  See your system manager and convince him or her that you
really need to know this type of stuff.
  (ii) The second issue has to do with the identification of the bottleneck
if you can't get through.  Because of the multiple-path, virtual-circuit,
adaptive routing character of the Internet, this question is either
irrelevant (if you get "equipment busy" on a telephone call to Europe, how
often do you find out where the equipment is tied up?  How often do you
care? and Why do you think the carrier is going to tell you?) or very
complex.
  The "very complex" version involves involves enough gateway- pinging and
route measuring to constitute a noticable network load, so it is not a good
facility for the casual user.  More important, it is very hard to interpret
the results in a useful way.  When I discover "Yale is down", the next
thing I do is to ask Brown how big the queue is for Yale so as to estimate
how long it has been down and how long it is going to take my message to
get through  (you didn't mention that one!).  But on the Internet, the
queues are on originating hosts, not on intermediate store-and-forward
machines and information about what is in those queues is typically
considered quite privileged (notice "is", not "should be", about which I
have no comment here).  And, more important, "Yale is down" typically means
a time of some minutes or longer, even given that the operators are on
their toes.  Because most of the gateways and routers, etc., on the Internet
are dedicated (and very simple) machines, not hosts, they tend to be able
to reset or reboot themselves very quickly and without human intervention.
And, given adequate connectivity, the system just quietly notices and goes
around dead links, often in the middle of a mail message or session.  So
there is a nasty uncertainty-principle variation here: you can find out the
status of the network when you asked, not when you encountered the problem
or when you are going to use the information.  Because BITNET responds a
bit more slowly, routing and blockage information is a bit more useful to
the casual user.

>d.  do a remote name lookup to get the mailing address of William Faulkner.
>f.  find out who is logged in.
>   Yes, I could also use the finger program here.
  At the risk of repeating myself, the important thing about the finger
program is that it *does* send pretty good approximations to interactive
messages.

>g.  Send messages to another user (and brush up on my Spanish in the
>    process.)
  This is a policy matter, not a technical one.  There are "talk" protocols
on the Internet which, because they are dedicated protocols, arguably work
better than flinging low-level interactive messages back and forth.  And
there has been provision for "immediate delivery to terminal" in SMTP
almost since the dawn of that protocol.  It is not often implemented,
presumably because not enough people have, in practice, needed it.

>What makes these particularly useful is that one command does it all.
  Or particularly harmful and error-prone.  See above.

>True, the content of the message changes, but the mechanism is the same.
  But, for any given network, this is ultimately always true: there are
always physical and link levels, and all messages pretty much look the same
at that level.  The critical question is how close to those levels, or even
to network level, the casual user should be operating.  If the answer is
"very far", then you move toward "one service, one protocol, one user-level
command".  If the answer is "no reason why it shouldn't be close", then you
see how much you can do with, e.g., TELL.  For historical reasons (and
possibly for rational ones), BITNET and the Internet have come up with
different answers.

    --john
    Klensin@INFOODS.MIT.EDU
-------