Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!bellcore!ulysses!mhuxr!mhuxn!ihnp4!ucbvax!SUMEX-AIM.ARPA!MRC%PANDA
From: MRC%PANDA@SUMEX-AIM.ARPA (Mark Crispin)
Newsgroups: mod.protocols.tcp-ip
Subject: private/proprietary protocols
Message-ID: <12206686220.6.MRC@PANDA>
Date: Wed, 14-May-86 15:30:04 EDT
Article-I.D.: PANDA.12206686220.6.MRC
Posted: Wed May 14 15:30:04 1986
Date-Received: Fri, 16-May-86 05:16:39 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 24
Approved: tcp-ip@sri-nic.arpa

Personally, I think that proprietary protocols have no place in the Internet
research/military community.  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.

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 have occasionally been frustrated with the delays and paperwork involved
in getting numbers assigned by Postel, but at the same time I feel these
procedures are necessary.  If anything, Jon has erred on the side of giving
out a number in questionable circumstances.  I vote to keep the current
procedure; if it ain't broke don't fix it.

-- Mark --
-------