[Ietf-not43] crisp requirements matrix
Andrew Newton
anewton@ecotroph.net
Wed Mar 26 18:44:39 EST 2003
This is a MIME-formatted message. If you see this text it means that your
E-mail software does not support MIME-formatted messages.
--=_zak-3288-1048704565-0001-2
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Here is a first pass at the crisp requirements matrix. The entries are
based on the latest draft in the repository. Therefore, they will
change with the addition of the new text from the comments period and
the expected comments due in about 2 weeks.
If you have comments on the format or structure of the matrix, please
send them to the list. It is provided in both HTML and ASCII text format.
-andy
--=_zak-3288-1048704565-0001-2
Content-Type: text/plain; name="crisp-matrix.txt"; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="crisp-matrix.txt"
CRISP Technical Proposal Evaluation Matrix
+------------------------------------------------------------------------+
| Requirement | IRIS | LW | Comment |
|------------------------------------------------------------------------|
| Sample |
|------------------------------------------------------------------------|
| The protocl MUST be capable of | NO | YES | IRIS only gives the |
| walking and chewing gum at the | | | appearance of |
| same time. | | | walking and chewing |
| | | | gum simultaneously, |
| | | | but it in fact |
| | | | requires two |
| | | | separate CPU clock |
| | | | cycles. On the other |
| | | | hand, LW does the |
| | | | walking on the |
| | | | rising edge of the |
| | | | cycle and the gum |
| | | | chewing on the |
| | | | falling edge of the |
| | | | cycle. |
|------------------------------------------------------------------------|
| Section 3.1.2 |
|------------------------------------------------------------------------|
| The protocol MUST NOT employ | | | |
| unique technology solutions for | | | |
| all aspects and layers above the | | | |
| network and transport layers and | | | |
| SHOULD make use of existing | | | |
| technology standards where | | | |
| applicable. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST employ the use | | | |
| of network and transport layer | | | |
| standards as defined by the | | | |
| Internet Engineering Task Force. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST define one or | | | |
| more transport mechanisms for | | | |
| mandatory implementation. | | | |
|------------------------------------------------------------------------|
| Section 3.1.3.1 |
|------------------------------------------------------------------------|
| The protocol MUST contain standard | | | |
| schemas for the exchange of data | | | |
| needed to implement the | | | |
| functionality in this document. | | | |
|------------------------------------+------+-----+----------------------|
| there MUST be a means to allow the | | | |
| use of schemas not defined by the | | | |
| needs of this document. | | | |
|------------------------------------+------+-----+----------------------|
| Both types of schemas MUST use the | | | |
| same schema language. | | | |
|------------------------------------+------+-----+----------------------|
| The schemas MUST be able to | | | |
| express data elements with | | | |
| identifying tags for the purpose | | | |
| of localization of the meaning of | | | |
| the identifying tags. | | | |
|------------------------------------------------------------------------|
| Section 3.1.4.1 |
|------------------------------------------------------------------------|
| The protocol MUST NOT prohibit an | | | |
| operator from granularly assigning | | | |
| multiple types of access to data | | | |
| according to the policies of the | | | |
| operator. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST provide an | | | |
| authentication mechanism and MUST | | | |
| NOT prohibit an operator from | | | |
| granting types of access based on | | | |
| authentication. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST provide an | | | |
| anonymous access mechanism that | | | |
| may be turned on or off based on | | | |
| the policy of an operator. | | | |
|------------------------------------------------------------------------|
| Section 3.1.5 |
|------------------------------------------------------------------------|
| The protocol MUST be capable of | | | |
| allowing machine parsable requests | | | |
| and responses. | | | |
|------------------------------------------------------------------------|
| Section 3.1.6 |
|------------------------------------------------------------------------|
| The protocol MUST be capable of | | | |
| allowing machine parsable requests | | | |
| and responses. | | | |
|------------------------------------------------------------------------|
| Section 3.1.7.1 |
|------------------------------------------------------------------------|
| The protocol MUST NOT require the | | | |
| aggregation of data to a central | | | |
| repository, server, or entity. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST NOT require | | | |
| aggregation of data indexes or | | | |
| hints to a central repository, | | | |
| server, or entity. | | | |
|------------------------------------------------------------------------|
| Section 3.1.8.1 |
|------------------------------------------------------------------------|
| The protocol MUST provide a | | | |
| mechanism allowing a client to | | | |
| determine if a query will be | | | |
| denied before the query is | | | |
| submitted according to the | | | |
| appropriate policies of the | | | |
| operator. | | | |
|------------------------------------------------------------------------|
| Section 3.1.9.1 |
|------------------------------------------------------------------------|
| 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. | | | |
|------------------------------------------------------------------------|
| Section 3.1.10 |
|------------------------------------------------------------------------|
| The protocol MUST be capable of returning the following types of |
| non-result or error responses to all lookups and searches: |
|------------------------------------------------------------------------|
| permission denied - a response | | | |
| indicating that the search or | | | |
| lookup has failed due to | | | |
| insufficient authorization. | | | |
|------------------------------------+------+-----+----------------------|
| not found - the desired results do | | | |
| not exist. | | | |
|------------------------------------+------+-----+----------------------|
| insufficient resources - the | | | |
| search or lookup requires | | | |
| resources that cannot be | | | |
| allocated. | | | |
|------------------------------------------------------------------------|
| Section 3.1.11.1 |
|------------------------------------------------------------------------|
| The protocol MUST NOT prohibit a | | | |
| server from participating in a | | | |
| query distribution system. | | | |
|------------------------------------+------+-----+----------------------|
| Section 3.1.12.1 | | | |
|------------------------------------+------+-----+----------------------|
| 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. | | | |
|------------------------------------------------------------------------|
| Section 3.1.13.1 |
|------------------------------------------------------------------------|
| 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. | | | |
|------------------------------------------------------------------------|
| Section 3.2.1.1 |
|------------------------------------------------------------------------|
| The protocol MUST contain the following lookup functions: |
|------------------------------------------------------------------------|
| Contact lookup given a unique | | | |
| reference to a contact of a | | | |
| resource. | | | |
|------------------------------------+------+-----+----------------------|
| Nameserver lookup given a | | | |
| fully-qualified host name or IP | | | |
| address of a nameserver. | | | |
|------------------------------------+------+-----+----------------------|
| Domain lookup given a | | | |
| fully-qualified domain name. | | | |
|------------------------------------------------------------------------|
| Section 3.2.2.1 |
|------------------------------------------------------------------------|
| The protocol MUST contain the following search functions: |
|------------------------------------------------------------------------|
| 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. | | | |
|------------------------------------+------+-----+----------------------|
| Domain registrant search by either | | | |
| exact name or partial name match | | | |
| with the ability to narrow the | | | |
| search to registrants of a | | | |
| particular TLD. | | | |
|------------------------------------+------+-----+----------------------|
| Domains hosted by a nameserver | | | |
| given the fully-qualified host | | | |
| name or IP address of a | | | |
| nameserver. | | | |
|------------------------------------------------------------------------|
| Section 3.2.3.1 |
|------------------------------------------------------------------------|
| 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: |
|------------------------------------------------------------------------|
| activation status | | | |
|------------------------------------+------+-----+----------------------|
| registrant | | | |
|------------------------------------+------+-----+----------------------|
| nameservers | | | |
|------------------------------------+------+-----+----------------------|
| technical, billing or other | | | |
| contacts | | | |
|------------------------------------+------+-----+----------------------|
| registry delegating the domain | | | |
|------------------------------------+------+-----+----------------------|
| registrar for the domain | | | |
|------------------------------------+------+-----+----------------------|
| The data set for domains MUST be | | | |
| able to express arbitrary textual | | | |
| information for extensions on an | | | |
| individual operator basis. | | | |
|------------------------------------------------------------------------|
| Section 3.2.4 |
|------------------------------------------------------------------------|
| The schemas used by the protocol | | | |
| SHOULD be capable of off-line | | | |
| serialization. | | | |
|------------------------------------------------------------------------|
| Section 3.2.5.1 |
|------------------------------------------------------------------------|
| 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: |
|------------------------------------------------------------------------|
| an empty result set. | | | |
|------------------------------------+------+-----+----------------------|
| a result set truncated for the | | | |
| purpose of improving performance | | | |
| bottlenecks. | | | |
|------------------------------------+------+-----+----------------------|
| a result set truncated to comply | | | |
| with Section 3.1.1 | | | |
|------------------------------------------------------------------------|
| Section 3.2.6.1 |
|------------------------------------------------------------------------|
| 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. | | | |
|------------------------------------------------------------------------|
| Section 3.2.7.1 |
|------------------------------------------------------------------------|
| 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. | | | |
|------------------------------------------------------------------------|
| Section 3.2.8.1 |
|------------------------------------------------------------------------|
| 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: |
|------------------------------------------------------------------------|
| complete omission of the value | | | |
| without explanation | | | |
|------------------------------------+------+-----+----------------------|
| an indication that the value | | | |
| cannot be given due to | | | |
| insufficient authorization | | | |
|------------------------------------+------+-----+----------------------|
| 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. | | | |
|------------------------------------------------------------------------|
| Section 3.2.9 |
|------------------------------------------------------------------------|
| 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. | | | |
|------------------------------------------------------------------------|
| Section 4.1 |
|------------------------------------------------------------------------|
| Entities accessing the service | | | |
| (users) MUST be provided a | | | |
| mechanism for passing credentials | | | |
| to a server for the purpose of | | | |
| authentication. | | | |
|------------------------------------------------------------------------|
| Section 4.2 |
|------------------------------------------------------------------------|
| The protocol MUST provide a | | | |
| mechanism capable of employing | | | |
| many authentication types and | | | |
| capable of extension for future | | | |
| authentication types. | | | |
|------------------------------------------------------------------------|
| Section 4.3 |
|------------------------------------------------------------------------|
| To distribute queries for search | | | |
| continuations and to issue entity | | | |
| references, the protocol MUST | | | |
| provide a referral mechanism. | | | |
|------------------------------------------------------------------------|
| Section 4.4 |
|------------------------------------------------------------------------|
| To distribute queries for search | | | |
| continuations and to issue entity | | | |
| references, the protocol MUST | | | |
| define a common referral scheme | | | |
| and syntax. | | | |
|------------------------------------+------+-----+----------------------|
| Section 4.5 | | | |
|------------------------------------+------+-----+----------------------|
| To provide structured queries and | | | |
| responses and allow for minimal | | | |
| technological reinvention, the | | | |
| protocol MUST employ a | | | |
| pre-existing schema language. | | | |
|------------------------------------+------+-----+----------------------|
| Section 4.6 | | | |
|------------------------------------+------+-----+----------------------|
| To provide for machine consumption | | | |
| as well as human consumption, the | | | |
| protocol MUST define schemas for | | | |
| use by the structured queries and | | | |
| responses. | | | |
+------------------------------------------------------------------------+
--=_zak-3288-1048704565-0001-2
Content-Type: text/html; charset=utf-8; name="crisp-matrix.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="crisp-matrix.html"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
<TITLE></TITLE>
<META NAME="GENERATOR" CONTENT="OpenOffice.org 1.0.1 (Linux)">
<META NAME="CREATED" CONTENT="20030325;14461200">
<META NAME="CHANGED" CONTENT="20030325;17011400">
<STYLE>
<!--
@page { size: 21.59cm 27.94cm; margin-left: 3.18cm; margin-right: 3.18cm; margin-top: 2.54cm; margin-bottom: 2.54cm }
P { margin-bottom: 0.21cm }
H1 { margin-bottom: 0.21cm }
H1.western { font-family: "Luxi Sans", sans-serif; font-size: 16pt }
H1.cjk { font-size: 16pt }
H1.ctl { font-size: 16pt }
TD P { margin-bottom: 0.21cm }
TH P { margin-bottom: 0.21cm; font-style: italic }
-->
</STYLE>
</HEAD>
<BODY LANG="en-US">
<H1 CLASS="western" ALIGN=CENTER>CRISP Technical Proposal Evaluation
Matrix</H1>
<P STYLE="margin-bottom: 0cm"><BR>
</P>
<TABLE WIDTH=569 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=4 CELLSPACING=0>
<COL WIDTH=303>
<COL WIDTH=41>
<COL WIDTH=39>
<COL WIDTH=152>
<THEAD>
<TR VALIGN=TOP>
<TH WIDTH=303>
<P>Requirement</P>
</TH>
<TH WIDTH=41>
<P>IRIS</P>
</TH>
<TH WIDTH=39>
<P>LW</P>
</TH>
<TH WIDTH=152>
<P>Comment</P>
</TH>
</TR>
</THEAD>
<TBODY>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Sample</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocl MUST be capable of walking and chewing gum at the
same time.</P>
</TD>
<TD WIDTH=41>
<P>NO</P>
</TD>
<TD WIDTH=39>
<P>YES</P>
</TD>
<TD WIDTH=152>
<P>IRIS only gives the appearance of walking and chewing gum
simultaneously, but it in fact requires two separate CPU clock
cycles. On the other hand, LW does the walking on the rising
edge of the cycle and the gum chewing on the falling edge of the
cycle.</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.1.2</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST NOT employ unique technology solutions for
all aspects and layers above the network and transport layers and
SHOULD make use of existing technology standards where
applicable.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST employ the use of network and transport
layer standards as defined by the Internet Engineering Task
Force.
</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST define one or more transport mechanisms for
mandatory implementation.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.1.3.1</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST contain standard schemas for the exchange of
data needed to implement the functionality in this document.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>there MUST be a means to allow the use of schemas not defined
by the needs of this document.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>Both types of schemas MUST use the same schema language.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The schemas MUST be able to express data elements with
identifying tags for the purpose of localization of the meaning
of the identifying tags.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.1.4.1</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST NOT prohibit an operator from granularly
assigning multiple types of access to data according to the
policies of the operator.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST provide an authentication mechanism and MUST
NOT prohibit an operator from granting types of access based on
authentication.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST provide an anonymous access mechanism that
may be turned on or off based on the policy of an operator.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.1.5</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST be capable of allowing machine parsable
requests and responses.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.1.6</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST be capable of allowing machine parsable
requests and responses.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.1.7.1</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST NOT require the aggregation of data to a
central repository, server, or entity.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST NOT require aggregation of data indexes or
hints to a central repository, server, or entity.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.1.8.1</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST provide a mechanism allowing a client to
determine if a query will be denied before the query is submitted
according to the appropriate policies of the operator.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.1.9.1</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST NOT require any Internet registry to
participate in any authentication system.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST NOT prohibit the participation by an
Internet registry in federated, distributed authentication
systems.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.1.10</I></P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P>The protocol MUST be capable of returning the following types
of non-result or error responses to all lookups and searches:</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>permission denied - a response indicating that the search or
lookup has failed due to insufficient authorization.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>not found - the desired results do not exist.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>insufficient resources - the search or lookup requires
resources that cannot be allocated.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.1.11.1</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST NOT prohibit a server from participating in
a query distribution system.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P><I>Section 3.1.12.1</I></P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>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.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>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.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.1.13.1</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>When issuing a referral, the protocol MUST be capable of
supplying a relay bag from the server to the client,</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>and the protocol MUST be capable of allowing the client to
submit this relay bag with a query to the referred server.
</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The use of the relay bag MUST be OPTIONAL.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST NOT make any assumptions regarding the
contents of the relay bag,</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>but the relay bag MUST be described using the schema language
of the protocol.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.2.1.1</I></P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P>The protocol MUST contain the following lookup functions:</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>Contact lookup given a unique reference to a contact of a
resource.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>Nameserver lookup given a fully-qualified host name or IP
address of a nameserver.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>Domain lookup given a fully-qualified domain name.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.2.2.1</I></P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P>The protocol MUST contain the following search functions:</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P>Domain name search given an exact match or reasonable subset
of a name.</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>This search SHOULD allow for parameters and qualifiers
designed to allow better matching of internationalized domain
names
</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>and SHOULD allow for both exact and partial matching within
the limits of internationalized domain names.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>This search SHOULD NOT require special transformations of
internationalized domain names to accommodate this search.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>This search MUST provide a means to narrow the search by names
delegated under a particular TLD.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>Domain registrant search by either exact name or partial name
match with the ability to narrow the search to registrants of a
particular TLD.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>Domains hosted by a nameserver given the fully-qualified host
name or IP address of a nameserver.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.2.3.1</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>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.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P>The schema MUST be capable of expressing the following
information for domains:</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>activation status</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>registrant</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>nameservers</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>technical, billing or other contacts</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>registry delegating the domain</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>registrar for the domain</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The data set for domains MUST be able to express arbitrary
textual information for extensions on an individual operator
basis.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.2.4</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The schemas used by the protocol SHOULD be capable of off-line
serialization.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.2.5.1</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>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.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P>When returning result sets, the protocol MUST be able to make
the following distinctions:</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>an empty result set.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>a result set truncated for the purpose of improving
performance bottlenecks.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>a result set truncated to comply with Section 3.1.1</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.2.6.1</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>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.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.2.7.1</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST NOT prohibit the distribution of data to
exclude any of the registry/registrar models stated in Section
2.1.1.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST be capable of expressing referrals and
entity references between the various models described in Section
2.1.1.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.2.8.1</I></P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P>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:</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>complete omission of the value without explanation</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>an indication that the value cannot be given due to
insufficient authorization</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>an indication that the value cannot be given due to privacy
constraints regardless of authorization status</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MAY define other values for this purpose, but
MUST define values defined above at a minimum.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 3.2.9</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The schema defining domain related resources MUST conform to
RFC 2277 [2] regarding textual data.
</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>In particular, the schema MUST be able to indicate the charset
and language in use with unstructured textual data.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST be able to support multiple representations
of contact data, with these representations complying with the
requirements in Section 3.2.3.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST be able to provide contact data in UTF-8
</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P STYLE="margin-bottom: 0cm">and SHOULD be able to provide
contact data in</P>
<P> US-ASCII, other character sets,
</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>and capable of specifying the language of the data.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 4.1</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>Entities accessing the service (users) MUST be provided a
mechanism for passing credentials to a server for the purpose of
authentication.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 4.2</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>The protocol MUST provide a mechanism capable of employing
many authentication types and capable of extension for future
authentication types.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 4.3</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>To distribute queries for search continuations and to issue
entity references, the protocol MUST provide a referral
mechanism.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR>
<TD COLSPAN=4 WIDTH=559 VALIGN=TOP>
<P><I>Section 4.4</I></P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>To distribute queries for search continuations and to issue
entity references, the protocol MUST define a common referral
scheme and syntax.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P><I>Section 4.5</I></P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>To provide structured queries and responses and allow for
minimal technological reinvention, the protocol MUST employ a
pre-existing schema language.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P><I>Section 4.6</I></P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
<TR VALIGN=TOP>
<TD WIDTH=303>
<P>To provide for machine consumption as well as human
consumption, the protocol MUST define schemas for use by the
structured queries and responses.</P>
</TD>
<TD WIDTH=41>
<P><BR>
</P>
</TD>
<TD WIDTH=39>
<P><BR>
</P>
</TD>
<TD WIDTH=152>
<P><BR>
</P>
</TD>
</TR>
</TBODY>
</TABLE>
<P STYLE="margin-bottom: 0cm"><BR>
</P>
</BODY>
</HTML>
--=_zak-3288-1048704565-0001-2--
More information about the Ietf-not43
mailing list