Re: Holding connections open; syntax ambiguity?

dank@blacks.jpl.nasa.gov Thu, 08 April 1993 17:19 UTC

Sender: ietf-wnils-request@ucdavis.ucdavis.edu
Message-Id: <9304081613.AA09667@blacks.jpl.nasa.gov>
To: Peter Deutsch <peterd@bunyip.com>
Cc: dank@blacks.jpl.nasa.gov, ietf-wnils@ucdavis.ucdavis.edu, dank@blacks.jpl.nasa.gov
Subject: Re: Holding connections open; syntax ambiguity?
In-Reply-To: Your message of "Thu, 08 Apr 93 03:53:29 EDT." <9304080753.AA26894@expresso.bunyip.com>
Date: Thu, 08 Apr 1993 09:13:31 -0600
From: dank@blacks.jpl.nasa.gov

Me:
> Come to think of it, it seems that comma is a bad choice to set off options,
> since it is used to set off first names (according to an early document on
> the servers).  
Peter:
>I don't recall ever having multiple search names like this...

Joan's document does specify the use of commas:
    whois smith,j     exact match on last name, first name begins with "J"
And current whois servers depend on it:
    % whois -h caltech.edu "smith, lori"      (query is just SMITH, LORI<CR>)
    Smith, Lori M.  (LS6)    lms@hydra0.caltech.edu
    % whois -h caltech.edu "lori smith"       (query is just LORI SMITH<CR>)
    No match found for LORI SMITH
so I hope we can continue to support it.
BTW, if we're going to continue to support the old 'whois' commandline client,
it's important that we not force the users to insert quotes in the search
string, since the Unix commandline interpreter strips quote chars and uses
them itself.

I'm really looking forward to having a consistent treatment of search keys.
Right now, some servers treat spaces as matching any intervening string; others
treat them as word delimiters and do exact word searches.
- Dan K.

Re: Holding connections open; syntax ambiguity? Peter Deutsch
Re: Holding connections open; syntax ambiguity? dank