Re: Whois++ constraints

[Peter Deutsch <[e-mail]>]

[ Somebody wrote: ]

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

Grrr. (I've made the trip a dozen times, but always cattle
class.... :-(

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

I'm fuzzy enough to be more unclear than usual. All I was
trying to say was that it should have something like:

SEARCH = { exact | substring | fuzzy | regex | <X-form> }

The text now has more words about what is legal, to
hopefully clarify the semantics as well.

> 
>      # 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?
> 
>         attribute=sn

I'm not sure I see the problem. This is just a search for
all records with an attribute "sn". It's conceivable there
are some, if not the server returns zero hits (or am I
missing something?).

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

Sounds like rough consensus to me...  :-)

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

Us, too...

BTW, there was a meeting of something called the
"Integrated Directory Services" Working Group in Columbus
(working to track both WHOIS and X.500. As part of this,
I've tentatively volunteered to track WHOIS++
implementations, so if you're planning to develop code for
this spec (clients or servers) please keep me abreast of
your progress. If and when the list is sufficiently long,
we will consider putting together an Implementation Survey
document.

Now, I'm off...


					- peterd

-- 
------------------------------------------------------------------------------
Peter Deutsch,                                       [e-mail]
President,                                        [phone]  (phone)
Bunyip Information Systems Inc.                    [phone]  (fax)

  "any sufficiently advanced magic is indistinguishable from technology"
           (- with apologies to Arthur C. Clarke, who almost got it right...)
------------------------------------------------------------------------------