Re: private/proprietary protocols

Mark Horton (mark@cbosgd.ATT.COM)
Sat, 17 May 86 23:52:47 edt

>Personally, I think that proprietary protocols have no place in the Internet
>research/military community.

Please remember that TCP/IP is used throughout the world as an industry
standard, it isn't just the friendly folks on the ARPANET anymore. Some
of us have to deal with managers who view our every remark as intellectual

>They are absolutely not in the best interest
>of US national defense. Quite enough problems exist because the UUCP protocol
>is AT&T proprietary. As a software vendor, I sympathize with the need for
>trade secret and other forms of software protection. However, a deliberate
>attempt to lock out interoperability with other vendors' products is bad for
>the customer and ultimately bad for the vendor.

I think Mark misunderstands the situation with UUCP. I am sure that AT&T
has not made a deliberate effort to keep the protocol a trade secret. I
don't believe they've given it any thought. I think the reason you can't
just sit down and write a UUCP is that nobody at AT&T has bothered to sit
down and document the protocol. (That would be a lot of work, especially
to get it really right, and there's no incentive to do it.) I know of one
implementation of UUCP done outside AT&T which was done by watching the line
and testing against AT&T implementations, and it's in a commercial product.
I don't think AT&T has any objection (but of course, if you asked them, they
would have their lawyers take two years to decide.)

On the other hand, the CODE implementing UUCP is certainly considered to
be AT&T proprietary, as is the rest of UNIX. But how many thousands of
students have seen it?

>Private protocols should be discouraged as much as possible. If a protocol is
>useful enough to consume part of the Internet namespace, it is useful enough
>to be documented for the rest of the Internet community. My feeling is that
>if there MUST be a private protocol assignment it should be "one port per
>organization", and that organization should make some arrangement to identify
>which of their private protocols they way (e.g. the first octet from the user
>agent identifies "MIT protocol #n", or "Symbolics protocol #n", etc.)

I can assure you that if AT&T were to be assigned a single TCP socket
to multiplex on, things would immediately become totally unworkable.
After all, there are 16 bits worth of sockets out there! That's a lot
of room.

By definition, any new experimental protocol invented by a commercial
organization is going to be proprietary, at least initially. Getting
it published as an RFC requires a fairly major management decision.
Management has a lot of things to take into account in making such a
decision, and the open nature of the ARPANET community is only one
factor in that decision. They are concerned about things like sales,
competition, and lead time on development. Good arguments can be made
for the use of an industry standard protocol as a selling point, but in
a new area, there probably aren't any industry standards. Depending on
lots of factors, the protocol might be published quickly and pushed as
an XXX standard (fill in your favoriate standards org for XXX) such as
Starlan or Ethernet; it might be published later, after developers have
had a chance to implement it and evaluate it (and gain lead time on
competitors - IBM did this with their PC and it still created an
industry standard); it might be sold under license to other vendors; or
it might be kept a trade secret.


This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:07 GMT