Arnd Vehling wrote:

Tobias Cremer wrote:

...

Yes, but only for the same kind of attributes, right? Means I cannot search for admin-c and mnt-by in the same -i query like I would do with

...

whois -i tech-c,mnt-by toc76-ripe,CW-EUROPE-GSOC

but of course

whois -i admin-c,tech-c toc76-ripe

works.

Right, i need to do searches on different inverse-attributes in one query. And i would like to only get those objects back which match both inverse attributes.

...

So the question if it is a OR or a AND operation is a second point beneath that and would apply to searching only i.e. "pn" attributes and serching multiple different attributes.

Right, would be cool to be able to specify if one wants to "AND" or "OR" the returned objects.

@DevTeam, would it be possible to get this in sometime soonish?

Actually, it might be nice to rethink the query mechanism a bit further. There are a few limitations with the current setup. Problem 1: ROUTE/ROUTE6 searches There is no way to specify that you want only ROUTE or ROUTE6 objects with a specific "origin:" attribute: $ whois -T route -r 62.23.0.0/16 route: 62.23.0.0/16 descr: FR-COLT-FRANCE origin: AS8220 ... route: 62.23.0.0/16 descr: FR-COLT-FRANCE origin: AS6675 ... Problem 2: PERSON searches Searching for PERSON objects sometimes returns results that are not desired. This can happen if the name in a person object matches the string of a "nic-hdl:" attribute, like when looking for "KIRI": $ whois -T person -r kiri | egrep '^((person|nic-hdl):|$)' person: Kiri Butler nic-hdl: KB9435-RIPE person: Kiri Georgiou nic-hdl: Kir5-RIPE person: Aasish Kiri nic-hdl: AK3283-RIPE person: Robert Kirmayer nic-hdl: KIRI The database has no way to know if you are looking for the "nic-hdl:" or the "person:" attribute that matches. Possible Solution A: multiple inverse queries We can solve problem 1 (multiple "origin:" attributes), and Tobias' original problem, by allowing multiple inverse queries in a logical AND operation. We'd need to change the meaning of multiple "-i" flags though. Right now, if you type: $ whois -i tech-c -i admin-c swk1-ripe It is the same as: $ whois -i tech-c,admin-c swk1-ripe The database *could* be changed to interpret them differently: $ whois -i tech-c,admin-c toc76-ripe Would work the same, but if you have more than one "-i" flag, you would list the keys separately: $ whois -i tech-c -i mnt-by toc76-ripe CW-EUROPE-GSOC Limitations are: o This does not work for problem 2 (ambiguous "person:" and "nic-hdl:" attributes). o It is not exactly simple for the average user to understand. Possible Solution B: SQL-like searches While we would be reluctant to allow actual SQL searches into the database, we might be able to open the database up to an SQL-like search language: $ whois --search tech-c='TOC76-RIPE' and mnt-by='CW-EUROPE-GSOC' $ whois --search nic-hdl='kiri' Problems: o One could perform some extremely non-optimal searches. (We could possibly avoid most of this problem by requiring that some key is present in the search.) o A second query language for users to learn. We would be unlikely to be able to implement either of these before the RIPE meeting, but could begin before then (after the pending abuse changes). Apologies for the long delay in replying, but I was nervous about raising the idea of SQL-like searches, and wanted to wait before mentioning it in public. -- Shane Kerr Software Engineering Department Manager RIPE NCC

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Shane, all, Shane Kerr wrote:

Problem 2: PERSON searches

[...]

The database has no way to know if you are looking for the "nic-hdl:" or the "person:" attribute that matches.

Possible Solution A: multiple inverse queries

We can solve problem 1 (multiple "origin:" attributes), and Tobias' original problem, by allowing multiple inverse queries in a logical AND operation. We'd need to change the meaning of multiple "-i" flags though.

[...]

Limitations are:

o This does not work for problem 2 (ambiguous "person:" and "nic-hdl:" attributes).

This would not be a problem when looking for non-ambiguous attributes like a handle. I'd like to guess that such a query is performed in most cases by searching a handle and i.e. a mntner instead of a real name and other attributes. Don't know if this is possible to implement, however...

o It is not exactly simple for the average user to understand.

If the other, simple query type with just one -i option continues unchanged, there would be no difference to anybody not interested in advanced queries.

Possible Solution B: SQL-like searches

While we would be reluctant to allow actual SQL searches into the database, we might be able to open the database up to an SQL-like search language:

$ whois --search tech-c='TOC76-RIPE' and mnt-by='CW-EUROPE-GSOC'

$ whois --search nic-hdl='kiri'

Problems:

o One could perform some extremely non-optimal searches. (We could possibly avoid most of this problem by requiring that some key is present in the search.)

It would be an affordable disadvantage being forced to use specific attributes, im my opinion - depending on what attributes that will be, of course :-)

o A second query language for users to learn.

Same as above, isn't it? It's an advantage for those how need this feature and doesn't hurt those that only need "simple" queries. It's a second query language to learn anyway, both if implemented in the RIPE Dbase software and if done in CRISP, if I get that right. Regards: Tobias - -- Tobias Cremer M.A. IP Admin Engineer Cable & Wireless Telecommunication Services GmbH Landsbergerstr. 155 80687 Muenchen Germany Tel +49 89 926 99 0 -- FAX +49 89 926 99 180 -- COMNET 7 49 9169 www.cw.com/de - -- Every message GnuPG signed -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCFILJhC6y11CNwvcRAn+IAKDWZjBtvBqgGkKxXzSG5Uo81GXupACfZjY4 q4cABiJ+xs5xl58Dv0Qidq0= =IXZe -----END PGP SIGNATURE-----