[64] in Information Retrieval
ID protocol
daemon@ATHENA.MIT.EDU (ganderso@Athena.MIT.EDU)
Wed Feb 12 16:26:17 1992
From: ganderso@Athena.MIT.EDU
To: saltzer@MIT.EDU
To: elibdev@MIT.EDU
Date: Wed, 12 Feb 92 16:24:45 EST
Thought people might be interested in this message.
Greg
------- Forwarded Message
Received: by ATHENA-PO-3.MIT.EDU (5.45/4.7) id AA17571; Wed, 12 Feb 92 09:31:54 EST
Received: from ugav2.cc.uga.edu by Athena.MIT.EDU with SMTP
id AA28691; Wed, 12 Feb 92 09:31:30 EST
Message-Id: <9202121431.AA28691@Athena.MIT.EDU>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
with BSMTP id 0287; Wed, 12 Feb 92 09:30:57 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8915;
Wed, 12 Feb 92 09:30:56 EST
Date: Wed, 12 Feb 1992 09:35:42 EDT
Reply-To: "Z39.50 Implementors Workshop" <Z3950IW%NERVM.BITNET@uga.cc.uga.edu>
Sender: "Z39.50 Implementors Workshop" <Z3950IW%NERVM.BITNET@uga.cc.uga.edu>
From: Joe Zeeman <zeeman@CRC.SOFKIN.CA>
Subject: Re: ID ACTION: draft-ietf-netdata-netdata-02.txt (fwd)
X-To: z3950iw@nervm.nerdc.ufl.edu
To: Multiple recipients of list Z3950IW <Z3950IW%NERVM.BITNET@uga.cc.uga.edu>
This from the ietf might be of interest to the ZIG list
Joe Zeeman
___________________________________________________________________
Forwarded message:
> From owner-ietf@isi.edu Wed Feb 12 04:48:16 1992
> Message-Id: <m0lE74N-000HwCC@heifetz.msen.com>
> Date: Tue, 11 Feb 92 18:39 EST
> From: emv@msen.com (Edward Vielmetti)
> To: ietf@isi.edu
> Subject: Re: ID ACTION: draft-ietf-netdata-netdata-02.txt
> Newsgroups: list.ietf
> In-Reply-To: <9202110947.aa09794@NRI.NRI.Reston.VA.US>
> Organization: MSEN, Inc. -- Ann Arbor, MI
>
> In article <9202110947.aa09794@NRI.NRI.Reston.VA.US> you write:
> >
> >This memo defines a protocol for use with relational database systems
> >in a TCP/IP based internet environment. This protocol is intended to
> >make interoperability among different database systems possible. It
> >is built on RPC (Remote Procedure Call) with a client/server type of
> >relationship. This document also defines the concept of Unit of Work.
> >The work of Network Database is involved with Data Conversion,
> >Security, I/O Buffer Management, and Transaction Management.
> >They will be described one by one in this document.
>
> There are several existing network database protocols in real-life use
> over the internet right now today. I am concerned that the IETF may
> be heading down an evoluationary dead end with this one approach.
>
> Existing protocols which might be worth of standardization in this
> field include:
>
> - SQL over TCP/IP, available today from various vendors;
> - NISO Z39.50(1988), used in several non-interoperable implementations
> right now (NOTIS and WAIS of note), and with several sets of people
> working to produce a Z39.50(1992) which would in fact interoperate;
> - the Lamont View Server, a protocol which has been used to do client/server
> table extractions from geological data sets and which has seen
> some use in the GIS community
> - humble, lovable old 'finger', which has been used to convey all sorts
> of queries to all sorts of servers, and upon which successful simple
> interfaces to several much more complicated systems have been built.
>
> I am not aware of a single implementation of the Network Database Protocol
> with any field operational experience on the greater Internet. Nor
> does it appear to be possible to construct such an implementation from
> the draft protocol documents. The approach given (ASN.1 encoded SQL
> over Sun RPC) is not a bad design for what it's worth, but large amounts
> of important design details - semantics of a COMMIT over RPC, interoperability
> if desired with non-SQL systems, or even for that matter very basic
> references to the various technologies assumed in the drafts - are
> completely missing.
>
> The internet needs a remote query protocol to handle the diverse needs
> of searches on remote full text databases, remote SQL engines, library
> card catalogs, numerical databases, and the like. This "netdata"
> protocol does not appear to be it. I would urge the IESG to make
> a critical appraisal of the development to date and determine whether
> this is going to lead to something useful, and to evaluate the work
> of the Z39.50 implementor's workshop to determine whether that approach
> might be more reasonable for the network as a whole to buy into.
>
> --
> Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
> MSEN Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 741 1120
>
------- End of Forwarded Message
