Re: Pointers to whois++ documents

Mark Prior <> Fri, 19 November 1993 01:20 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa15095; 18 Nov 93 20:20 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15087; 18 Nov 93 20:20 EST
Received: from by CNRI.Reston.VA.US id aa28176; 18 Nov 93 20:20 EST
Received: by (4.1/UCD2.05) id AA26309; Thu, 18 Nov 93 16:02:29 PST
Received: from by (4.1/UCD2.05) id AA23973; Thu, 18 Nov 93 15:36:53 PST
Received: by with SMTP (5.61+IDA+MU/UA-5.28) id AA14465; Fri, 19 Nov 1993 10:08:30 +1030
Message-Id: <>
To: Alan Emtage <>
Subject: Re: Pointers to whois++ documents
In-Reply-To: Your message of "Thu, 18 Nov 1993 11:32:06 CDT." <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 19 Nov 1993 10:08:29 +1030
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark Prior <>

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

I don't recall having any problems implementing it.

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

So am I correct in assuming that you are proposing that the entire
meaning of the message is encoded in the three digit code which can
then be translated into a local language/format by the client, ie my
client could just say


rather then something like

%F Cannot connect to X.500 Directory Service

     >      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

That's very Unix-centric of you. What about people you use some other
operating system without pipes. I know how you can redirect stuff to a
file in VMS but I suspect most of our "normal" users do not.