Rajat | 19 Aug 12:59 2004
Picon

Regarding whois query in xml format


Hello all,
I am in process of finding the location of a given IP
address. So I made some queries to the whois
servers(using TCP <at> 43), but whatever response I got is
in human readable text formate. More over the response
format of each server is of different form. I compiled
following servers,

whois.arin.net
whois.apnic.net
whois.ripe.net
whois.lacnic.net

I am not able to parse the response and get the
relevent information.

Is there any way to get the response in proper xml
format. So that I can easily parse it. I got one mail
in a message archive, in that it was stated that if we
sand whois query in XML format then will get the
response in XML format only. Other wise simple text
response will be returned.

Does any body know that how we can query the whois
srevr in xml format? And is it depends on servers xml
compatibility??

Thanks in advance.

(Continue reading)

Bill Weinman | 18 May 18:37 2003

Re: How do I identify if a particular registrar complies with the 'wh ois export and exchange format'?


The next version of my BW Whois (version 4.0) will parse data from the 
different registrars and deliver XML. (In the process I am working with 
Rich Wesson to update the expired whois-export draft -- it will likely change.)

I'm currently scheduled to have a beta version ready by the end of June. (I 
have a proof of concept working already.)

--Bill

At 09:04 AM 5/2/2003, Chhabria, Kavita - Apogent wrote:
>Hello all:   I came across this internet draft just yesterday and would 
>certainly like to have some more information on it.   Also, I am faced 
>with a requirement in a program to be able to use the whois protocol and 
>extract data out of the output from different registrars by parsing them. 
>However, since the output varies from registrar to registrar, I decided to 
>search for ways to overcome this problem and that is when I came across 
>this 'whois export and exchange format'.  The question that I now have is 
>that how do I identify if a registrar is capable of sending me the output 
>of the whois query as an xml document as outlined in this draft?  Pls pls 
>explain me that.   I have been trying to solve this problem for a long 
>time now and any help in this regard would be greatly 
>appreciated.   Thanks   Kavita Chhabria Systems Developer Apogent 
>Technologies (616) 544-7515 
><mailto:kchhabria <at> apogent.com>kchhabria <at> apogent.com

->--
   Bill Weinman   <http://bw.org/>
   Music Database <http://www.webmusicdb.com/>
   Music          <http://music.bw.org/>
(Continue reading)

Chhabria, Kavita - Apogent | 2 May 16:04 2003

How do I identify if a particular registrar complies with the 'wh ois export and exchange format'?

Hello all:
 
I came across this internet draft just yesterday and would certainly like to have some more information on it.
 
Also, I am faced with a requirement in a program to be able to use the whois protocol and extract data out of the output from different registrars by parsing them. However, since the output varies from registrar to registrar, I decided to search for ways to overcome this problem and that is when I came across this 'whois export and exchange format'.  The question that I now have is that how do I identify if a registrar is capable of sending me the output of the whois query as an xml document as outlined in this draft?  Pls pls explain me that.
 
I have been trying to solve this problem for a long time now and any help in this regard would be greatly appreciated.
 
Thanks
 
Kavita Chhabria
Systems Developer
Apogent Technologies
(616) 544-7515
 
Hugo Salgado Hernández | 25 Apr 05:44 2003
Picon

Re: Request to Move RFC 954 to Historic Status


The point of contact exists in the web page of the .cl cctld, where
anyone can ask for the name, emails and phone numbers of
the technical contacts of any domain. In this way, we can
keep track of  posibly misuse of this data.

Hugo

> The fact that spammers and others misuse data still leaves us
> with the original purpose of network operations issues.
> If someone in your ccTLD is hacking or spamming or has been infected by
> CodeRed, it is neccessary to have a publicly available point of contact
> so that the issue can be resolved. Indeed, if we are trying to reach
> some place and things are broken we need a (possibly different) contact.
> If you feel your privacy concerns are more important,  please
> don't connect to the rest of the Internet so we don't need to contact
> you when something goes wrong.
>
> Conform to the RFC. That does not mean you cannot come up with a service
> to relay mail that screens for spam and other misuse and list those
> mailboxes. In addition you could come up with a call centre which relays
> calls on behalf of registrants so that if we need to reach someone voice
> (perhaps because their network is unreachable or mail bounces), we can
> do so.
>
> Quality of data in WHOIS records is not uniform, many dolts here in the
> US register absolute garbage in the contact fields and registrant name
> and some registrars allow it.
>
>
>
>
>
>
>
>
>
>
> On Wed, 23 Apr 2003, Hugo Salgado H. wrote:
>
>>
>> Hi.
>> This is my first mail to this list. My name is Hugo Salgado,
>> and i work on NIC Chile, the .CL cctld administrator.
>> Since few weeks ago we've been receiving complaints for the
>> mail-blocking list that www.rfc-ignorant.com mantains.
>> That list is blocking entire ccTLDs that are not respecting
>> the RFC 954 on their whois service.
>> As you were discussing before, that RFC lacks of things like
>> privacy policies, anti-data-mining for spammers, etc.
>> In .CL we don't publish the email addresses for our registrants, and
>> that is the cause that rfc-ignorant is blocking the entire
>> .cl email addresses.
>>
>> Is there an RFC that overrides the very old 954 ?? i know that
>> .PL is listed in the blocked countries, for the same privacy
>> policies in whois.dns.pl, but that was dicussed before in this
>> list ??
>>
>> Thanks, and sorry for my spanglish ;)

--
Hugo Salgado H. <hsalgado <at> nic.cl>
Agustinas 1357, 4º piso - Santiago Chile
Phone: (562) 940 7700 Fax: (562) 940 7701

Hugo Salgado H. | 23 Apr 17:00 2003
Picon

Re: Request to Move RFC 954 to Historic Status


Hi.
This is my first mail to this list. My name is Hugo Salgado,
and i work on NIC Chile, the .CL cctld administrator.
Since few weeks ago we've been receiving complaints for the
mail-blocking list that www.rfc-ignorant.com mantains.
That list is blocking entire ccTLDs that are not respecting
the RFC 954 on their whois service.
As you were discussing before, that RFC lacks of things like
privacy policies, anti-data-mining for spammers, etc.
In .CL we don't publish the email addresses for our registrants,
and that is the cause that rfc-ignorant is blocking the entire
.cl email addresses.

Is there an RFC that overrides the very old 954 ?? i know that
.PL is listed in the blocked countries, for the same privacy
policies in whois.dns.pl, but that was dicussed before in this
list ??

Thanks, and sorry for my spanglish ;)

--

-- 
Hugo Salgado H. <hsalgado <at> nic.cl>
R&D NIC Chile - http://www.nic.cl
Agustinas 1357, piso 4, Cod. Postal 6500587  Santiago Chile
Phone: (562) 940 7700   Fax: (562) 940 7701

Picon

Re: Request to Move RFC 954 to Historic Status


[ietf-whois and related lists]

I sat down with the European Commission's Call for Expressions of Interest
for the Selection of the .eu TLD Registry this week, and was pleased that
Directive 95/46/EC is the controlling framework for that registry's core
policy requirements (B.3, 1(b), Technical Annex, page 2). Here is the URL
to the EC's DP home: 

	http://europa.eu.int/comm/internal_market/en/dataprot/

That was my first imputus to finally submit an individual contribution to
move 954 from "DRAFT STANDARD" to "HISTORIC".

Now prior to Yokahama I asked around if anyone knew why and how (process)
954 had been moved from "UNKNOWN" (like 742 and 812) to "DRAFT STANDARD".
No one I asked knew, but I didn't bother to formally ask the IESG and/or
the RFC Editor. That change of status for 954 appears to have occured in
the past two years. Perhaps someone on the IESG can enlighten me.

Then there is the current ICANN announcement of some policy w.r.t. its
Registrar Accreditation Agreement (RAA). The RAA contains language which
appears closer to the language in 954 concerning MILNET TAC users than to
the language in 954 concerning individual with a directory on an ARPANET or
MILNET host. Both are in conflict with 95/46/EC, and the OEDC Guidelines
(the oecd.org link is broken, so here is Roger Clarke's restatement, itself
a useful read)

	http://www.anu.edu.au/people/Roger.Clarke/DV/PaperOECD.html

I can't speculate on the actual status of :43 deployments by ccTLD operators
located outside of North America.

I decided not to include a mapping from the DCA language to a P3P schema,
as for many, the policy scope question (controlling jurisdiction and legal
theory, e.g., "fair trade" (US) vs "human rights" (EU)), not the mechanism
for description and policy-scoped access, is more interesting, and both XML
and schemas and/or DTDs are a distraction. I'll add it to -01.

Your comments are welcome.

I've cc'd the Provreg WG list due to the overlap of interest (many are also
registrars and/or registry operators), and the W3C's P3P Spec WG list, also
due to the overlap of interest.

If anyone can provide feedback from RIPE-43 and or CENTR (Jaap?), or ICDPPC-24
(Rigo?) this month, and ARIN-X (Ed?) next month, that would be a good thing.

Please be sure to cc me if replying.

I started writing this before a comment got to me. The comment was:

> I strongly disagree with the suggestion posed by this Draft.  Whois is
> a protocol in the public domain, and people can and do still use it.
> The fact that SRI no longer supports it under DCA funding is an absurd
> argument; it is just as irrelevant as the fact that ISI no longer
> supports the DNS under DARPA funding, as it once did; should we make
> the DNS protocol Historic?
> 
> There is no protocol document obsoleting Whois, and I am not aware of
> any terrible network consequence of its operation.   People with
> security issues on their databases do not have to participate.  If
> there are technical security problems with the protocol, the IESG
> should move to develop a protocol to obsolete Whois.  In the absence of
> such a replacement, and in the absence of any demonstrable harm to the
> Internet from keeping it as a Draft Standard, moving it to Historic
> would be unnecessary and (I believe) a violatiokn of common sense
> and proper standards setting.

954 specifies not only a protocol:

	C: [::printable::]\r\n
	S: .*\r\n <socket close>

It also specifies a data colleciton practice, the DCA's for MILNET TAC users,
and for individual (users) with a directory on an ARPANET or MILNET host. The
data collection practice itself is historic. The PROPOSED STANDARD status of
a national military data collection practice is historic as well. If the IETF
has any role in non-military public registry data collection practices, by
RIRs, domain registry operators, or others choosing to use the above protocol
on port 43, 954 is historic.

Strong disagreement noted.

Eric

------- Forwarded Message

To: IETF-Announce: ;
From: Internet-Drafts <at> ietf.org
Reply-to: Internet-Drafts <at> ietf.org
Subject: I-D ACTION:draft-brunner-rfc954-historic-00.txt
Date: Thu, 05 Sep 2002 07:18:36 -0400
Sender: nsyracus <at> cnri.reston.va.us

- --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Request to Move RFC 954 to Historic Status
	Author(s)	: E. Brunner-Williams
	Filename	: draft-brunner-rfc954-historic-00.txt
	Pages		: 3
	Date		: 2002-9-4
	
This memo requests a change of the status of RFC 954,

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brunner-rfc954-historic-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-brunner-rfc954-historic-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-brunner-rfc954-historic-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv <at> ietf.org"

Content-Type: text/plain
Content-ID:	<2002-9-4143115.I-D <at> ietf.org>

ENCODING mime
FILE /internet-drafts/draft-brunner-rfc954-historic-00.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-brunner-rfc954-historic-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-9-4143115.I-D <at> ietf.org>

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

Picon

FYI: [ARIN] New Whois Display Format


Oki all,

Ginny Listman sent this to the dbwg list at ARIN. It is self-explanitory.

Eric

------- Forwarded Message

Date: Tue, 12 Mar 2002 11:00:20 -0500 (EST)
From: ginny listman <ginny <at> arin.net>
To: dbwg <at> arin.net
Subject: New Whois Display Format
Message-ID: <Pine.GSO.3.96.1020312105837.12375A-200000 <at> ops.arin.net>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1015948820=:12375"
Sender: dbwg-request <at> arin.net
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime <at> docserver.cac.washington.edu for more info.

- ---559023410-851401618-1015948820=:12375
Content-Type: TEXT/PLAIN; charset=US-ASCII

To coincide with the release of the new database and templates, ARIN has
begun development of a new Whois, in a modular format. The Output Module
will define the Whois display. It is our objective to keep the Whois
display in a easily readable format, while accomodating machine queries
by providing labels.

The requirements outlined in this document are based on feedback from the
community. To provide a usable tool, we are requesting additional comments 
at this time.  Additionally, this format will be discussed at the Member
Meeting taking place April 7-10 in Las Vegas.

Ginny Listman
Director of Engineering
ARIN

*****

           WHOIS REQUIREMENTS

I. Uses of Whois
   a. As a troubleshooting aid
   b. For Applications that use resource assignment information
   c. To show address space utilization
   d. In the future, to display routing objects

II. Privacy
   a. The Whois database is a public resource.

III. Formats
   a. The "default" format is returned when querying Whois without any flags, 
      and there is a single record returned. For ease of use all items will
      include labels. If a field does not exist, for example if a POC is 
      missing a email address, a label will not be displayed. Refer to the 
      attached "Whois Examples" for samples. The four object will be displayed 
      as follows:

      i. Point Of Contact - display all attributes of the POC

         Name: <last name, first name, middle name> or <role account>
         Handle: <point of contact handle>
         Address: <organization name, street address, city, state, zip, 
                   country code>
         Phone: <phone number, phone extension, phone type>
         Phone: <phone number, phone extension, phone type>
         Email: <email address>
         Email: <email address>

     ii. Organization - list the organization and all associated POCs

         Org Name: <organization name>
         Org ID: <organization ID, formerly maintainer ID>
         Org Address: <street address, city, state, zip, country code>

         Org <POC function> Handle: <POC handle>
         Org <POC function> Name: <POC name>
         Org <POC function> Phone: <POC office phone number><*>
         Org <POC function> Email: <POC email address><*>

         Org <POC function> Handle: <POC handle>
         Org <POC function> Name: <POC name>
         Org <POC function> Phone: <POC office phone number><*>
         Org <POC function> Email: <POC email address><*>

         Note: Organization POC functions include Admin, Tech, Abuse and NOC.

    iii. Autonomous System - list the organization, the autonomous system,
         POCs for the autonomous system, and POCs for the organization

         Org Name: <organization name>
         Org ID: <organization ID, formerly maintainer ID>
         Org Address: <street address, city, state, zip, country code>

         AS Number: <autonomous system number>
         AS Handle: <autonomous system handle>
         AS Name: <autonomous system name>

         AS <POC function> Handle: <POC handle>
         AS <POC function> Name: <POC name>
         AS <POC function> Phone: <POC office phone number><*>
         AS <POC function> Email: <POC email address><*>

         Org <POC function> Handle: <POC handle>
         Org <POC function> Name: <POC name>
         Org <POC function> Phone: <POC office phone number><*>
         Org <POC function> Email: <POC email address><*>

         Note: All POCs for the AS will be displayed. Only the organization's
         Tech, Abuse and NOC POCs will be displayed.

     iv. IPv4 Network - list the organization, the network, POCs for the
         network, POCs for the organization

         Org Name: <organization name>
         Org ID: <organization ID, formerly maintainer ID>
         Org Address: <street address, city, state, zip, country code>

         CIDR Net Address: <network address in CIDR format>
         Network Range: <network address range>
         Network Handle: <network handle>
         Network Name: <network name>
         Can Sub-Delegate: <Y/N>
         IN-ADDR: <in-addr server name>
         IN-ADDR: <in-addr server name>

         Net <POC function> Handle: <POC handle>
         Net <POC function> Name: <POC name>
         Net <POC function> Phone: <POC office phone number><*>
         Net <POC function> Email: <POC email address><*>

         Net <POC function> Handle: <POC handle>
         Net <POC function> Name: <POC name>
         Net <POC function> Phone: <POC office phone number><*>
         Net <POC function> Email: <POC email address><*>

         Note: All POCs for the network will be displayed. Only the 
         organization's Tech, Abuse and NOC POCs will be displayed.

         * Indicates that multiple phone numbers or email addresses exist,
           of which only the first is displayed.

   b. The "list" format is returned when querying Whois without specifying any 
      flags, and there are multiple records returned. Labels are not included.
      The fields that are displayed are outlined below.
      i. Point Of Contact - last name, first name, middle name, handle, one 
         email address, one office phone number
     ii. Organization - Organization name, Organization ID
    iii. Autonomous System - AS name, handle, AS number
   iiii. Network - network name, handle, either a single CIDR block or network
         range.

   c. In the future, we may provide the output in RPSL-like format.

IV. Query by type. To narrow a search, a query can include a flag indicating
    the object type as follows:
   a. n <query string> will return only networks
   b. a <query string> will return only autonomous systems
   c. p <query string> will return only point-of-contacts
   d. o <query string> will return only organizations

V. Query by attribute. To narrow a search, a query can also include a flag
   as follows:
   a. ! <handle> will return the single match of the specified handle
   b.  <at>  <DNS name> will return the list of POCs with the specified domain name
      in the email address
   c. . <name> will return a list of POCs, organizations, autonomous systems,
      and/or networks that start with the specified name

VI. Additional features
   a. Sub-queries can be displayed using the % flag.  The queried string
      must return a single record to provide sub-query information.  The
      following objects have sub-query information:
      i. Networks - display the reassignment/reallocation information in
         list format, if data exists.
     ii. Organizations - display the organization's resources information
         in list format, if data exists.
   b. Parentage can be displayed using the * flag.  The queried string
      must return a single record to provide parentage information.  The
      following objects have parentage information:
      i. Networks - display the parentage in default format, if data exists.
     ii. Organizations - will be implemented in future releases.
   c. Other keywords
      i. = <query string> will show default displays for all matches, 
         regardless of the number returned
     ii. HELP will display the help screen
    iii. <query string>. will show a list of all matches starting with the
         given string.
     iv. SUM <query string> will show list displays, even if there is only
         one match.
   d. The maximum number of records output is limited to 256.  This may be
      revised in future versions.
   e. A future enhancement will include an relational lookup.  For example, if
      a POC is queried, the resouces associated with the POC would be 
      displayed.

- ---559023410-851401618-1015948820=:12375
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=whois-ex
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.3.96.1020312110020.12375B <at> ops.arin.net>
Content-Description: Whois Examples

ICAgICAgICAgICAgICAgIFdIT0lTIEVYQU1QTEVTDQoNClRoZSBmb2xsb3dp
bmcgaW5mb3JtYXRpb24gaXMgdXNlZCBhcyBzYW1wbGUgZGF0YS4NCg0KMS4g
T3JnYW5pemF0aW9uIEFCQyBJU1AgaXMgcmVnaXN0ZXJlZCB3aXRoIDUgUE9D
cyAtIERFRi1BUklOIGFzIHRoZSANCmFkbWluaXN0cmF0aXZlIGNvbnRhY3Qs
IEFCQy1URUNILUFSSU4gYW5kICBBQkMtVEVDSDItQVJJTiBhcyB0ZWNobmlj
YWwgDQpjb250YWN0cywgQUJDLU5PQy1BUklOIGFzIGEgTk9DIGNvbnRhY3Qg
YW5kIEFCQy1BQlUtQVJJTiBhcyBhbiBhYnVzZSBjb250YWN0Lg0KMi4gQUJD
IElTUCBoYXMgYmVlbiBhc3NpZ25lZCBhdXRvbm9tb3VzIHN5c3RlbSA2NTAw
MCwgYW5kIGhhcyBBQlVTRS1BUklOIGFzIA0KYW4gYWJ1c2UgY29udGFjdC4N
CjMuIEFCQyBJU1AgaGFzIGJlZW4gYWxsb2NhdGVkIHR3byBuZXR3b3JrIGJs
b2Nrcy4gIFRoZSBmaXJzdCAxMC4wLjAuMC8xNQ0KZG9lcyBub3QgaGF2ZSBh
bnkgcmVzb3VyY2UgUE9DcyBhc3NvY2lhdGVkIHdpdGggaXQuICBJdCBoYXMg
dHdvIElOLUFERFIgc2VydmVycy4NCjQuIFRoZSBzZWNvbmQgYWxsb2NhdGlv
biAxMC4zMi4wLjAvMTYgaGFzIFNVUC1BUklOIGFzIGEgdGVjaG5pY2FsIGNv
bnRhY3QgYW5kDQpOT0MyLUFSSU4gYXMgYSBOT0MgY29udGFjdC4gIEl0IGhh
cyA0IElOLUFERFIgc2VydmVycy4NCjUuIEFCQyBoYXMgcmVhc3NpZ25lZCAx
MC4zMi4wLjAtMTAuMzIuMC4xOSB0byBYWVogSVNQLiBYWVogaGFzIHRoZSBt
aW5pbWFsDQphbW91bnQgb2YgUE9DcyAtIFhZWi1URUNILUFSSU4gYXMgdGhl
IG9yZ2FuaXphdGlvbmFsIHRlY2huaWNhbCBhbmQgWFlaLUFETUktQVJJTg0K
YXMgdGhlIGFkbWluaXN0cmF0aXZlLiBUaGVyZSBhcmUgbm8gUE9DcyBvciBJ
Ti1BRERSIHNlcnZlcnMgb24gdGhlIHJlYWxsb2NhdGlvbi4NCg0KQmFzZWQg
b24gdGhpcyBpbmZvcm1hdGlvbiwgdGhlIHdob2lzIGRpc3BsYXkgd291bGQg
YmUgYXMgZm9sbG93czoNCg0KMS4gd2hvaXMgYWJjDQogICAgT3JnIE5hbWU6
IEFCQyBJU1ANCiAgICBPcmcgSUQ6IEFCQw0KICAgIE9yZyBBZGRyZXNzOiAx
MzIgTWFpbiBTdHJlZXQNCiAgICAgICAgICAgICAgICAgQW55dG93biwgVkEg
MjIyMjINCiAgICAgICAgICAgICAgICAgVVMNCg0KICAgIE9yZyBBZG1pbiBI
YW5kbGU6IERFRi1BUklODQogICAgT3JnIEFkbWluIE5hbWU6IEZvb2Jhciwg
RHdpZ2h0IEUuDQogICAgT3JnIEFkbWluIFBob25lOiArMS05OTktOTk5LTc3
NzcgKE9mZmljZSkgKg0KICAgIE9yZyBBZG1pbiBFbWFpbDogZm9vYmFyQGV4
YW1wbGUubmV0DQoNCiAgICBPcmcgVGVjaCBIYW5kbGU6IEFCQy1URUNILUFS
SU4NCiAgICBPcmcgVGVjaCBOYW1lOiBUZWNobmljYWwgU3VwcG9ydA0KICAg
IE9yZyBUZWNoIFBob25lOiArMS05OTktOTk5LTk5OTkgKE9mZmljZSkgKg0K
ICAgIE9yZyBUZWNoIEVtYWlsOiB0ZWNoQGV4YW1wbGUubmV0DQoNCiAgICBP
cmcgVGVjaCBIYW5kbGU6IEFCQy1URUNIMi1BUklODQogICAgT3JnIFRlY2gg
TmFtZTogVGVjaG5pY2FsIFN1cHBvcnQgTWFuYWdlcg0KICAgIE9yZyBUZWNo
IFBob25lOiArMS05OTktOTk5LTg4ODggKE9mZmljZSkNCiAgICBPcmcgVGVj
aCBFbWFpbDogdGVjaC1tZ3JAZXhhbXBsZS5uZXQNCg0KICAgIE9yZyBOT0Mg
SGFuZGxlOiBBQkMtTk9DLUFSSU4NCiAgICBPcmcgTk9DIE5hbWU6IE5ldHdv
cmsgT3BlcmF0aW9ucyBDZW50ZXINCiAgICBPcmcgTk9DIFBob25lOiArMS05
OTktOTk5LTY2NjYgKE9mZmljZSkgKg0KICAgIE9yZyBOT0MgRW1haWw6IG5v
Y0BleGFtcGxlLm5ldA0KDQogICAgT3JnIEFidXNlIEhhbmRsZTogQUJDLUFC
VS1BUklODQogICAgT3JnIEFidXNlIE5hbWU6IE5ldHdvcmsgQWJ1c2UgU3Vw
cG9ydA0KICAgIE9yZyBBYnVzZSBQaG9uZTogKzEtOTk5LTk5OS01NTU1IChP
ZmZpY2UpICoNCiAgICBPcmcgQWJ1c2UgRW1haWw6IGFidXNlQGV4YW1wbGUu
bmV0DQoNCjIuIHdob2lzIDY1MDAwDQogICAgT3JnIE5hbWU6IEFCQyBJU1AN
CiAgICBPcmcgSUQ6IEFCQw0KDQogICAgQVMgTnVtYmVyOiA2NTAwMA0KICAg
IEFTIEhhbmRsZTogQVM2NTAwMA0KICAgIEFTIE5hbWU6IEFCQy1BU042NTAw
MA0KDQogICAgQVMgQWJ1c2UgSGFuZGxlOiBBQlVTRS1BUklODQogICAgQVMg
QWJ1c2UgTmFtZTogQVMgNjUwMDAgQWJ1c2UgU3VwcG9ydA0KICAgIEFTIEFi
dXNlIFBob25lOiArMS03MDMtMDAwLTAwMDAgKE9mZmljZSkgKg0KICAgIEFT
IEFidXNlIEVtYWlsOiBhYnVzZS02NTAwMEBleGFtcGxlLm5ldA0KDQogICAg
T3JnIFRlY2ggSGFuZGxlOiBBQkMtVEVDSC1BUklODQogICAgT3JnIFRlY2gg
TmFtZTogVGVjaG5pY2FsIFN1cHBvcnQNCiAgICBPcmcgVGVjaCBQaG9uZTog
KzEtOTk5LTk5OS05OTk5IChPZmZpY2UpICoNCiAgICBPcmcgVGVjaCBFbWFp
bDogdGVjaEBleGFtcGxlLm5ldA0KDQogICAgT3JnIFRlY2ggSGFuZGxlOiBB
QkMtVEVDSDItQVJJTg0KICAgIE9yZyBUZWNoIE5hbWU6IFRlY2huaWNhbCBT
dXBwb3J0IE1hbmFnZXINCiAgICBPcmcgVGVjaCBQaG9uZTogKzEtOTk5LTk5
OS04ODg4IChPZmZpY2UpDQogICAgT3JnIFRlY2ggRW1haWw6IHRlY2gtbWdy
QGV4YW1wbGUubmV0DQoNCiAgICBPcmcgTk9DIEhhbmRsZTogQUJDLU5PQy1B
UklODQogICAgT3JnIE5PQyBOYW1lOiBOZXR3b3JrIE9wZXJhdGlvbnMgQ2Vu
dGVyDQogICAgT3JnIE5PQyBQaG9uZTogKzEtOTk5LTk5OS02NjY2IChPZmZp
Y2UpICoNCiAgICBPcmcgTk9DIEVtYWlsOiBub2NAZXhhbXBsZS5uZXQNCg0K
ICAgIE9yZyBBYnVzZSBIYW5kbGU6IEFCQy1BQlUtQVJJTg0KICAgIE9yZyBB
YnVzZSBOYW1lOiBOZXR3b3JrIEFidXNlIFN1cHBvcnQNCiAgICBPcmcgQWJ1
c2UgUGhvbmU6ICsxLTk5OS05OTktNTU1NSAoT2ZmaWNlKSAqDQogICAgT3Jn
IEFidXNlIEVtYWlsOiBhYnVzZUBleGFtcGxlLm5ldA0KDQozLiB3aG9pcyAx
MC4wLjAuMA0KICAgIE9yZyBOYW1lOiBBQkMgSVNQDQogICAgT3JnIElEOiBB
QkMNCg0KICAgIENJRFIgTmV0IEFkZHJlc3M6IDEwLjAuMC4wLzE1DQogICAg
TmV0d29yayBSYW5nZTogMTAuMC4wLjAtMTAuMS4yNTUuMjU1DQogICAgTmV0
d29yayBIYW5kbGU6IE5FVC0xMC0wLTAtMA0KICAgIE5ldHdvcmsgTmFtZTog
TkVUV09SSy0xMA0KICAgIENhbiBTdWItRGVsZWdhdGU6IFkNCiAgICBJTi1B
RERSOiBucy5leGFtcGxlLm5ldA0KICAgIElOLUFERFI6IG5zMi5leGFtcGxl
Lm5ldA0KDQogICAgT3JnIFRlY2ggSGFuZGxlOiBBQkMtVEVDSC1BUklODQog
ICAgT3JnIFRlY2ggTmFtZTogVGVjaG5pY2FsIFN1cHBvcnQNCiAgICBPcmcg
VGVjaCBQaG9uZTogKzEtOTk5LTk5OS05OTk5IChPZmZpY2UpICoNCiAgICBP
cmcgVGVjaCBFbWFpbDogdGVjaEBleGFtcGxlLm5ldA0KDQogICAgT3JnIFRl
Y2ggSGFuZGxlOiBBQkMtVEVDSDItQVJJTg0KICAgIE9yZyBUZWNoIE5hbWU6
IFRlY2huaWNhbCBTdXBwb3J0IE1hbmFnZXINCiAgICBPcmcgVGVjaCBQaG9u
ZTogKzEtOTk5LTk5OS04ODg4IChPZmZpY2UpDQogICAgT3JnIFRlY2ggRW1h
aWw6IHRlY2gtbWdyQGV4YW1wbGUubmV0DQoNCiAgICBPcmcgTk9DIEhhbmRs
ZTogQUJDLU5PQy1BUklODQogICAgT3JnIE5PQyBOYW1lOiBOZXR3b3JrIE9w
ZXJhdGlvbnMgQ2VudGVyDQogICAgT3JnIE5PQyBQaG9uZTogKzEtOTk5LTk5
OS02NjY2IChPZmZpY2UpICoNCiAgICBPcmcgTk9DIEVtYWlsOiBub2NAZXhh
bXBsZS5uZXQNCg0KICAgIE9yZyBBYnVzZSBIYW5kbGU6IEFCQy1BQlUtQVJJ
Tg0KICAgIE9yZyBBYnVzZSBOYW1lOiBOZXR3b3JrIEFidXNlIFN1cHBvcnQN
CiAgICBPcmcgQWJ1c2UgUGhvbmU6ICsxLTk5OS05OTktNTU1NSAoT2ZmaWNl
KSAqDQogICAgT3JnIEFidXNlIEVtYWlsOiBhYnVzZUBleGFtcGxlLm5ldA0K
DQo0LiB3aG9pcyAxMC4zMi4wLjANCiAgICBORVRXT1JLLTEwLjMyIChORVQt
MTAtMzItMC0wKSAgICAgICAgICAgICAgICAgIDEwLjMyLjAuMC8xNg0KICAg
IE5FVC0xMC0zMi1SRSAoTkVULTEwLTMyLTAtMC0yKSAgICAgICAgIDEwLjMy
LjAuMC0xMC4zMi4wLjE5DQoNCjUuIHdob2lzIE5FVC0xMC0zMi0wLTAtMg0K
ICAgIE9yZyBOYW1lOiBYWVogSVNQDQogICAgT3JnIElEOiBYWVoNCg0KICAg
IENJRFIgTmV0IEFkZHJlc3M6IDEwLjMyLjAuMC8yOCwgMTAuMzIuMC4xOS8z
MA0KICAgIE5ldHdvcmsgUmFuZ2U6IDEwLjMyLjAuMC0xMC4zMi4wLjE5DQog
ICAgTmV0d29yayBIYW5kbGU6IE5FVC0xMC0zMi0wLTAtMg0KICAgIE5ldHdv
cmsgTmFtZTogTkVULTEwLTMyLVJFDQogICAgQ2FuIFN1Yi1EZWxlZ2F0ZTog
Tg0KDQogICAgT3JnIFRlY2ggSGFuZGxlOiBYWVotVEVDSC1BUklODQogICAg
T3JnIFRlY2ggTmFtZTogVGVjaG5pY2FsIFN1cHBvcnQNCiAgICBPcmcgVGVj
aCBQaG9uZTogKzEtNzc3LTc3Ny03Nzc3IChPZmZpY2UpICoNCiAgICBPcmcg
VGVjaCBFbWFpbDogdGVjaC14eXpAZXhhbXBsZS5uZXQNCg0KNi4gd2hvaXMg
QUJDLU5PQy1BUklODQogICAgTmFtZTogTmV0d29yayBPcGVyYXRpb25zIENl
bnRlcg0KICAgIEhhbmRsZTogQUJDLU5PQy1BUklODQogICAgQWRkcmVzczog
QUJDIElTUA0KICAgICAgICAgICAgIDEzMiBNYWluIFN0cmVldA0KICAgICAg
ICAgICAgIEFueXRvd24sIFZBIDIyMjIyDQogICAgICAgICAgICAgVVMNCiAg
ICBQaG9uZTogKzEtOTk5LTk5OS02NjY2IChPZmZpY2UpDQogICAgUGhvbmU6
ICsxLTg4OC04ODgtODg4OCAoTW9iaWxlKQ0KICAgIFBob25lOiArMS03Nzct
Nzc3LTc3NzcgKEZheCkNCiAgICBFbWFpbDogbm9jQGV4YW1wbGUubmV0DQo=
- ---559023410-851401618-1015948820=:12375--

------- End of Forwarded Message

Picon

NC teleconf 14/02/02 Agenda item 5: WHOIS referral from ICANN


------- Blind-Carbon-Copy

To: philip.sheppard <at> aim.be
cc: touton <at> icann.org, brunner
Subject: NC teleconf 14/02/02 Agenda item 5: WHOIS referral from ICANN
Date: Wed, 20 Feb 2002 18:33:23 -0500
From: Eric Brunner-Williams in Portland Maine <brunner <at> nic-naa.net>

Philip,

Would you be so kind as to copy me on the item that was referred to the
DNSO's WHOIS TF? I've seen the Verio reconsideration request [1], this is
simply to flush out anything I don't know about.

Eric

References:
[1] http://www.icann.org/committees/reconsideration/rc01-4.htm

------- End of Blind-Carbon-Copy

Picon

Some food for thought


Oki all,

This gem dropped into my in-tray this afternoon, and I've sanitized the part
that is relevant to :43. 

Someone is flogging 10^^8 records that look surprisingly similar to whois
data, from select spindles, in CD form, for $200, or .0005 cents/record.
Of course, the mechanism of acquisition of the data need not have been any
protocol, contract (bulk sale) is another possibility.

Just to keep my understanding of the market in registrant data consistent
with reality, anyone who has data on mass-registrant data (prices, vendors,
date of acquisition, format (this vendor's format of choice is EXCELL), do
drop me a note off-list.

Eric

------- Forwarded Message

>Subject: 10.000.000 Domains For You
>
>You could be interested in [advert identifer removed]
>
>[advert identifer removed] Multi-CD-Roms Marketeers Domain Names Kit
>is a wonderful tool for Internet Marketing.
>It contains a domain database with 10 million records from .com, .net,
>.org, and .edu.
>
>Each record includes:
>	Domain Name,
> 	Registrant,
> 	Registrant Code,
> 	Registrant Address,
> 	Registrant City,
> 	Admin Contact,
> 	Admin Code,
> 	Admin email,
> 	Admin Company,
> 	Admin Address,
> 	Admin City,
> 	Admin Tel,
> 	Admin Fax,
> 	Tech Contact,
> 	Tech Code,
> 	Tech Email,
> 	Tech Company,
> 	Tech Address,
> 	Tech City,
> 	Tech Tel,
> 	Tech Fax,
> 	Bill Contact,
> 	Bill Code,
> 	Bill Email,
> 	Bill Company,
> 	Bill Address,
> 	Bill City,
> 	Bill Tel,
> 	Bill Fax,
> 	Server 1,
> 	Server IP 1,
>       ...
>	Server 6,
>	Server IP 6

------- End of Forwarded Message

Florian Weimer | 13 Feb 09:22 2002
Picon

Registering handle suffixes


Is it possible to register WHOIS handle suffixes somewhere, to avoid
collisions?

Picon

!43 BoF <at> -53; co-chair status; whois-fix status


Oki all,

For those who aren't on the !43 list (details below), a few days ago Leslie
Daigle (leslie <at> research.netsol.com) sent out a BoF announcement for -53. In
the proposed charter for the BoF (Cross-Registry Information Service Protocol
(CRISP)), backwards compatibility with RFC 954 is listed as a non-goal.

Shortly before -52, when I realized that both Dave and I had a beneficiary
relationship with the same company, incidently a whois:43 operator, and at
some risk of 3rd-party interference, I sent mail to this list announcing
that for family reasons I was cutting back on non-essential travel, and would
not travel from Maine to Salt Lake.

While my family reasons isn't likely to change till mid-year, I'm happy to
announce that the shared beneficiary relationship problem has been resolved,
and there is no risk of 3rd-party interference. I propose to continue to "co"
and move the -51 BoF and this mailing list to a working group -- with all of
your explicit, or at least tacit consent.

There is still, as I wrote then (11/9/01) still a charter to complete, and
time-line drift to correct for, assuming that the dates and deliverables were
approximately correct.

I'll still taking updates to the chart we started at London, the per-ccTLD
details. I'd like to se one for the per-RIR and per-LIR details. Anyone???

Eric

This is "below":

Discussions about Internet infrastructure directory service protocols and
requirements that aren't whois. <ietf-not43.lists.research.netsol.com>
mailto:ietf-not43-request <at> lists.research.netsol.com?subject=subscribe


Gmane