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