ROBINSON@BITNIC.BITNET (Andrew T. Robinson) (02/05/90)
I think what is required is not so much standardized tools, but guaranteed interfaces at various levels in the protocol stack--with a DEFAULT set of tools that use these interfaces, provided when a node joins BITNET. Because BITNET *is* a multivendor network with no forseeable limit on host system types, it is basically impossible to write a single set of tools that will work for everyone. It is difficult even to find a least-common- denominator in terms of system services, compilers, etc. Well designed interface specifications, on the other hand, are a more reasonable (if not particularly easier) goal. In general, those specifications should be opearating system independent (not use terminology or depend on services provided by a particular operating system) *and* protocol independent (not depend on "low" level protocols, such as NJE, TCP/IP, RFC822, etc). If those goals are to be acheived, people will have to stop thinking in terms of VM vs. Unix vs. VMS, TCP/IP vs. OSI vs. NJE, RFC822 vs. X.400, etc., and START thinking in terms of BITNET: What services we want to provide to the end user. Binding BITNET into existing or proposed protocols is a good way to ensure its eventual demise. By knowing what services you want to offer, you can define access methods that are largely independent of implementation. Such specifications not only make movement among protocol suites possible, but they do NOT inhibit individual/organizational creativity in the development of network applications the way a "standard" set of tools does (if it looks like a duck, and quacks like a duck, it's a duck). Andy
LVARIAN@PUCC.BITNET (Lee C. Varian) (02/05/90)
Andy, Thee speaks my mind. Lee Varian Princeton University
GETTES@PUCC.BITNET (Michael R. Gettes) (02/05/90)
On Sun, 4 Feb 90 11:52:06 EST Andrew T. Robinson said: >By knowing what services you want to offer, you can define access methods >that are largely independent of implementation. Such specifications not only >make movement among protocol suites possible, but they do NOT inhibit >individual/organizational creativity in the development of network application >the way a "standard" set of tools does (if it looks like a duck, and quacks >like a duck, it's a duck). How true. But if the duck has babies instead of laying eggs, then you have a platypus, which is just a confused duck in my mind. BITNET could be seen as a platypus as well. We still have the "platypus and egg" problem even if we attempt to define services independent of standardization. I completely agree with this concept -- I only wish the concept could bloom within the confines of reality, but alas, some things are fantastical. Does the term "defacto" ring a bell? /mrg
michael@MAINE.MAINE.EDU (Michael Johnson) (02/05/90)
>I think what is required is not so much standardized tools, but guaranteed >interfaces at various levels in the protocol stack--with a DEFAULT set of >tools that use these interfaces, provided when a node joins BITNET. That's reasonable. It satisfies my reason for bringing this up, which is that we need consistent interfaces. >If those goals are to be acheived, people will have to stop thinking in terms >of VM vs. Unix vs. VMS, TCP/IP vs. OSI vs. NJE, RFC822 vs. X.400, etc., and >START thinking in terms of BITNET: What services we want to provide to the >end user. Binding BITNET into existing or proposed protocols is a good way >to ensure its eventual demise. Unfortunately, I don't think we can avoid making choices like RFC822 vs X.400, because these are implemented ABOVE the network layer. If we are to have mailers being able to communicate, we're going to need to have SOME standards engraved in stone, at least for the reasonable future. >By knowing what services you want to offer, you can define access methods >that are largely independent of implementation. Such specifications not only >make movement among protocol suites possible, but they do NOT inhibit >individual/organizational creativity in the development of network applications >the way a "standard" set of tools does (if it looks like a duck, and quacks >like a duck, it's a duck). > >Andy Michael Johnson "We are the Priests of the Temples University of Maine System of Syrinx. Our great computers fill Computing and Data Processing Services the hallowed halls." - Neil Peart