Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!caip!lll-crg!styx!scrc-quabbin.arpa!DCP
From: DCP@SCRC-QUABBIN.ARPA (David C. Plummer)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Port Collisions
Message-ID: <860514220958.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Wed, 14-May-86 22:09:00 EDT
Article-I.D.: FIREBIRD.860514220958.2.DCP
Posted: Wed May 14 22:09:00 1986
Date-Received: Fri, 16-May-86 03:59:28 EDT
References: <8605141747.AA04242@isi-braden.arpa>
Sender: daemon@styx.UUCP
Organization: The ARPA Internet
Lines: 46
Approved: tcp-ip@sri-nic.arpa


    Date: Wed, 14 May 86 10:47:27 PDT
    From: braden@isi-braden.arpa (Bob Braden)

    It sounds like another version of the SNA/DECNET free-enterprise protocol
    wars.

    Do you think we should encourage the proliferation of private protocols,
    many of them doing the same things?  It is clearly in the national 
    interest (that's us, friends) to promote maximal interconnection of
    heterogeneous systems.  That is what standards are for.

    Until recently, in England there were several different standards for
    electric plugs, because each of the 19th century power barons designed
    their own.  So you bought an appliance with a cord but no plug on the
    end, and added the plug necessary for your outlet. Rather like a
    configuration file, isn't it?

    As a customer, do you think I should buy a software system from a vendor
    that did not have the resources to properly document its internal function?
    I wonder what kind of maintenance and support I will get with that product.

Example.  Symbolics calls its current "private file protocol" NFILE.  It
is currently documented in the Release 6.1 Release Notes.  We know it to
be far superior to TCP/FTP and pervious file protocols on Lisp Machines.
NFILE is a true file ACCESS protocol as oposed to FTP which is a
transfer protocol.  Back then we weren't ready to tout it to the rest of
the world.  I'm still not sure we are.  The reasons are many.  We aren't
sure it is really sufficient.  We do know that there are some very
complex operations in it because of the need to handle aborting out of
operations correctly.  The generic-file-system model it assumes may not
fit in well with all known system.  We also fear that many people will
not understand the need for some of the complexity and will either want
it thrown out because they can't figure out how to implement it, or
won't implement the parts without telling people.  (Need I remind people
that Unix TCP/FTP still sends the wrong code for the DELETE operation, I
believe it is.)  Companies may be willing to document their protocols to
let others experiment with them.  They may not be prepared to solidify
on it or to change it to the whims of the masses.  If NFILE replaced
TCP/FTP as the Internet standard, and if we discovered some other
feature that is rather crucial to our system, we would be in the same
ballpark as we are now: a private protocol.

There are sometimes some good reasons not to push private protocols as
standards until all the conditions are right, even though those private
protocols are documented and provide superior functionality.