[Ietf-not43] matrix in text
Rick Wesson
wessorh at ar.com
Tue Jul 1 22:02:20 EDT 2003
and thanks to andy here is the matrix in text... the html version
is available at http://wesson.us/crisp-matrix.html
please refer to the section when suggesting a fix.
-rick
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 | YES | | |
| 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 | YES | | |
| of network and transport layer | | | |
| standards as defined by the | | | |
| Internet Engineering Task Force. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST define one or | | | [iris] needs |
| more transport mechanisms for | | | additional text |
| mandatory implementation. | | | |
|------------------------------------------------------------------------|
| Section 3.1.3.1 |
|------------------------------------------------------------------------|
| The protocol MUST contain standard | YES | | |
| schemas for the exchange of data | | | |
| needed to implement the | | | |
| functionality in this document. | | | |
|------------------------------------+------+-----+----------------------|
| there MUST be a means to allow the | YES | | |
| use of schemas not defined by the | | | |
| needs of this document. | | | |
|------------------------------------+------+-----+----------------------|
| Both types of schemas MUST use the | YES | | |
| same schema language. | | | |
|------------------------------------+------+-----+----------------------|
| The schemas MUST be able to | YES | | |
| 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 | | | [iris] needs |
| operator from granularly assigning | | | additional |
| multiple types of access to data | | | definition |
| 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 | YES | | |
| allowing machine parsable requests | | | |
| and responses. | | | |
|------------------------------------------------------------------------|
| Section 3.1.6 |
|------------------------------------------------------------------------|
| The protocol MUST be capable of | YES | | |
| allowing machine parsable requests | | | |
| and responses. | | | |
|------------------------------------------------------------------------|
| Section 3.1.7.1 |
|------------------------------------------------------------------------|
| The protocol MUST NOT require the | YES | | |
| aggregation of data to a central | | | |
| repository, server, or entity. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST NOT require | YES | | |
| aggregation of data indexes or | | | |
| hints to a central repository, | | | |
| server, or entity. | | | |
|------------------------------------------------------------------------|
| Section 3.1.8.1 |
|------------------------------------------------------------------------|
| The protocol MUST provide a | NO | | |
| 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 | YES | | |
| Internet registry to participate | | | |
| in any authentication system. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST NOT prohibit the | YES | | |
| 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 | YES | | |
| indicating that the search or | | | |
| lookup has failed due to | | | |
| insufficient authorization. | | | |
|------------------------------------+------+-----+----------------------|
| not found - the desired results do | YES | | |
| 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 | YES | | |
| server from participating in a | | | |
| query distribution system. | | | |
|------------------------------------+------+-----+----------------------|
| Section 3.1.12.1 | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST provide a means | YES | | |
| 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 | YES | | |
| 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 | YES | | |
| protocol MUST be capable of | | | |
| supplying a relay bag from the | | | |
| server to the client, | | | |
|------------------------------------+------+-----+----------------------|
| and the protocol MUST be capable | YES | | |
| of allowing the client to submit | | | |
| this relay bag with a query to the | | | |
| referred server. | | | |
|------------------------------------+------+-----+----------------------|
| The use of the relay bag MUST be | YES | | |
| OPTIONAL. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST NOT make any | YES | | |
| assumptions regarding the contents | | | |
| of the relay bag, | | | |
|------------------------------------+------+-----+----------------------|
| but the relay bag MUST be | YES | | |
| 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 | YES | | |
| reference to a contact of a | | | |
| resource. | | | |
|------------------------------------+------+-----+----------------------|
| Nameserver lookup given a | YES | | |
| fully-qualified host name or IP | | | |
| address of a nameserver. | | | |
|------------------------------------+------+-----+----------------------|
| Domain lookup given a | YES | | |
| 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 | YES | | |
| parameters and qualifiers designed | | | |
| to allow better matching of | | | |
| internationalized domain names | | | |
|------------------------------------+------+-----+----------------------|
| and SHOULD allow for both exact | YES | | |
| and partial matching within the | | | |
| limits of internationalized domain | | | |
| names. | | | |
|------------------------------------+------+-----+----------------------|
| This search SHOULD NOT require | YES | | |
| special transformations of | | | |
| internationalized domain names to | | | |
| accommodate this search. | | | |
|------------------------------------+------+-----+----------------------|
| This search MUST provide a means | YES | | |
| to narrow the search by names | | | |
| delegated under a particular TLD. | | | |
|------------------------------------+------+-----+----------------------|
| Domain registrant search by either | YES | | |
| exact name or partial name match | | | |
| with the ability to narrow the | | | |
| search to registrants of a | | | |
| particular TLD. | | | |
|------------------------------------+------+-----+----------------------|
| Domains hosted by a nameserver | YES | | |
| given the fully-qualified host | | | |
| name or IP address of a | | | |
| nameserver. | | | |
|------------------------------------------------------------------------|
| Section 3.2.3.1 |
|------------------------------------------------------------------------|
| The data sets for contacts, | YES | | |
| 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 | YES | | |
|------------------------------------+------+-----+----------------------|
| registrant | YES | | |
|------------------------------------+------+-----+----------------------|
| nameservers | YES | | |
|------------------------------------+------+-----+----------------------|
| technical, billing or other | YES | | |
| contacts | | | |
|------------------------------------+------+-----+----------------------|
| registry delegating the domain | YES | | |
|------------------------------------+------+-----+----------------------|
| registrar for the domain | YES | | |
|------------------------------------+------+-----+----------------------|
| The data set for domains MUST be | YES | | |
| able to express arbitrary textual | | | |
| information for extensions on an | | | |
| individual operator basis. | | | |
|------------------------------------------------------------------------|
| Section 3.2.4 |
|------------------------------------------------------------------------|
| The schemas used by the protocol | YES | | |
| SHOULD be capable of off-line | | | |
| serialization. | | | |
|------------------------------------------------------------------------|
| Section 3.2.5.1 |
|------------------------------------------------------------------------|
| The protocol MUST contain a | YES | | |
| 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. | YES | | |
|------------------------------------+------+-----+----------------------|
| a result set truncated for the | YES | | |
| purpose of improving performance | | | |
| bottlenecks. | | | |
|------------------------------------+------+-----+----------------------|
| a result set truncated to comply | YES | | |
| with Section 3.1.1 | | | |
|------------------------------------------------------------------------|
| Section 3.2.6.1 |
|------------------------------------------------------------------------|
| The protocol MUST use the | YES | | |
| 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 | YES | | |
| distribution of data to exclude | | | |
| any of the registry/registrar | | | |
| models stated in Section 2.1.1. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST be capable of | YES | | |
| 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 | YES | | |
| without explanation | | | |
|------------------------------------+------+-----+----------------------|
| an indication that the value | YES | | |
| cannot be given due to | | | |
| insufficient authorization | | | |
|------------------------------------+------+-----+----------------------|
| an indication that the value | YES | | |
| cannot be given due to privacy | | | |
| constraints regardless of | | | |
| authorization status | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MAY define other | YES | | |
| values for this purpose, but MUST | | | |
| define values defined above at a | | | |
| minimum. | | | |
|------------------------------------------------------------------------|
| Section 3.2.9 |
|------------------------------------------------------------------------|
| The schema defining domain related | YES | | |
| resources MUST conform to RFC 2277 | | | |
| [2] regarding textual data. | | | |
|------------------------------------+------+-----+----------------------|
| In particular, the schema MUST be | YES | | |
| able to indicate the charset and | | | |
| language in use with unstructured | | | |
| textual data. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST be able to | YES | | |
| support multiple representations | | | |
| of contact data, with these | | | |
| representations complying with the | | | |
| requirements in Section 3.2.3. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST be able to | YES | | |
| provide contact data in UTF-8 | | | |
|------------------------------------+------+-----+----------------------|
| and SHOULD be able to provide | YES | | |
| contact data in | | | |
| | | | |
| US-ASCII, other character sets, | | | |
|------------------------------------+------+-----+----------------------|
| and capable of specifying the | YES | | |
| language of the data. | | | |
|------------------------------------------------------------------------|
| Section 4.1 |
|------------------------------------------------------------------------|
| Entities accessing the service | YES | | |
| (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 | YES | | |
| mechanism capable of employing | | | |
| many authentication types and | | | |
| capable of extension for future | | | |
| authentication types. | | | |
|------------------------------------------------------------------------|
| Section 4.3 |
|------------------------------------------------------------------------|
| To distribute queries for search | YES | | |
| continuations and to issue entity | | | |
| references, the protocol MUST | | | |
| provide a referral mechanism. | | | |
|------------------------------------------------------------------------|
| Section 4.4 |
|------------------------------------------------------------------------|
| To distribute queries for search | YES | | |
| continuations and to issue entity | | | |
| references, the protocol MUST | | | |
| define a common referral scheme | | | |
| and syntax. | | | |
|------------------------------------+------+-----+----------------------|
| Section 4.5 | | | |
|------------------------------------+------+-----+----------------------|
| To provide structured queries and | YES | | |
| responses and allow for minimal | | | |
| technological reinvention, the | | | |
| protocol MUST employ a | | | |
| pre-existing schema language. | | | |
|------------------------------------+------+-----+----------------------|
| Section 4.6 | | | |
|------------------------------------+------+-----+----------------------|
| To provide for machine consumption | YES | | |
| as well as human consumption, the | | | |
| protocol MUST define schemas for | | | |
| use by the structured queries and | | | |
| responses. | | | |
+------------------------------------------------------------------------+
-------------- next part --------------
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 | YES | | |
| 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 | YES | | |
| of network and transport layer | | | |
| standards as defined by the | | | |
| Internet Engineering Task Force. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST define one or | | | [iris] needs |
| more transport mechanisms for | | | additional text |
| mandatory implementation. | | | |
|------------------------------------------------------------------------|
| Section 3.1.3.1 |
|------------------------------------------------------------------------|
| The protocol MUST contain standard | YES | | |
| schemas for the exchange of data | | | |
| needed to implement the | | | |
| functionality in this document. | | | |
|------------------------------------+------+-----+----------------------|
| there MUST be a means to allow the | YES | | |
| use of schemas not defined by the | | | |
| needs of this document. | | | |
|------------------------------------+------+-----+----------------------|
| Both types of schemas MUST use the | YES | | |
| same schema language. | | | |
|------------------------------------+------+-----+----------------------|
| The schemas MUST be able to | YES | | |
| 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 | | | [iris] needs |
| operator from granularly assigning | | | additional |
| multiple types of access to data | | | definition |
| 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 | YES | | |
| allowing machine parsable requests | | | |
| and responses. | | | |
|------------------------------------------------------------------------|
| Section 3.1.6 |
|------------------------------------------------------------------------|
| The protocol MUST be capable of | YES | | |
| allowing machine parsable requests | | | |
| and responses. | | | |
|------------------------------------------------------------------------|
| Section 3.1.7.1 |
|------------------------------------------------------------------------|
| The protocol MUST NOT require the | YES | | |
| aggregation of data to a central | | | |
| repository, server, or entity. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST NOT require | YES | | |
| aggregation of data indexes or | | | |
| hints to a central repository, | | | |
| server, or entity. | | | |
|------------------------------------------------------------------------|
| Section 3.1.8.1 |
|------------------------------------------------------------------------|
| The protocol MUST provide a | NO | | |
| 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 | YES | | |
| Internet registry to participate | | | |
| in any authentication system. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST NOT prohibit the | YES | | |
| 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 | YES | | |
| indicating that the search or | | | |
| lookup has failed due to | | | |
| insufficient authorization. | | | |
|------------------------------------+------+-----+----------------------|
| not found - the desired results do | YES | | |
| 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 | YES | | |
| server from participating in a | | | |
| query distribution system. | | | |
|------------------------------------+------+-----+----------------------|
| Section 3.1.12.1 | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST provide a means | YES | | |
| 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 | YES | | |
| 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 | YES | | |
| protocol MUST be capable of | | | |
| supplying a relay bag from the | | | |
| server to the client, | | | |
|------------------------------------+------+-----+----------------------|
| and the protocol MUST be capable | YES | | |
| of allowing the client to submit | | | |
| this relay bag with a query to the | | | |
| referred server. | | | |
|------------------------------------+------+-----+----------------------|
| The use of the relay bag MUST be | YES | | |
| OPTIONAL. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST NOT make any | YES | | |
| assumptions regarding the contents | | | |
| of the relay bag, | | | |
|------------------------------------+------+-----+----------------------|
| but the relay bag MUST be | YES | | |
| 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 | YES | | |
| reference to a contact of a | | | |
| resource. | | | |
|------------------------------------+------+-----+----------------------|
| Nameserver lookup given a | YES | | |
| fully-qualified host name or IP | | | |
| address of a nameserver. | | | |
|------------------------------------+------+-----+----------------------|
| Domain lookup given a | YES | | |
| 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 | YES | | |
| parameters and qualifiers designed | | | |
| to allow better matching of | | | |
| internationalized domain names | | | |
|------------------------------------+------+-----+----------------------|
| and SHOULD allow for both exact | YES | | |
| and partial matching within the | | | |
| limits of internationalized domain | | | |
| names. | | | |
|------------------------------------+------+-----+----------------------|
| This search SHOULD NOT require | YES | | |
| special transformations of | | | |
| internationalized domain names to | | | |
| accommodate this search. | | | |
|------------------------------------+------+-----+----------------------|
| This search MUST provide a means | YES | | |
| to narrow the search by names | | | |
| delegated under a particular TLD. | | | |
|------------------------------------+------+-----+----------------------|
| Domain registrant search by either | YES | | |
| exact name or partial name match | | | |
| with the ability to narrow the | | | |
| search to registrants of a | | | |
| particular TLD. | | | |
|------------------------------------+------+-----+----------------------|
| Domains hosted by a nameserver | YES | | |
| given the fully-qualified host | | | |
| name or IP address of a | | | |
| nameserver. | | | |
|------------------------------------------------------------------------|
| Section 3.2.3.1 |
|------------------------------------------------------------------------|
| The data sets for contacts, | YES | | |
| 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 | YES | | |
|------------------------------------+------+-----+----------------------|
| registrant | YES | | |
|------------------------------------+------+-----+----------------------|
| nameservers | YES | | |
|------------------------------------+------+-----+----------------------|
| technical, billing or other | YES | | |
| contacts | | | |
|------------------------------------+------+-----+----------------------|
| registry delegating the domain | YES | | |
|------------------------------------+------+-----+----------------------|
| registrar for the domain | YES | | |
|------------------------------------+------+-----+----------------------|
| The data set for domains MUST be | YES | | |
| able to express arbitrary textual | | | |
| information for extensions on an | | | |
| individual operator basis. | | | |
|------------------------------------------------------------------------|
| Section 3.2.4 |
|------------------------------------------------------------------------|
| The schemas used by the protocol | YES | | |
| SHOULD be capable of off-line | | | |
| serialization. | | | |
|------------------------------------------------------------------------|
| Section 3.2.5.1 |
|------------------------------------------------------------------------|
| The protocol MUST contain a | YES | | |
| 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. | YES | | |
|------------------------------------+------+-----+----------------------|
| a result set truncated for the | YES | | |
| purpose of improving performance | | | |
| bottlenecks. | | | |
|------------------------------------+------+-----+----------------------|
| a result set truncated to comply | YES | | |
| with Section 3.1.1 | | | |
|------------------------------------------------------------------------|
| Section 3.2.6.1 |
|------------------------------------------------------------------------|
| The protocol MUST use the | YES | | |
| 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 | YES | | |
| distribution of data to exclude | | | |
| any of the registry/registrar | | | |
| models stated in Section 2.1.1. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST be capable of | YES | | |
| 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 | YES | | |
| without explanation | | | |
|------------------------------------+------+-----+----------------------|
| an indication that the value | YES | | |
| cannot be given due to | | | |
| insufficient authorization | | | |
|------------------------------------+------+-----+----------------------|
| an indication that the value | YES | | |
| cannot be given due to privacy | | | |
| constraints regardless of | | | |
| authorization status | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MAY define other | YES | | |
| values for this purpose, but MUST | | | |
| define values defined above at a | | | |
| minimum. | | | |
|------------------------------------------------------------------------|
| Section 3.2.9 |
|------------------------------------------------------------------------|
| The schema defining domain related | YES | | |
| resources MUST conform to RFC 2277 | | | |
| [2] regarding textual data. | | | |
|------------------------------------+------+-----+----------------------|
| In particular, the schema MUST be | YES | | |
| able to indicate the charset and | | | |
| language in use with unstructured | | | |
| textual data. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST be able to | YES | | |
| support multiple representations | | | |
| of contact data, with these | | | |
| representations complying with the | | | |
| requirements in Section 3.2.3. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST be able to | YES | | |
| provide contact data in UTF-8 | | | |
|------------------------------------+------+-----+----------------------|
| and SHOULD be able to provide | YES | | |
| contact data in | | | |
| | | | |
| US-ASCII, other character sets, | | | |
|------------------------------------+------+-----+----------------------|
| and capable of specifying the | YES | | |
| language of the data. | | | |
|------------------------------------------------------------------------|
| Section 4.1 |
|------------------------------------------------------------------------|
| Entities accessing the service | YES | | |
| (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 | YES | | |
| mechanism capable of employing | | | |
| many authentication types and | | | |
| capable of extension for future | | | |
| authentication types. | | | |
|------------------------------------------------------------------------|
| Section 4.3 |
|------------------------------------------------------------------------|
| To distribute queries for search | YES | | |
| continuations and to issue entity | | | |
| references, the protocol MUST | | | |
| provide a referral mechanism. | | | |
|------------------------------------------------------------------------|
| Section 4.4 |
|------------------------------------------------------------------------|
| To distribute queries for search | YES | | |
| continuations and to issue entity | | | |
| references, the protocol MUST | | | |
| define a common referral scheme | | | |
| and syntax. | | | |
|------------------------------------+------+-----+----------------------|
| Section 4.5 | | | |
|------------------------------------+------+-----+----------------------|
| To provide structured queries and | YES | | |
| responses and allow for minimal | | | |
| technological reinvention, the | | | |
| protocol MUST employ a | | | |
| pre-existing schema language. | | | |
|------------------------------------+------+-----+----------------------|
| Section 4.6 | | | |
|------------------------------------+------+-----+----------------------|
| To provide for machine consumption | YES | | |
| as well as human consumption, the | | | |
| protocol MUST define schemas for | | | |
| use by the structured queries and | | | |
| responses. | | | |
+------------------------------------------------------------------------+
More information about the Ietf-not43
mailing list