Re: Whois++ constraints

[Mark Prior <[e-mail]>]

     Just a quick comment on something that went by a couple of
     days ago..

     [ You wrote: ]
     .  .  .
     >      > 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 may be exposing my ignorance here, but I assume "sn" is
     something special in X.500 that would indicate that it
     turns up a gazillion times? If so, it should still be
     handled by the default response mechanism, which specifies
     a low-output default when there is a large number of
     responses. The current placeholder in the doc specify a
     SUMMARY response if there are more than ten hits, unless
     there is an overriding global constraint.

Sorry I should have used the "long" form, for those not familiar with
X.500 sn is the short form of surname. Surname is a required attribute
for all objects in a X.500 directory of type person, ie every person
record is guaranteed to have a surname attribute.

What I was alluding to (obscurely as usual :-) is something that the
people deploying X.500 based Directories have run up against (and
something Whois++ won't avoid either) in that many organisations will
want to avoid the possibility of people trawling their directory for
data. Quipu (one of the X.500 implementations, and the one I use) has
a mechanism whereby the administrator can limit the number of records
that can be returned as a result of a search, in my case it's 10. This
means that no matter what constraint you place on the whois search you
will get at most ten entries back.

     We could also think about allowing each server to specify
     its own particular MAXHITS value as part of the response
     to the CONSTRAINTS command (which is used to list valid
     constraints for a particular server). If any MAXHITS
     larger than this is specified, I would assume an
     appropriate WARNING should be generated along with the
     response, assuming it mattered.

That is what you will get from my server, eg

% whois -h wp smith
Whois++ Service at The University of Adelaide, AU.
For more information about this service send the "help" command.

% Partial results only - a size limit was exceeded, only 10 entries returned
#ABRIDGED 10
 "cn=Angela SMITH, ou=User Services, ou=Barr Smith Library, o=The University of
+ Adelaide, c=AU" person
 "cn=Christopher SMITH, ou=User Services, ou=Barr Smith Library, o=The
+ University of Adelaide, c=AU" person
 "cn=Joan Marie SMITH, ou="Horticulture, Viticulture and Oenology", ou=Faculty
+ of Agricultural and Natural Resource Sciences, o=The University of Adelaide,
+ c=AU" person
 "cn=Anthony Shane SMITH, ou=Plant Science, ou=Faculty of Agricultural and
+ Natural Resource Sciences, o=The University of Adelaide, c=AU" person
 "cn=Carole Lesley SMITH, ou=Plant Science, ou=Faculty of Agricultural and
+ Natural Resource Sciences, o=The University of Adelaide, c=AU" person
 "cn=David Brian SMITH, ou=Plant Science, ou=Faculty of Agricultural and Natural
+ Resource Sciences, o=The University of Adelaide, c=AU" person
 "cn=Sarah Elizabeth SMITH, ou=Soil Science, ou=Faculty of Agricultural and
+ Natural Resource Sciences, o=The University of Adelaide, c=AU" person
 "cn=David Jonathon SMITH, ou=English Language and Literature, ou=Faculty of
+ Arts, o=The University of Adelaide, c=AU" person
 "cn=Derek Leon SMITH, ou=Geography, ou=Faculty of Arts, o=The University of
+ Adelaide, c=AU" person
 "cn=Carolyn Anne SMITH, ou=Dentistry, ou=Faculty of Dentistry, o=The University
+ of Adelaide, c=AU" person
#END

Note, Abridged format = Handle format with my server.

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

     I would think so, and again I would think each case would
     be adequately handled by the default response mechanism.

Well I'm not sure this is really sensible but anyway onto something
slightly different, what is you interpretation of the following queries?

1.      attribute=telephone;value=*5680;attribute=fax
2.      attribute=telephone;attribute=fax;value=*5680

According to my understanding on your intent, gained from talking to you
at the IETF rather than the doc, (1) means
Find all records with a telephone attribute, now from that list give me
the records where the telephone attribute has a value ending with 5680.
From this set return to me all those records that have also have a fax
attribute.
I don't really understand what (2) should return (ie I'm not sure it's
equivalent to (1)) as I'm not sure which attribute (or both) the value
should be associated with.

Comments?

Mark.