Re: draft-campbell-whois-00.txt

[Bruce Campbell <bruce_campbell@xxxxxxxx>]

On Sun, 10 Feb 2002, Allen Smith wrote:

> > 1.2 Aims of this Document
> >
> >    This document aims to provide an accurate definition of the basic WHOIS
> >    protocol used on the Internet today.  It includes observed variations
> >    on possible queries and answers.
> >
> >    This document does NOT provide definitions of the possibly sensitive
> >    subjects as follows:
> >
> >          Data that must be registered in any Database
> >          Data that must be protected by Privacy Concerns
> >          Output Format of Data
>
> Is there some particular reason why, at the minimum, either the
> RIPE-181 or RPSL format should not be available (with others being

Current installed base of 'whois' servers indicates that such a
requirement on output format would be politically incorrect, and not able
to be implemented in some cases.

> >          Question Format (beyond a requirement for 'help')
> >
> >    The above definitions are defined by the Registry operating a
> >    particular Database, and the Laws of that Registry's Country.
>
> I suggest deletion of the above two lines, at the minimum. There are a
> number of other factors which govern this:
> 	A. Other RFCs, with their requirements for registries, et al;
> 	   see above.
> 	B. Requirements of parent registries and of ICANN. The latter

Both correct.

> > 2. Requirements
>
> [...]
>
> >    A public 'WHOIS' Server SHOULD have as one of its aliases, a
> >    hostname of 'whois', eg 'whois.example.com'.
>
> Aliases? Unless you're meaning this in a different sense than I have
> customarily seen it used, "alias" implies that this is not the (or a)
> "real hostname" of the server in question (i.e., that which will be
> returned by a PTR lookup (or will be among those returned by a PTR
> lookup) and which is not the domain name for a CNAME record - in
> common parlance, "is not a CNAME"). "SHOULD have as one of its
> hostnames (or aliases)", perhaps?

Accepted, pending a review of DNS terms.

> > 2.2.1 Server Operator
> >
> >    The Entity or Entities in charge of a given 'WHOIS' Server who is/are
> >    responsible for the behaviour and operation of a given Server.  The
> >    Server Operator MUST report usage, problems (etc) with the 'WHOIS'
> >    Server to the Registry responsible for the Database.  This implies
> >    that the Server MUST log usage of the Server in some fashion.
> >
> >    The Server Operator, in addition to abiding by any restrictions set
> >    by the Registry, may add extra restrictions to the use of the Server,
> >    possibly dynamically in response to Client behaviour.
>
> Except as required otherwise by the Registry and other RFCs, including
> those governing the conduct of Registries, or as the welfare of the
> Internet may dictate.

Perhaps:

	The Server Operator, in addition to abiding by any and all
	restrictions set by the Registry, may add extra restrictions to
	the usage of the Server where such extra restrictions do not
	conflict with existing restrictions.

Elsewhere it covers possible behaviour in response to data-mining
activities (etc), so the 'dynamically in response' is unneeded at that
point.

> > 2.3 Registry
> >
> >    The Entity or Entities in charge of a given Database which is
> >    accessible via a given 'WHOIS' Database.  Normally, the Server
> >    Operator(s) and the Registry are the same Entities, however a
> >    distinction must be made between the two to reflect operational
> >    practice.
> >
> >    Where the Registry is the custodian of Data covered by Privacy
> >    Restrictions, the Registry MUST enforce these restrictions.
>
> Is there some reason why this needs to be in the RFC? Normally, such
> "Privacy Restrictions" are imposed by laws (either privacy laws or
> contract laws). If a country (or association of countries, such as the
> EU) wishes to have and enforce such laws, they have their own means of
> doing so...

I suspect that I was trying to ensure that by referencing possible privacy
restrictions, it would serve as a reminder that such restrictions may
exist.

> >    The Registry MAY also add extra restrictions to the use of it's
> >    Data/Database.
>
> Again, so long as these do not conflict with rules by a parent
> Registry, ICANN/IANA, or the welfare of the Internet community as a
> whole.

Noted, will reword similar to 2.2.1.

> > 2.3.2 Updating the Database
> >
> [...]
>
> >    The Registry may require certain information required for the
> >    Registry's Operation to be registered within it's Database.
>
> >From the RFCs I have cited above, and the needs of the Internet for
> contact and other information to deal with problems, this information
> MUST be required by the Registry to be placed in the database and made
> public.

Correct, but the requirement for such data disclosure cannot be in the
document describing the port 43 interactions.

> > 2.3.3 Normal Usage of Data
> >
> >    The exact usage of the Data within a Database is left for the
> >    Registry to define, however Data obtained via WHOIS has historically
> >    been for Internet Operational Purposes.  Users should refer to the
> >    usage conditions imposed by a given Registry.
>
> The data in such a database MUST be available to be used for purposes
> needed by the Internet community.

No.  'WHOIS' is used by applications other than documenting
domain/ip/person records.

> > 3.2.1 Language and Character Set
> >
> >    The 'WHOIS' Server operator MAY nominate a Language and Character Set
> >    to be used for any part of the 'Question'.  If a Language or
> >    Character Set other than 'English' and 'US-ASCII' is expected from
> >    the Client, the Server MAY provide an initial banner message before
> >    the Question is asked, specifying the Language and Character set in
> >    use. [BCP18]
>
> I suggest "SHOULD", at least for Character Sets other than
> 'US-ASCII', given possible problems with clients not expecting other
> Character Sets.

Noted.

> > 3.3.3 Banner
> >
> >    The Server MAY supply a Banner Message at three points during the
> >    connection:
> >
> >       Immediately after initial connection,
> >
> >       Immediately after the termination of the Question by the Client
> >       and before the output of the Answer.
> >
> >       Immediately after the output of the Answer.
> >
> >    To assist readability, the Banner Message SHOULD NOT exceed a polite
> >    4 lines.
> >
> >    The Client MUST display any Banner Message to the User without
> >    alteration.
>
> Umm... including without, say, translation into a different language,
> alteration of character set for display purposes, etcetera?

Please rephrase your point as it doesn't make sense.

> > 3.3.5 Warning Messages
> >
> >    The Server MAY supply Warning Messages where part or all of the
> >    Question is inappropriate as defined by the Server Operator.
> >    Warning Messages should supply accurate and up to date information
> >    about the perceived problem with the Question, Connection or Client.
>
> Is there some reason why this is not "SHOULD supply"?

Hrm.  MAY as in 'the query MAY be inappropriate'.  Perhaps:

	The Server SHOULD supply Warning Messages _if_ part or all of the
	Question is inappropriate as defined by the Server Operator
	(etc)

( noted also for error and rejection messages )

Regards,


-- 
                             Bruce Campbell                            RIPE
                   Systems/Network Engineer                             NCC
                 www.ripe.net - PGP562C8B1B                      Operations