Re: Whois++ constraints

[Mark Prior <[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.... :-(

Obviously flying with the wrong airline. I use Continental and the
miles you get from flying the Pacific once is enough to get an upgrade
on the next one (providing you are in their Elite program but that
only takes one flight across the Pacific and US).

     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.

Fine, I was just leaving the BNF generic by not specifying what
constraint types were valid (and so what constraint values applied).

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

Well if that's what you want to do then I will make my server do that
(it will smash into my DSA's search limit pretty quickly though).

I assume this also applies to the queries
        template=person
        value=prior

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

Now to get the working code bit too :-)

     Now, I'm off...

I've heard that one before :-)

Mark.