Re: Pointers to whois++ documents

Alan Emtage <bajan@bunyip.com> Thu, 18 November 1993 17:48 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07978; 18 Nov 93 12:48 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07972; 18 Nov 93 12:48 EST
Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa15832; 18 Nov 93 12:48 EST
Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA19469; Thu, 18 Nov 93 08:59:03 PST
X-Orig-Sender: ietf-wnils-request@ucdavis.edu
Received: from mocha.bunyip.com by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA17160; Thu, 18 Nov 93 08:30:26 PST
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11700 (mail destined for ietf-wnils@ucdavis.edu) on Thu, 18 Nov 93 11:32:07 -0500
Message-Id: <9311181632.AA11700@mocha.bunyip.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Alan Emtage <bajan@bunyip.com>
Date: Thu, 18 Nov 1993 11:32:06 -0500
In-Reply-To: Mark Prior's message as of Nov 18, 9:59
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
To: Mark Prior <mrp@itd.adelaide.edu.au>
Subject: Re: Pointers to whois++ documents
Cc: ietf-wnils@ucdavis.edu

>      PROTOCOL CHANGES
> 
>      1) The HOLD attribute has changed from a unary to binary operator. You
>      need to say "hold=true" rather than just "hold".
> 
> I fail to see the point of this, what is the problem with just having
> an unary operator? Are you proposing that some servers may have hold
> on by default?

The problem is one of parsing the input. As constructed in the current
draft the parsing of unary constraint operators is difficult (and I
believe "impossible" in some cases in that the results are ambiguous). 

>      2) The LIST, COMMANDS and CONSTRAINTS, commands create "virtual"
>      templates for their responses. For example, the CONSTRAINTS command
>      returns:
> 
> I assume "virtual" means that you can't construct a search query to
> find them. If this is true then that's OK.

Correct. It's just so that the client will have a consistent response
format to deal with so that you don't have to have separate parsers for
different kinds of responses.

>      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.
> 
> Well if you are going to have 3 digit codes are you going to define
> what the other digits mean or is this just a silly way of emulating
> VMS's I, W, E, F severity levels?

This is to allow system responses to have a language-independent format.
We will need to define what each response means (much like FTP, SMTP,
NNTP etc) but this is much easier than having to deal with
english-language system responses which would then have to be translated
or strcmp()'d to see what the response is. It also gives much more
flexibility to handle expanded response modes.

>      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.
> 
> I think it would be better, until smart formatting whois++ clients are
> widely deployed, to retain the 2 item limit between (default) full and
> abridged/handle. If you increase it to 10 that means that potentially
> you can get 10 full listing flashing by you on your screen. That's
> fine for people who have window systems with scrollbars but there are
> still a huge number of people with dumb terminals. This is bad enough
> with something like archie where only the last matches (probably not
> in your country) will be left on the screen but with whois++ it
> probably means the hit you wanted has scrolled off the top :-)

That's why we have file redirects, script(1), more(1), and
less(1).


-- 
-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