C.1.26. Section 4.12 (Extended Operation)
- Specified how values of Extended operations defined in terms of
ASN.1 are to be encoded.
- Added instructions on what Extended operation specifications
consist of.
- Added a recommendation that servers advertise supported Extended
operations.
C.1.27. Section 5.2 (Transfer Protocols)
- Moved referral-specific instructions into referral-related
sections.
C.1.28. Section 7 (Security Considerations)
- Reworded notes regarding SASL not protecting certain aspects of
the LDAP Bind messages.
- Noted that Servers are encouraged to prevent directory
modifications by clients that have authenticated anonymously
[RFC4513].
- Added a note regarding the possibility of changes to security
factors (authentication, authorization, and data confidentiality).
- Warned against following referrals that may have been injected in
the data stream.
- Noted that servers should protect information equally, whether in
an error condition or not, and mentioned matchedDN,
diagnosticMessage, and resultCodes specifically.
- Added a note regarding malformed and long encodings.
C.1.29. Appendix A (Complete ASN.1 Definition)
- Added "EXTENSIBILITY IMPLIED" to ASN.1 definition.
- Removed AttributeType. It is not used.
C.2. Changes Made to RFC 2830
This section summarizes the substantive changes made to Sections of
RFC 2830. Readers should consult [RFC4513] for summaries of changes
to other sections.
C.2.1. Section 2.3 (Response other than "success")
- Removed wording indicating that referrals can be returned from
StartTLS.
- Removed requirement that only a narrow set of result codes can be
returned. Some result codes are required in certain scenarios, but
any other may be returned if appropriate.
- Removed requirement that the ExtendedResponse.responseName MUST be
present. There are circumstances where this is impossible, and
requiring this is at odds with language in Section 4.12.
C.2.1. Section 4 (Closing a TLS Connection)
- Reworded most of this section to align with definitions of the
LDAP protocol layers.
- Removed instructions on abrupt closure as this is covered in other
areas of the document (specifically, Section 5.3)
C.3. Changes Made to RFC 3771
- Rewrote to fit into this document. In general, semantics were
preserved. Supporting and background language seen as redundant
due to its presence in this document was omitted.
- Specified that Intermediate responses to a request may be of
different types, and one of the response types may be specified to
have no response value.
Editor’s Address
Jim Sermersheim
Novell, Inc.
1800 South Novell Place
Provo, Utah 84606, USA
Phone: +1 801 861-3088
EMail: jimse@novell.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).