Benson I. Margulies (Margulies@SCRC-YUKON.ARPA)
Wed, 14 May 86 07:45 EDT
Date: 13 May 1986 18:38-PDT
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,
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.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:06 GMT