Re: Pointers to whois++ documents
Alan Emtage <bajan@bunyip.com> Wed, 17 November 1993 22:14 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14729; 17 Nov 93 17:14 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14723; 17 Nov 93 17:14 EST
Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa24030; 17 Nov 93 17:14 EST
Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA07378; Wed, 17 Nov 93 12:30:25 PST
X-Orig-Sender: ietf-wnils-request@ucdavis.edu
Received: from mocha.bunyip.com by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA02599; Wed, 17 Nov 93 11:32:51 PST
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10095 (mail destined for jcgargano@ucdavis.edu) on Wed, 17 Nov 93 14:34:22 -0500
Message-Id: <9311171934.AA10095@mocha.bunyip.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Alan Emtage <bajan@bunyip.com>
Date: Wed, 17 Nov 1993 14:34:22 -0500
In-Reply-To: Peter Deutsch's message as of Nov 16, 11:25
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
To: Peter Deutsch <peterd@bunyip.com>, Chris Weider <clw@merit.edu>, ietf-wnils@ucdavis.edu
Subject: Re: Pointers to whois++ documents
Cc: jcgargano@ucdavis.edu
This is just FYI... the current Bunyip server does not implement the Protocol Spec as of the last draft due to problems we had in trying to code it as written. The README file in the distribution has a section called "PROTOCOL CHANGES" which document these. I've included it here. These were posted to the list when we released the server, however I don't remember much discussion. Peter has said he'd rewrite the draft to make this changes if no one objects. Here they are again: PROTOCOL CHANGES The following are coded up in the server and will be submitted to the working group as proposed changes to protocol. 1) The HOLD attribute has changed from a unary to binary operator. You need to say "hold=true" rather than just "hold". 2) The LIST, COMMANDS and CONSTRAINTS, commands create "virtual" templates for their responses. For example, the CONSTRAINTS command returns: # FULL 4 # constraint HOLD Name: HOLD Description: Hold the connection for next query Values: <"true","FALSE"> Scope: global # constraint MAXHITS Name: MAXHITS Description: Maximum number of responses Values: <100> Scope: global # constraint LOGICAL Name: LOGICAL Description: Logical connection between search terms Values: <"AND","or"> Scope: global # constraint MATCH Name: MATCH Description: Type of match Values: <"STANDARD","initial"> Scope: local # END Which gives the contraints supported, a description, the valid values for the constraint and whether they are local or global in scope. Defaults values are given in CAPS. 3) System responses (starting with a '%') have status numbers, following the conventions for the FTP protocol (rfc 959). Values of 100 - 199 are informational and temporary, 200 - 299 are status values and permenant. 300 - 399 are non fatal temporary warnings, 400 - 499 are permenant warnings and 500 - 599 are fatal permenant errors. 4) ABRIGED responses are given after 10 hits, not 2 as in the RFC. The WAIS search system does not permit the determination of what element of the inital search query caused a match, so they do not return this value. It is possible that very few search engines will allow this and this may need to be reviewed. The ABRIDGED responses here have degenerated to HANDLE responses. -- -Alan ------------------------------------------------------------------------------ Alan Emtage, "The Left in Canada is more gauche Bunyip Information Systems, than sinister" Montreal, CANADA -The Economist bajan@bunyip.com Voice: +1 (514) 875-8611 Fax: +1 (514) 875-8134
- Pointers to whois++ documents Chris Weider
- Re: Pointers to whois++ documents Peter Deutsch
- Re: Pointers to whois++ documents Joan Gargano
- Re: Pointers to whois++ documents Alan Emtage
- Re: Pointers to whois++ documents Mark Prior
- Re: Pointers to whois++ documents Alan Emtage
- Re: Pointers to whois++ documents Mark Prior