This form contains a series of questions that need to be answered. As you go about answering the questions, please keep the following things in mind:

• While it is not required that each question be answered at this time, all questions must have answers before the response is submitted to The Open Group for review and publication.
• Press the "Save" button at any time to save work in progress. Once the work has been saved, there is the option to continue editing if required.
• Many questions have instructions to assist in development of answers. They are marked with the indicator. Please look at the instructions carefully.
• Although HTML markup can be included in answers, this is not recommended apart from basic tags such as <p> and <br>, since incorrect markup could effect the format of other items in the document.
• Questions on this system should be addressed to the Conformance Statement manager at The Open Group.

Enter the name of the Organization that produced the implementation and the name of the author of the Conformance Statement.

1. LDAP 2000

Product Information

Environment Specification

Product registration applies to software products operating in a specific hardware or hardware/software environment.

A product may be registered in all members of a binary-compatible family of products on the basis of a single test report.

Answer the questions for each binary-compatible family. Alternately, provide the answers in the Appendix at the end of this document.

	Testing Environment	Binary-compatible Family	Portability Environment	Indicator of Compliance	Compliance Details
			None.	None.	Test Suite: Test Report:
			None.	None.	Test Suite: Test Report:
			None.	None.	Test Suite: Test Report:
			None.	None.	Test Suite: Test Report:
			None.	None.	Test Suite: Test Report:

Temporary Waivers

1.1 Directory: LDAP 2000

Question 1: Does the product support Extensible Matching?

Response

Yes   No

Rationale

IETF RFC 2251, Section 4.1.9 says that servers which support matching rules for use in the extensibleMatch search filter MUST list the matching rules they implement in subschema entries, using the matchingRules attributes.

IETF RFC 2252, Section 4.5 says that if the server supports the extensibleMatch, then the server MUST publish the relationship between the matching rules and attributes in the matchingRuleUse attribute.

IETF RFC 2252, Section 8 says that servers which implement the extensibleMatch filter SHOULD allow all the matching rules listed in this section to be used in the extensibleMatch.

The wording of these sections imply that support for Extensible Match is not mandatory.

Reference

IETF RFC 2251, Section 4.1.9, and IETF RFC 2252, Sections 4.5 and 8.

Question 2: Does the server send Notices of Disconnection?

Response

Yes   No

Rationale

IETF RFC 2251, Section 4.4.1 states that a notification of disconnection may be used by a server to advise a client that the server is about to close the connection due to an error condition.

This wording implies that servers need not send notices of disconnection.

Reference

IETF RFC 2251, Section 4.4.1.

Question 3: Does the server allow modification of subschema entries by clients?

Response

Yes   No

Rationale

IETF RFC 2252, Section 8.4 says that servers which allow subschema entries to be modified by clients MUST support certain matching rules, which are the equality matching rules for several of the subschema attributes.

This wording implies that whether a server allows clients to modify subschema entries is an option, and that there is a requirement to support certain matching rules that is contingent on that option.

Reference

IETF RFC 2252, Section 8.4.

Question 4: Does the server support validation of client certificates?

Response

Yes   No

Rationale

The SSL Version 3 specification, Section 7.6.4, says that a non-anonymous server can optionally request a certificate from the client, if appropriate, for the selected cipher suite.

This wording implies that whether a server can request (and by implication whether it can validate) client certificates is optional.

Reference

SSL Version 3 Specification, Section 7.6.4.

Question 5: Does the server support access to SSL Credentials via SASL EXTERNAL?

Response

Yes   No

Rationale

IETF RFC 2251, Section 4.2.2 says that the client can request that the server use authentication information from a lower layer protocol by using the SASL EXTERNAL mechanism. However, it is not clear whether this applies in the case where SSL is used in conjunction with the Port 636 mechanism.

In this situation, it seems best to make it optional for the server to allow the client to connect using SSL on port 636 (or another port dedicated by the server to LDAP over SSL) and then to authenticate using its SSL credentials via the SASL EXTERNAL mechanism.

Reference

IETF RFC 2251, Section 4.2.2.