Hi David! => WRT "fuzzy" / wildcard matches - it would make the RIPE-DB software => more user friendly (and maybe more attractive for deployment by other => registries) to provide for (implicit/explicit) regexp or partial key => matches. = =To what end? Is the purpose of the database registration information =lookup or a more general white pages service? I' would suggest the =former and leave the latter to the WHOIS++/LDAP/X.500 crowd. Two things here: - local langauge problems (European National Character Sets) which make it difficult to find out about a (arbitrarily chosen) transcription. - comments from other environments, where the lack of this feature was quoted as a major obstacle to use this software 'cause this functionality is provided right now. The remark about the white pages is understood, although I don't think we should limit the sw functionality to avoid misuse :-) Thanks for throwing in your 2 yen. Wilfried.
Hi Wilfried,
=To what end? Is the purpose of the database registration information =lookup or a more general white pages service? I' would suggest the =former and leave the latter to the WHOIS++/LDAP/X.500 crowd.
- local langauge problems (European National Character Sets) which make it difficult to find out about a (arbitrarily chosen) transcription.
Local language problems? Heh. Let me introduce you to traditional Chinese with all 100,000+ characters :-). The advantage of the whois database serving as a simple registered object lookup mechanism is that you don't have to worry (too much) about gunk like local language support -- the registration database access method (whois) allows lookups on registry objects, namely inetnums, handles, domains, route objects, etc. of which people (generally :-)) are not a part. Yes, I'm arguing person: field contents should not be indexed, but I've been known as a radical in the past. Note this would have solved the problem that brought this issue up (I think).
- comments from other environments, where the lack of this feature was quoted as a major obstacle to use this software 'cause this functionality is provided right now.
If all you have is a hammer, everything begins to look like a nail. This doesn't mean you should attach a blender to your hammer to allow making more consistent puree...
The remark about the white pages is understood, although I don't think we should limit the sw functionality to avoid misuse :-)
I'm of the "simpler is better" camp. It would be nice if registry objects were defined to be strictly hierarchical in nature (addresses and domains are already there, handles are soon to be there with the addition of the -<registry> suffix (APNIC's will be -AP (not -APNIC) as soon as I can find time to write the necessary software to do the conversion), AS numbers are somewhat problematic, but there are only 64K of them and we can make RDIs hierarchical when IDRP gets out of the starting gate). This would allow a simple, programatic way of determining which registry maintains which objects (I'd like to use the DNS to do this, but rwhois is still lurking in the background). I figure it is the only way the registry database system can scale and keep up with the Internet growth rate. Flat namespaces, like people's names can be handled by other methods (I'm told centroids work, but don't know enough to have an opinion). Cheers, -drc
On Fri, 19 Jul 1996, David R. Conrad wrote:
and domains are already there, handles are soon to be there with the addition of the -<registry> suffix (APNIC's will be -AP (not -APNIC) as soon as I can find time to write the necessary software to do the conversion), AS numbers are somewhat problematic, but there are only
I find it possible that national NIC's will in the future run registries themselves. I would therefore find it a smart move for not-national NIC's to not choose 2-letter codes. -- Robert Martin-Legène (RM59), Network Manager (AS2109) DKnet, Fruebjergvej 3, DK-2100 København Ø, Denmark, +45 39 17 99 00
Hi David,
database serving as a simple registered object lookup mechanism is that you don't have to worry (too much) about gunk like local language support -- the registration database access method (whois) allows lookups on registry objects, namely inetnums, handles, domains, route objects, etc. of which people (generally :-)) are not a part.
Yes, I'm arguing person: field contents should not be indexed, but I've been known as a radical in the past. Note this would have solved the problem that brought this issue up (I think).
I'm of the "simpler is better" camp. It would be nice if registry
There are more radical approaches possible like just stopping the whois service alltogether. People can easily get the ftp files and run grep. It's much simpler and solves the problem completely :-).
objects were defined to be strictly hierarchical in nature (addresses and domains are already there, handles are soon to be there with the addition of the -<registry> suffix (APNIC's will be -AP (not -APNIC) as soon as I can find time to write the necessary software to do the conversion), AS numbers are somewhat problematic, but there are only
This is very much appreciated. Why don't you choose the more radical approach and use the APNIC extension when you are already doing an conversion? It is much easier for everybody if the 'source:' and NIC handle postfix match (we can do some automatic referral tricks when we standarize on this, and yes we can also make the 'source:' names hierarchical). David K.
participants (4)
-
David R. Conrad -
David.Kessens＠ripe.net -
Robert Martin-Legene -
Wilfried Woeber, UniVie/ACOnet