Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!ucbvax!SCRC-YUKON.ARPA!Margulies
From: Margulies@SCRC-YUKON.ARPA.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Port Collisions
Message-ID: <860514074552.6.MARGULIES@REDWING.SCRC.Symbolics.COM>
Date: Wed, 14-May-86 07:45:00 EDT
Article-I.D.: REDWING.860514074552.6.MARGULIES
Posted: Wed May 14 07:45:00 1986
Date-Received: Fri, 16-May-86 01:37:10 EDT
References: <[SRI-NIC.ARPA]13-May-86.18:38:48.STJOHNS>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 66
Approved: tcp-ip@sri-nic.arpa


    Date: 13 May 1986 18:38-PDT
    From: STJOHNS@SRI-NIC.ARPA

    I  am not sure I see the problem here.  A "private file protocol"
    is just that - PRIVATE.  It is run between machines that make the
    assumption  that  they are all running the same private protocol.

Wrong meaning of private.  Try the definition `A protocol not published
as an RFC, for any reason whatsoever.'

    Or is there the possibility that one machine is running  multiple
    PRIVATE file protocols?

Exactly. Symbolics has a 'private' file protocol.  One of our customers
wanted to teach their lisp machine to talk someone elses 'private' file
protocol.  Unfortunately, they were on the same port.  This situation is
typical, and likely to happen again and again.


    Either  a  protocol is a network wide standard - implying that is
    is documented, and that it is designed for at least a minimum  of
    interoperability  -  or  it  is private, with little or no public
    documentation, and with no designed  interoperability.   In  this
    context,  I  am  talking  about global interoperability, not just
    interoperability between UNIX systems for example.

The problem is with the phrase `network-wide standard'.   The number
czar only designates protocols as `network-wide standards' as part of
the activity of the internet research community (I'm paraphrasing Jon
Postel, and I hope that I'm getting it right). That is not to say that
vendors cannot offer protcols for inclusion in the global set. However,
it is often not practical for us to do so.  We can't always afford the
time to document the protocol for the community, which is a pretty-near
necessart for inclusion in the global protocol set.

Anyway, I don't think that your simple division of the world into Public
and Private is good enough.  I think that things are more complex.

First, there is an extensive gray area between officially blessed
protocols (global interoperability) and protocols that are private hacks
amongst a small number of cooperative machines (no interoperability).
As a commercial vendor, we are concerned with orderly partial
inter-operability.  If Berkley has established a 'private' Unix TCP
protocol, it is very likely that sooner or later someone with a lisp
machine (or something else non-Unix) will want to talk that protocol to
a Unix.  That dosen't necessarily qualify the protocol as a network-wide
standard, but gives a good reason for us to avoid port collisions.

Second, even if I were implementing a protocol that would only be used
at one site amongst three machines,  I would like some assurance that I
won't find out next week that some vendor is using the port that I chose
for some protocol that I am interested in using.

    I can see  some  advantage  though  in  providing  some  sort  of
    sentinal  as  part  of the PRIVATE protocols to say "I am running
    FOO as my private protocol, go away if you don't talk FOO".   But
    wouldn't  this  more  properly  be  part  of  the protocol?  Each
    protocol should do some  confirmation  for  robustness  purposes,
    right?

Indeed, its not hard to say `sorry, you can't talk to him, because he's
doing something else over that port.'  Cold comfort if your goal is to
talk to him.

    Mike