if a query will be denied before the query is submitted according to
the appropriate policies of the operator.
3.1.8.2. Service Description
Because usage scenarios will differ depending on both policy and type
of service, some server operators may want to provide the ability for
a client to predetermine its ability to retrieve data from a query.
However, some operators will not allow this for security reasons,
policy restrictions, or other matters.
3.1.9. Authentication Distribution
3.1.9.1. Protocol Requirement
The protocol MUST NOT require any Internet registry to participate in
any authentication system. The protocol MUST NOT prohibit the
participation by an Internet registry in federated, distributed
authentication systems.
3.1.9.2. Service Description
Some server operators may have a need to delegate authentication to
another party or participate in a system where authentication
information is distributed. However, the ability to operate a CRISP
compliant server must not require this.
3.1.10. Base Error Responses
The protocol MUST be capable of returning the following types of
non-result or error responses to all lookups and searches:
o permission denied - a response indicating that the search or
lookup has failed due to insufficient authorization.
o not found - the desired results do not exist.
o insufficient resources - the search or lookup requires resources
that cannot be allocated.
3.1.11. Query Distribution
3.1.11.1. Protocol Requirement
The protocol MUST NOT prohibit a server from participating in a query
distribution system.
3.1.11.2. Service Description
For lookups and searches requiring distribution of queries, the
client must be allowed to distribute these queries among the
participants in an established mesh of server operators. It is not a
requirement that the protocol enable the discovery of servers, but
cooperating servers should be able to intelligently handle
distribution with its established mesh. Individual server operators
will respond to all queries received according to their policies for
authentication, privacy, and performance.
However, the ability to operate a CRISP compliant server must not
require the participation in any query distribution system.
3.1.12. Protocol and Schema Versioning
3.1.12.1. Protocol Requirements
The protocol MUST provide a means by which the end-systems can either
identify or negotiate over the protocol version to be used for any
query or set of queries.
All resource-specific schema MUST provide a version identifier
attribute which uniquely and unambiguously identifies the version of
the schema being returned in the answer set to a query.
3.1.12.2. Service Description
The service should allow end-systems using different protocol
versions to fallback to a mutually supported protocol version. If
this is not possible, the service must provide a meaningful error
which indicates that this is the specific case.
The service must suggest negotiation and/or recovery mechanisms for
clients to use when an unknown schema version is received.
3.1.13. Relay Bag
The term "bag" in this section describes a flexible container which
may contain unspecified data.
3.1.13.1. Protocol Requirement
When issuing a referral, the protocol MUST be capable of supplying a
relay bag from the server to the client, and the protocol MUST be
capable of allowing the client to submit this relay bag with a query
to the referred server. The use of the relay bag MUST be OPTIONAL.
The protocol MUST NOT make any assumptions regarding the contents of
the relay bag, but the relay bag MUST be described using the schema
language of the protocol.
The protocol MUST provide different error messages to indicate
whether the bag is of unrecognized format (permanent failure), if it
contains unacceptable data (permanent failure), or if it contains
data that means processing is refused at this time (transient
failure).
There MUST be no more than one bag per referral. The protocol MUST
NOT make an association or linkage between successive bags in a
referral chain.
The client MUST pass the bag as part of any query made to a referrant
server as a result of a referral.
3.1.13.2. Service Description
In some models where service coordination among participating server
operators is utilized, there might be needs to allow a referring
server to pass operator-to-operator coordination data along with the
referral to the referent server. Such needs might be auditing or
tracking. This feature requirement allows a server to pass to the
client a flexible container of unspecified data ("bag") that the
client should pass to the referent server. The bag has no meaning to
the client.
3.1.14. Privacy Labels
3.1.14.1. Protocol Requirement
When a value in an answer to a query is given, the protocol MUST be
capable of tagging the value with the following labels:
1. do not redistribute
2. special access granted
The protocol MAY define other values for this purpose, but MUST
define values defined above at a minimum. The protocol MUST be
capable of attaching these labels concurrently.
3.1.14.2. Service Description
Internet registries will have varying policies regarding the access
to their data. Some registries may grant certain classes of users
with access to data that would not normally be given to most users.
In these cases, registries may want to tag the values in these
entries with labels specifying the responsibilities accompanying
these special user rights.
3.2. Domain Specific Functions
These functions describe requirements specifically needed by domain
registries (Section 2.1.1) and domain registrars (Section 2.1.2).
Requirements specific to other registries (Section 2.2) MUST be
specified separately. No compliant server operator is required to
support the functions required by every registry type.
3.2.1. Lookups
3.2.1.1. Protocol Requirement
The protocol MUST contain the following lookup functions:
1. Contact lookup given a unique reference to a contact of a
resource.
2. Nameserver lookup given a fully-qualified host name or IP address
of a nameserver.
3. Domain lookup given a fully-qualified domain name.
See Section 3.2.3 for the requirements regarding the expected return
values.
3.2.1.2. Service Description
These lookups are all single index queries and should produce zero or
only one entity.
Depending on the policy and need of an Internet registry, a server
operator may not allow all or any of these lookups to return part or
all of the information. See Section 3.2.3.
3.2.2. Searches
3.2.2.1. Protocol Requirement
The protocol MUST contain the following search functions:
1. Domain name search given an exact match or reasonable subset of a
name. This search SHOULD allow for parameters and qualifiers
designed to allow better matching of internationalized domain
names and SHOULD allow for both exact and partial matching within
the limits of internationalized domain names. This search SHOULD
NOT require special transformations of internationalized domain
names to accommodate this search. This search MUST provide a
means to narrow the search by names delegated under a particular
TLD.
2. Domain registrant search by either exact name or partial name
match with the ability to narrow the search to registrants of a
particular TLD.
3. Domains hosted by a nameserver given the fully-qualified host name
or IP address of a nameserver.
See Section 3.2.3 for the requirements regarding the expected return
values.
3.2.2.2. Service Description
Depending on the policy and need of an Internet registry, a server
operator may not allow all or any of these searches to return part or
all of the information. See Section 3.1.4. Access to information
resulting from these searches may also be limited, depending on
policy, by quantity. Section 3.2.5 describes these types of
restrictions.
Some Internet registries may also be participating in a query
distribution system. See Section 3.1.11.
3.2.3. Information Sets
3.2.3.1. Protocol Requirements
The data sets for contacts, nameservers, and domains MUST be able to
express and represent the attributes and allowable values of
registration requests in domain registration and provisioning
protocols.
The schema MUST be capable of expressing the following information
for domains:
o activation status
o registrant
o nameservers
o technical, billing or other contacts
o registry delegating the domain
o registrar for the domain
The data set for domains MUST be able to express arbitrary textual
information for extensions on an individual operator basis. Examples
of such information are license agreements, authorized use policies,
extended status notifications, marketing/for sale notices, and URI
references to other sources.
3.2.3.2. Service Description
It is not expected that every Internet registry supply all of the
information spelled out above, however the schemas employed by the
protocol must be capable of expressing this information should a
registry need to provide it.
The following sections describe requirements relative to the use of
schemas with respect to individual registry need and policy:
o Section 3.2.8
o Section 3.2.5
o Section 3.1.4
o Section 3.1.1
3.2.4. Serialization Support
The schemas used by the protocol SHOULD be capable of off-line
serialization
Off-line serialization allows for implementation independent
operations such as backup and recovery, load-balancing, etc. This
MAY also make possible, in whole or in part, data escrow capabilities
and other usages, however such usages are out of the scope of this
document.
3.2.5. Result Set Limits
3.2.5.1. Protocol Requirement
The protocol MUST contain a feature, used at the discretion of a
server operator, to allow a server to express to a client a limit on
the number of results from searches and lookups. When returning
result sets, the protocol MUST be able to make the following
distinctions:
1. an empty result set.
2. a result set truncated for the purpose of improving performance
bottlenecks.
3. a result set truncated to comply with Section 3.1.1
3.2.5.2. Service Description
Client software will operate more usefully if it can understand
reasons for the truncation of result sets. Of course, some Internet
registries may not be able to expose their policies for the limiting
of result sets, but, when it is possible, clients will have a better
operational view. This may eliminate re-queries and other repeated
actions that are not desirable.
3.2.6. DNS Delegation Referencing
3.2.6.1. Protocol Requirement
The protocol MUST use the delegation authority model available in DNS
[1] as the primary means for determining the authoritative source for
information regarding domains or any other objects when applicable.
3.2.6.2. Service Description
The intent of this requirement is to have clients use the DNS
delegation model to find servers authoritative for resources instead
of using a master or central server containing pointer information.
In other words, when a resource is naturally mapped by DNS, the
desired behavior is to consult the DNS to find an authoritative
server containing information about that resource. Using
’example.com’, the authoritative server for information about
example.com according to the registrant of that domain may be found
by querying the DNS zone for example.com. To find the registry
information for example.com, the DNS zone for .com should be queried.
There are cases where resources will not naturally map into the DNS
delegation hierarchy. This requirement is not meant to force such a
mapping.
3.2.7. Distribution for Domain Registry Types
3.2.7.1. Protocol Requirement
The protocol MUST NOT prohibit the distribution of data to exclude
any of the registry/registrar models stated in Section 2.1.1. The
protocol MUST be capable of expressing referrals and entity
references between the various models described in Section 2.1.1.
3.2.7.2. Service Description
Depending on the domain registry/registrar model in use, technical
data for a domain may only reside in one server while contact data
for the same domain may only reside in a server operated by a
separate entity. However, in many uses, this is not the situation.
Therefore, the service must accommodate for the various registration
distribution models of domain registry types described in Section
2.1.1 while complying with Section 3.1.7.
3.2.8. Data Omission
3.2.8.1. Protocol Requirement
When a value in an answer to a query cannot be given due to policy
constraints, the protocol MUST be capable of expressing the value in
one of three ways:
1. complete omission of the value without explanation
2. an indication that the value cannot be given due to insufficient
authorization
3. an indication that the value cannot be given due to privacy
constraints regardless of authorization status
The protocol MAY define other values for this purpose, but MUST
define values defined above at a minimum.
3.2.8.2. Service Description
Internet registries will have varying constraints regarding their
ability to expose certain types of data, usually social information.
Server operators must have the ability to accommodate this need while
client software will be more useful when provided with proper
explanations. Therefore, depending on policy, a server operator has
a choice between not returning the data at all, signaling a
permission error, or indicating a privacy constraint.
3.2.9. Internationalization
The schema defining domain related resources MUST conform to RFC 2277
[2] regarding textual data. In particular, the schema MUST be able
to indicate the charset and language in use with unstructured textual
data.
The protocol MUST be able to support multiple representations of
contact data, with these representations complying with the
requirements in Section 3.2.3. The protocol MUST be able to provide
contact data in UTF-8 and SHOULD be able to provide contact data in
US-ASCII, other character sets, and capable of specifying the
language of the data.
4. Feature Requirements
Feature requirements describe the perceived need derived from the
functional requirements for specific technical criteria of the
directory service. This section describes requirements in the manner
specified in Section 1.3.
4.1. Client Authentication
Entities accessing the service (users) MUST be provided a mechanism
for passing credentials to a server for the purpose of
authentication. The protocol MUST provide a mechanism capable of
employing many authentication types and capable of extension for
future authentication types.
4.2. Referrals
To distribute queries for search continuations and to issue entity
references, the protocol MUST provide a referral mechanism.
4.3. Common Referral Mechanism
To distribute queries for search continuations and to issue entity
references, the protocol MUST define a common referral scheme and
syntax.
4.4. Structured Queries and Responses
To provide for machine consumption as well as human consumption, the
protocol MUST employ structured queries and responses.
4.5. Existing Schema Language
To provide structured queries and responses and allow for minimal
technological reinvention, the protocol MUST employ a pre-existing
schema language.
4.6. Defined Schemas
To provide for machine consumption as well as human consumption, the
protocol MUST define schemas for use by the structured queries and
responses.
5. Internationalization Considerations
Requirements defined in this document MUST consider the best
practices spelled out in [2].
6. IANA Considerations
IANA consideration for any service meeting these requirements will
depend upon the technologies chosen and MUST be specified by any
document describing such a service.
7. Security Considerations
This document contains requirements for the validation of
authenticated entities and the access of authenticated entities
compared with the access of non-authenticated entities. This
document does not define the mechanism for validation of
authenticated entities. Requirements defined in this document MUST
allow for the implementation of this mechanism according best common
practices.
The requirement in Section 3.1.4 must be weighed against other
requirements specifying search or lookup capabilities.
This document contains requirements for referrals and entity
references. Client implementations based on these requirements
SHOULD take proper care in the safe-guarding of credential
information when resolving referrals or entity references according
to best common practices.
This document contains requirements for the distribution of queries
among a mesh of participating service providers. Protocols proposed
to meet these requirements must be able to protect against the use of
that distribution system as a vector of distributed denial of service
attacks or unauthorized data mining.
Normative References
[1] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[2] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Informative References
[4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[5] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167,
June 1997.
[6] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
954, October 1985.
[7] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing
Policy Specification Language (RPSL)", RFC 2622, June 1999.
URIs
[8] <http://www.ietf.org/proceedings/00dec/00dec-41.htm>
[9] <http://www.ietf.org/proceedings/01aug/51-40.htm>
[10] <http://www.uwho.verisignlabs.com/
Final-WhoIsPanel-Aug15-Resume.pdf>
[11] <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/
min_database.html>
[12] <http://www.nanog.org/mtg-0110/lookup.html>
Appendix A. Glossary
o TLD: Initials for "top level domain." Referes to domains in DNS
[1] that are hierarchically at the level just beneath the root.
o ccTLD: Initials for "country code top level domain." TLD’s which
use one of the two character country codes defined by ISO.
o gTLD: Initials for "generic top level domain." TLD’s that do not
use one of the two character country codes defined by ISO.
o contact data: Data containing names and contact information (i.e.,
postal addresses, phone numbers, e-mail addresses) of humans or
legal entities.
o operational data: Data necessary to the operation of networks and
network related services and items.
o RIR: Initials for "regional Internet registry."
o IRR: Initials for "Internet routing registry."
o forward lookup: a DNS lookup where a domain name is resolved to an
IP address.
o reverse lookup: a DNS lookup where an IP address is resolved to a
domain name.
o mining: In the context of this document, this term is specific to
data mining. This is a methodical process to obtain the contents
of directory service, usually as much as possible, not relevant to
any immediate need. Data mining is often not a practice welcomed
by registry operators.
Appendix B. Acknowledgements
B.1. Forums
The proceedings of the following public forums were used as input to
the scope and requirements for this document:
o whois BOF of the 49th IETF [8]; December 10-15, 2000; San Diego,
CA, USA
o whoisfix BOF of the 51st IETF [9]; August 5-10, 2001; London,
England
o First UWho Consultation [10]; August 15, 2001; Washington, DC, USA
o Second UWho Consultation; November 15, 2001; Marina del Rey, CA,
USA
o Third UWho Consultation; November 19, 2001; Washington, DC, USA
o DNR WG of RIPE 40, October 1-5, 2001; Praque, Czech Republic
o Database WG of RIPE 40 [11]; October 1-5, 2001; Praque, Czech
Republic
o General Session of NANOG 23 [12]; October 21-23; Oakland, CA, USA
o DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
o Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The
Netherlands
o NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida
o CENTR General Assembly, February 21-22, 2002; Rambouillet, France
o CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis,
Minnesota, USA
B.2. Working Group
This document is a work item of the Cross-Registry Internet Service
Protocol (CRISP) Working Group in the Applications Area of the IETF.
Discussions for this working group are held on the email list ietf-
not43@lists.verisignlabs.com. To subscribe to this email list, send
email to ietf-not43-request@lists.verisignlabs.com with a subject
line of "subscribe". Archives of this list may be found out
http://lists.verisignlabs.com/pipermail/ietf-not43/.
B.3. Contributions
Comments, suggestions, and feedback of significant substance have
been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane Kerr,
Cathy Murphy, Stephane Bortzmeyer, Rick Wesson, Jaap Akkerhuis, Eric
Hall, Patrick Mevzek, Marcos Sanz, Vittorio Bertola, George
Michaelson, and Tim Christensen.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF’s procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Author’s Address
Andrew L. Newton
VeriSign, Inc.
21355 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; anewton@ecotroph.net
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the