MRC%PANDA@SUMEX-AIM.ARPA (Mark Crispin) (05/14/86)
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 -- -------
mark@cbosgd.ATT.COM.UUCP (05/18/86)
>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 property. >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. Mark