Re: Pointers to whois++ documents

Mark Prior <mrp@itd.adelaide.edu.au> Thu, 18 November 1993 01:12 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16609; 17 Nov 93 20:12 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16603; 17 Nov 93 20:12 EST
Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa28065; 17 Nov 93 20:12 EST
Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA23972; Wed, 17 Nov 93 15:45:45 PST
X-Orig-Sender: ietf-wnils-request@ucdavis.edu
Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA22714; Wed, 17 Nov 93 15:28:29 PST
Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.28) id AA27633; Thu, 18 Nov 1993 09:59:35 +1030
Message-Id: <9311172329.AA27633@jarrah.itd.adelaide.edu.au>
To: Alan Emtage <bajan@bunyip.com>
Cc: ietf-wnils@ucdavis.edu
Subject: Re: Pointers to whois++ documents
In-Reply-To: Your message of "Wed, 17 Nov 1993 14:34:22 CDT." <9311171934.AA10095@mocha.bunyip.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 18 Nov 1993 09:59:35 +1030
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark Prior <mrp@itd.adelaide.edu.au>

     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?

     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.

     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?

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

Mark.