From linda at sat-tel.com Thu Feb 1 10:09:53 2001 From: linda at sat-tel.com (Linda) Date: Thu, 01 Feb 2001 10:09:53 -0500 Subject: The future of SWIP References: <20010131181218.B6744@uu.net> Message-ID: <3A797C40.28604E32@sat-tel.com> I agree with David's logic regarding option #2 and why it is not a good idea. I also agree with both Dawn and David that swip should be more automated. Linda Dawn Martin wrote: > I agree, SWIP should be more automated. > > I don't see why there is a need for upstreams to be the only ones > to be able to change an assignment to an allocation. I would > think it is a common enough change and if the downstream > wants to SWIP their reassignments, why make it a longer process? > In the past the downstream could contact ARIN an have them > put a maintainer ID on the block. > > -Dawn > > Quoth David R Huberman (huberman at gblx.net): > > Hello Ginny, > > > > I can't say I see the merits of either approach, to be honest. > > > > I am 100% against Option 2, in its current form. Education of > > downstream customers on using ARIN tools is not a viable option > > for larger providers with significant customer bases. > > > > The advantages of Option 1 seem far outweighed by the disadvantages > > as you have articulated them. A messier database, with multiple > > overlapping objects, is not what we're aiming for. > > > > Personally, I don't see any major problems with SWIP as it is now > > conceptually - it simply needs full automation to allow templates > > to be processed with immediacy. > > > > Comments/flames welcome. > > > > /david > > > > *--------------------------------* > > | Global Crossing IP Engineering | > > | Manager, Global IP Addressing | > > | TEL: (908) 720-6182 | > > | FAX: (703) 464-0802 | > > *--------------------------------* > > From shane at time-travellers.org Thu Feb 1 16:12:41 2001 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 1 Feb 2001 22:12:41 +0100 Subject: The future of SWIP In-Reply-To: ; from ginny@arin.net at 2001-01-31 12:49:55 +0000 References: Message-ID: <20010201221236.A29992@mars.lab.time-travellers.org> On 2001-01-31 12:49:55 +0000, ginny listman wrote: > Does anyone comment on which option you prefer? Not really, but I can tell you how the RIPE database handles this. :) While the RIPE database doesn't really have the same approach to organization information that ARIN's does, there is the possibility for any organization to register information about itself. It is up to other organizations to decide how this is to be used. So, in ARIN's case, ARIN would register information about the ARIN member. If the member allocated space to another organization, it could then register information about that organization itself (this is option #1). However, in the RIPE model, if the ARIN member so desired, it could allow the organization to update the information as it wished (allowing the desirable effects of option #2). If the organization was allocated space from a different ARIN member, then that member could choose to use the information registered by the first ARIN member, or it could register the organization with new information. You can have: 1. ARIN member creates downstream information, ARIN member maintains it 2. ARIN member creates downstream information, downstream maintains it 3. ARIN member creates downstream information, both maintain it You can also have: 1. ARIN member uses existing downstream information, another ARIN member maintains it 2. ARIN member uses existing downstream information, downstream maintains it 3. ARIN member uses existing downstream information, it and another ARIN member maintains it 4. ARIN member uses existing downstream information, it and downstream both maintain it 5. ARIN member uses existing downstream information, all 3 maintain it Further extensions with additional members, additional downstreams, and so on are left as an exercise to the reader. ;) Basically, I think if both option #1 and #2 are potentially useful to some members, allow them both. It will require some work to make the use of mechanisms clear, but it will probably be worth the effort. But then, I'm not a member, so take with the appropriate grain of salt. Shane From woeber at cc.univie.ac.at Fri Feb 2 07:50:29 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 02 Feb 2001 13:50:29 +0100 Subject: user IF question: is there a reverse lookup mechanism? Message-ID: <009F70A7.91754F7E.12@cc.univie.ac.at> [ maybe a bit off-topic ?] With the activities started to move "legacy" (pre-ARIN) internet resource delegations for the non-ARIN region, and with the globally unique handle discussion in mind, I've got a question... In the ancient past a particular person was registered with a NIC handle of RP1126. Those handles have been (still are) accepted in the RIPE-DB). When ARIN moved objects to their own database, quite a while ago, some (all) relevant person objects were copied to the local DB, but obviously the suffix -ARIN was added during that process. So, this very same individual has ended up with another handle: RP1126-ARIN (and probably the old RP1126 somewhere at NSI, too :-) Now, I am wondering, is there any whois-mechanism to find all the objects in the ARIN DB that reference (point to) that handle, i.e. the equivalent to a RIPE-style inverse lookup of "$ whois -r -i zone-c,tech-c,admin-c RP1126[-ARIN]" ? Grateful for any input or help, Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ginny at arin.net Fri Feb 2 10:07:02 2001 From: ginny at arin.net (ginny listman) Date: Fri, 2 Feb 2001 10:07:02 -0500 (EST) Subject: user IF question: is there a reverse lookup mechanism? In-Reply-To: <009F70A7.91754F7E.12@cc.univie.ac.at> Message-ID: Wilfried, Under our current version of whois, we do not have a mechanism to give you all the records associated with a poc handle. However, we do have an internal tool to do this. If you need to know all resources for a specific poc, you can send a request to hostmaster at arin.net. Now having said that, is this something we should consider including after we have converted to a new schema? Ginny Listman Director of Engineering ARIN On Fri, 2 Feb 2001, Wilfried Woeber, UniVie/ACOnet wrote: > [ maybe a bit off-topic ?] > > With the activities started to move "legacy" (pre-ARIN) internet > resource delegations for the non-ARIN region, and with the globally > unique handle discussion in mind, I've got a question... > > In the ancient past a particular person was registered with a NIC handle > of RP1126. Those handles have been (still are) accepted in the RIPE-DB). > > When ARIN moved objects to their own database, quite a while ago, some > (all) relevant person objects were copied to the local DB, but obviously > the suffix -ARIN was added during that process. So, this very same > individual has ended up with another handle: RP1126-ARIN (and probably > the old RP1126 somewhere at NSI, too :-) > > Now, I am wondering, is there any whois-mechanism to find all the > objects in the ARIN DB that reference (point to) that handle, i.e. > the equivalent to a RIPE-style inverse lookup of > "$ whois -r -i zone-c,tech-c,admin-c RP1126[-ARIN]" ? > > Grateful for any input or help, > Wilfried. > _________________________________:_____________________________________ > Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at > UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 > Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 > A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > From woeber at cc.univie.ac.at Fri Feb 2 12:36:13 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 02 Feb 2001 18:36:13 +0100 Subject: user IF question: is there a reverse lookup mechanism? Message-ID: <009F70CF.7BD5B2EE.19@cc.univie.ac.at> Ginny, thanks for the quick reply! >Under our current version of whois, we do not have a mechanism to give you >all the records associated with a poc handle. I see. > However, we do have an >internal tool to do this. If you need to know all resources for a >specific poc, you can send a request to hostmaster at arin.net. OK, I'll use that path for the particular contat - but is this a method which can be used on a more regular basis as well? We have to find some way to support those people who want to identify and compare e.g. address blocks in the ARIN DB and in the RIPE-DB before those blocks get moved to their new home - to prevent poorly maintained stuff to replace more up-to-date records... (for an example pls. see below) >Now having said that, is this something we should consider including after >we have converted to a new schema? Well, we (for the RIPE-DB) take it for granted to have it (as our DB is used as an IP and Routing Registry and was used as a domain repository as well), but it might be less important for the ARIN region. Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ bash$ warin 140.78 EDV-Zentrum (NET-JKU-LAN) Johannes Kepler Universitaet Altenbergerstrasse 69 A-4040 Linz AUSTRIA Netname: JKU-LAN Netblock: 140.78.0.0 - 140.78.255.255 Coordinator: Schmittner, Guenther (GS268-ARIN) K000163 at EDVZ.UNI-LINZ.AC.AT +43-732-2468-671 (FAX) +43-732-2468-688 Domain System inverse mapping provided by: ALIJKU01.EDVZ.UNI-LINZ.AC.AT 140.78.2.62 ALIJKU02.EDVZ.UNI-LINZ.AC.AT 140.78.3.62 Record last updated on 30-Apr-1992. Database last updated on 2-Feb-2001 07:38:34 EDT. bash$ wripe -T inetnum 140.78 % Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 140.78.0.0 - 140.78.255.255 netname: JKU-LAN descr: Johannes Kepler Universitaet Linz descr: Zentraler Informatik Dienst descr: Altenbergerstrasse 69 descr: A-4040 Linz, Austria country: AT admin-c: WM164-RIPE tech-c: GH3003-RIPE rev-srv: alijku01.edvz.uni-linz.ac.at alijku02.edvz.uni-linz.ac.at status: ASSIGNED PI changed: Schmittner at EDVZ.Uni-Linz.AC.AT 19991120 source: RIPE person: Wilfried Maschtera address: Johannes Kepler Universitaet Linz address: Zentraler Informatik Dienst address: Altenbergerstrasse 69 address: A-4040 Linz address: Austria phone: +43 732 2468.8431 fax-no: +43 732 2468.9397 e-mail: Wilfried.Maschtera at zid.uni-linz.ac.at nic-hdl: WM164-RIPE mnt-by: AS1205-MNT changed: Joerg.Lentsch at zid.uni-linz.ac.at 20000706 changed: Joerg.Lentsch at zid.uni-linz.ac.at 20000913 source: RIPE person: Gerald Hanusch address: Johannes Kepler Universitaet Linz address: Zentraler Informatik Dienst address: Altenbergerstrasse 69 address: A-4040 Linz address: Austria phone: +43 732 2468.8554 fax-no: +43 732 2468.9397 e-mail: Gerald.Hanusch at zid.uni-linz.ac.at nic-hdl: GH3003-RIPE mnt-by: AS1205-MNT changed: Joerg.Lentsch at zid.uni-linz.ac.at 20000706 changed: Joerg.Lentsch at zid.uni-linz.ac.at 20000913 source: RIPE ______________________________________________________________________ From cathym at arin.net Tue Feb 20 16:46:46 2001 From: cathym at arin.net (Cathy Murphy) Date: Tue, 20 Feb 2001 16:46:46 -0500 (EST) Subject: Enforcing ISO-3166-1 Message-ID: In order to change from the current batch-process mode, the design of the new ARIN database calls for automatically processing and responding to submitted data such as reassignments. This design also incorporates the ISO 3166 country code standard. This will help the database maintain data integrity. Additionally, it will facilitate the transfer of legacy data and the expansion of additional regional IRs. How would it impact your organization's interaction with ARIN if the the ISO 3166 country standard became required for all country identifications in the submitted data? The database would accept and process only the country in either the two or three character code, or the full name. This change would mean enforcing ISO 3166 by accepting USA, GB or Brazil, but not accepting U.S.A., UK, or Brasil. An alternate proposal suggests that ARIN anticipate common mistakes such as embedded punctuation, misspellings and incorrect codes. -Cathy From jkd at cyberspace.org Wed Feb 21 11:51:17 2001 From: jkd at cyberspace.org (John K. Doyle, Jr.) Date: Wed, 21 Feb 2001 11:51:17 -0500 (EST) Subject: Enforcing ISO-3166-1 In-Reply-To: Message-ID: On Tue, 20 Feb 2001, Cathy Murphy wrote: > This change would mean enforcing ISO 3166 by accepting USA, GB or Brazil, > but not accepting U.S.A., UK, or Brasil. An alternate proposal suggests > that ARIN anticipate common mistakes such as embedded punctuation, > misspellings and incorrect codes. Cathy - enforcing the standard in the database is obviously a good idea. A friendly user interface that corrects for obvious and common errors is an equally good idea. Is there any reason that the two should be mutually exclusive? John From cathym at arin.net Wed Feb 21 12:48:44 2001 From: cathym at arin.net (Cathy Murphy) Date: Wed, 21 Feb 2001 12:48:44 -0500 (EST) Subject: Enforcing ISO-3166-1 In-Reply-To: Message-ID: On Wed, 21 Feb 2001, John K. Doyle, Jr. wrote: > On Tue, 20 Feb 2001, Cathy Murphy wrote: > > > This change would mean enforcing ISO 3166 by accepting USA, GB or Brazil, > > but not accepting U.S.A., UK, or Brasil. An alternate proposal suggests > > that ARIN anticipate common mistakes such as embedded punctuation, > > misspellings and incorrect codes. > > Cathy - enforcing the standard in the database is obviously a good idea. A > friendly user interface that corrects for obvious and common errors is an > equally good idea. Is there any reason that the two should be mutually > exclusive? Not really. The question is not can we, but should we, develop that friendly user interface. What do we consider "obvious and common"? The PRO for doing this are obvious: it simplifies life for those submitting templates. The CON (or PRO for strict enforcement) is that it introduces a certain level of ambiguity. For instance, we might create a user-friendly test (based on past, commonly-made errors) that CHI means Chile (CL,CHL). However, perhaps someone specified CHI intending it to resolve to China (CN,CHN) or Switzerland (CH,CHE). Not likely, but in this hypothetical, we would be the cause of bogus data in whois. So it's a matter of balancing, and we are trying to determine where we should draw the line. Do we anticipate those most common mistakes, knowing that there is the potential for creating bogus data, but understanding that we are making submission easier? Or do we play tough and shift the entire burden to those submitting templates? Cathy From bmjames at swbell.net Wed Feb 21 12:50:35 2001 From: bmjames at swbell.net (Bruce James) Date: Wed, 21 Feb 2001 11:50:35 -0600 Subject: Enforcing ISO-3166-1 References: Message-ID: <002201c09c2e$cb5d6c60$847fd840@a> >>Cathy - enforcing the standard in the database is obviously a good idea. A friendly user interface that corrects for obvious and common errors is an equally good idea. Is there any reason that the two should be mutually exclusive?<< I agree. Do it...... /Bruce James bmjames at swbell.net ----- Original Message ----- From: "John K. Doyle, Jr." To: "Cathy Murphy" Cc: Sent: Wednesday, February 21, 2001 10:51 AM Subject: Re: Enforcing ISO-3166-1 On Tue, 20 Feb 2001, Cathy Murphy wrote: > This change would mean enforcing ISO 3166 by accepting USA, GB or Brazil, > but not accepting U.S.A., UK, or Brasil. An alternate proposal suggests > that ARIN anticipate common mistakes such as embedded punctuation, > misspellings and incorrect codes. Cathy - enforcing the standard in the database is obviously a good idea. A friendly user interface that corrects for obvious and common errors is an equally good idea. Is there any reason that the two should be mutually exclusive? John --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/2001 From shane at time-travellers.org Wed Feb 21 13:18:42 2001 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 21 Feb 2001 19:18:42 +0100 Subject: Enforcing ISO-3166-1 In-Reply-To: ; from cathym@arin.net at 2001-02-21 12:48:44 +0000 References: Message-ID: <20010221191841.A7838@mars.lab.time-travellers.org> On 2001-02-21 12:48:44 +0000, Cathy Murphy wrote: > > So it's a matter of balancing, and we are trying to determine where we > should draw the line. Do we anticipate those most common mistakes, > knowing that there is the potential for creating bogus data, but > understanding that we are making submission easier? Or do we play > tough and shift the entire burden to those submitting templates? Well, perhaps you could post a sample list here, and we can see if the entries are indeed obvious to the readers. From my experiences with this topic, I feel that you can safely "auto-correct" most of the problems with almost no mismatches. The examples you gave of Brasil and UK, for instance, are extremely common. Things like Britian are also fairly common - not much ambiguity there, just wrongness. ;) Other cases that call for more tact should probably just be omitted. While I'd give good odds that an entry for Korea probably means "South Korea", you can't know for sure. One thing I do think is that any correction that occurs should be made clear to the user: Shane Kerr, We have updated your contact information. Because you refused to follow the directions we provide here: http://www.arin.net/some-directions.html We corrected the address you submitted. Country code: Netherlands Became: Country code: NL If this is incorrect, please submit the correct data in the correct format. Love, ARIN The usual legal disclaimers would of course have to be attached. The real answer to this is of course a web (or other GUI) interface, so the user can pick from a list. ;) Shane From ginny at arin.net Wed Feb 21 14:22:13 2001 From: ginny at arin.net (ginny listman) Date: Wed, 21 Feb 2001 14:22:13 -0500 (EST) Subject: Enforcing ISO-3166-1 In-Reply-To: <20010221191841.A7838@mars.lab.time-travellers.org> Message-ID: On Wed, 21 Feb 2001, Shane Kerr wrote: > On 2001-02-21 12:48:44 +0000, Cathy Murphy wrote: > > > > So it's a matter of balancing, and we are trying to determine where we > > should draw the line. Do we anticipate those most common mistakes, > > knowing that there is the potential for creating bogus data, but > > understanding that we are making submission easier? Or do we play > > tough and shift the entire burden to those submitting templates? > > Well, perhaps you could post a sample list here, and we can see if the > entries are indeed obvious to the readers. From my experiences with > this topic, I feel that you can safely "auto-correct" most of the > problems with almost no mismatches. The examples you gave of Brasil and > UK, for instance, are extremely common. Things like Britian are also > fairly common - not much ambiguity there, just wrongness. ;) My concern is not of ambiguity, rather a data management nightmare. For example, we have UK, Great Britain, England, etc. None of which are listed in ISO 3166. What is there is United Kingdom, GB and GBR. I can think of at least 5 ways of expressing US, that are not "standard". Are we suppose to list to dbwg (or some other list) to make sure we've capture all the common names? Or just see what common errors we accumulate? Why can't we just educate the members and inform them about ISO 3166? If we accept a template with U.S.A., are we promoting the ignorance of an ISO standard? > We corrected the address you submitted. > > Country code: Netherlands > FYI, Netherlands is in ISO 3166 as the full name. Therefore this would be accepted. However, if you had entered Nederlands, that's where there could be a problem. > > The real answer to this is of course a web (or other GUI) interface, so > the user can pick from a list. ;) Agreed. Or intention is to have a web based template. However, not every member would be willing to submit via the web. Therefore, we will need to address text-based templates. > > Shane > Ginny Listman Director of Engineering ARIN From shane at time-travellers.org Wed Feb 21 15:17:46 2001 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 21 Feb 2001 21:17:46 +0100 Subject: Enforcing ISO-3166-1 In-Reply-To: ; from ginny@arin.net at 2001-02-21 14:22:13 +0000 References: <20010221191841.A7838@mars.lab.time-travellers.org> Message-ID: <20010221211745.B8592@mars.lab.time-travellers.org> On 2001-02-21 14:22:13 +0000, ginny listman wrote: > > > Well, perhaps you could post a sample list here, and we can see if > > the entries are indeed obvious to the readers. From my experiences > > with this topic, I feel that you can safely "auto-correct" most of > > the problems with almost no mismatches. The examples you gave of > > Brasil and UK, for instance, are extremely common. Things like > > Britian are also fairly common - not much ambiguity there, just > > wrongness. ;) > > My concern is not of ambiguity, rather a data management nightmare. > For example, we have UK, Great Britain, England, etc. None of which > are listed in ISO 3166. What is there is United Kingdom, GB and GBR. > I can think of at least 5 ways of expressing US, that are not > "standard". Are we suppose to list to dbwg (or some other list) to > make sure we've capture all the common names? Or just see what common > errors we accumulate? Why can't we just educate the members and > inform them about ISO 3166? If we accept a template with U.S.A., are > we promoting the ignorance of an ISO standard? Given a choice between smarter, but imperfect, software and the impossible and unending task of attempting to educate the world why not choose making life easier on users and yourself? This particular problem has the wonderful property of dealing with largely static data (country codes), plus having having a wonderful source of sample errors easily avaible (the existing ARIN database). Most of the work only has to be done once (and in fact I did this very thing once before), requiring only minor (if any) subsequent modifications. It's the job of the developer to attempt to anticipate common errors and correct them in an intuitive way. Programs should be made to work for people, not people for their software. > > The real answer to this is of course a web (or other GUI) interface, > > so the user can pick from a list. ;) > > Agreed. Or intention is to have a web based template. However, not > every member would be willing to submit via the web. Therefore, we > will need to address text-based templates. In a world with both a web interface and an e-mail interface, then I am totally in favor of strict rules. The target audience for such an interface is expert users and automated tools, both of which would probably prefer the parser to do what you tell it to, not what it thinks you mean for it to do. My 0.022 Euros... Shane From chairman at mii.or.id Wed Feb 21 17:01:18 2001 From: chairman at mii.or.id (PURWADI, Teddy A) Date: Thu, 22 Feb 2001 05:01:18 +0700 Subject: Enforcing ISO-3166-1 In-Reply-To: <20010221191841.A7838@mars.lab.time-travellers.org> References: Message-ID: <3.0.6.32.20010222050118.04698610@pop3.access.net.id> At 07:18 PM 2/21/01 +0100, Shane Kerr wrote: >On 2001-02-21 12:48:44 +0000, Cathy Murphy wrote: > http://www.arin.net/some-directions.html link is error. Thanks. Brgs, -Teddy [ISOC-ID] "INFORMATION-INTERNET SOCIETY" From huberman at gblx.net Wed Feb 21 18:13:45 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 21 Feb 2001 16:13:45 -0700 (MST) Subject: Enforcing ISO-3166-1 In-Reply-To: Message-ID: (Apologies, I haven't seen the rest of my inbox yet) > The database would accept and process only the country in either the > two or three character code, or the full name. This change would mean > enforcing ISO 3166 by accepting USA, GB or Brazil, but not accepting > U.S.A., UK, or Brasil. An alternate proposal suggests that ARIN > anticipate common mistakes such as embedded punctuation, misspellings > and incorrect codes. The alternate proposal is, of course, the way to go about it in my opinion. Country codes should be mandatory in the ARIN WHOIS database. ISO-3166 compliancy, while nice, is only practical for newcomers to ARIN if there is at least 'basic' flexibility. Go for it /david *--------------------------------* | Global Crossing IP Engineering | | Manager, Global IP Addressing | | TEL: (908) 720-6182 | | FAX: (703) 464-0802 | *--------------------------------* From woeber at cc.univie.ac.at Thu Feb 22 07:21:24 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 22 Feb 2001 13:21:24 +0100 Subject: Enforcing ISO-3166-1 Message-ID: <009F805A.D1716D8E.4@cc.univie.ac.at> = =It's the job of the developer to attempt to anticipate common errors and =correct them in an intuitive way. Programs should be made to work for =people, not people for their software. = In this particular context, I agree, but with the footnote that the complete list of "alternate" input (and it's mapping to the "correct" entry) has to be documented, and, the program should provide feedback to the user about it's clever action and, probably, ask for confirmation. Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~