Re: Whois++ constraints

Mark Prior <> Thu, 08 April 1993 08:54 UTC

Received: from by (5.61/UCD2.04) id AA12006; Thu, 8 Apr 93 01:54:12 -0700
Received: from by (5.61/UCD2.04) id AA19154; Thu, 8 Apr 93 00:59:29 -0700
Received: by (5.61/UCD2.04) id AA10026; Thu, 8 Apr 93 00:50:15 -0700
Received: from by (5.61/UCD2.04) id AA09736; Thu, 8 Apr 93 00:42:09 -0700
Received: by with SMTP (5.61+IDA+MU/UA-5.26) id AA06670; Thu, 8 Apr 1993 17:09:43 +0930
Message-Id: <>
To: Peter Deutsch <>
Subject: Re: Whois++ constraints
In-Reply-To: Your message of "Thu, 08 Apr 1993 03:14:39 -0400." <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 08 Apr 1993 17:09:41 +0930
From: Mark Prior <>

     Welcome back. I trust it wasn't too gruelling a flight
     across the pond...

Flying business class helps a lot but it is still a long way, I wish
they had a Concorde over the Pacific.

     [ You wrote: ]

     > Can we please agree to change the syntax for the constaints before our
     > respective servers are released.
     > I would suggest the following syntax
     > <keyword> [ "=" <value> ] { "," <keyword> [ "=" <value> ] }

     I see no problems with this as the general structure of
     global constraints, although we'll obviously have to watch
     things to be sure that the BNF allows for the various
     legal constaints and options. One example that comes to
     mind is that I've been assuming so far that we can allow
     only one of the possible output format specifiers per
     query. Ditto for search type and so on.

Well I think that is a sematics issue but the specification should
mention that the intent is that would only be one output format type.

     # The simple, subtractive nature of WHOIS++ queries, and the lack of
     # Boolean search operations, could lead to possible ambiguities if
     # certain combinations of search terms were allowed. For example, if the
     # user were to specify more than one template type for a given search
     # either no matches could occur (since it is implicit that no record can
     # have more than one template type associated with it) or a logical OR
     # operation would have to be inferred.
     # To handle such cases, the second and all subsequent terms are to be
     # discarded and a suitable warning returned along with the results of
     # the search.  This occurs when either multiple template types, or
     # multiple handles are specified in a search.

     Thus, we _could_ handle such things as multiple output
     format specifiers the same way I've proposed handling
     multiple template or handle specifiers - accept the first,
     then toast the rest, then run the query.

The other problem that should be addressed is incomplete
specifications. For example what does the following mean?


     The problem with this approach for output format is that if
     somebody goofs, it's conceivable that they end up
     specifying (and thus receiving) lots of unwanted full
     record search results (which when we have MIME output
     sound and video is going to be a bear.. :-(
     Because of this, in the case of output format it may be
     better if we were to take a more conservative approach and
     simply declare an error and bail out.

That is the approach I have taken.

     > I would also like to transform the constraints "full", "handle",
     > "abridged", and "summary" into "format=(full|handle|abridged|summary)".
     > This will allow us to easily add formats, such as mime, later on
     > without extending the keywords into infinity.

     I definitely agree. Consider the doc revised on this (unless
     someone else squeals RSN??).

OK I will change my code.

     It's late enough here now that I'm going to call it a
     night. As more issues come up I'll post (unless Mark beats
     me to it?? :-)

Well although it's a more reasonable time here (5pm Friday) I think I
will go home and read all those books I bought at Computer Literacy
instead :-).