rfc4522.txt

samba最新软件


RFC 4522            LDAP: The Binary Encoding Option           June 2006


   Attributes of a syntax without the binary transfer requirement and
   having a defined LDAP-specific encoding SHOULD NOT be returned in the
   binary form.

   Attributes of a syntax without the binary transfer requirement and
   without a defined LDAP-specific encoding may be returned in the
   binary form or omitted from the result.

7.  Conflicting Requests

   A particular attribute could be explicitly requested by an attribute
   description and/or implicitly requested by the attribute descriptions
   of one or more of its supertypes, or by the special attribute
   description string "*".  If the binary option is present in at least
   one, but not all, of these attribute descriptions then the effect of
   the request with respect to binary transfer is implementation
   defined.

8.  Security Considerations

   When interpreting security-sensitive fields, and in particular fields
   used to grant or deny access, implementations MUST ensure that any
   matching rule comparisons are done on the underlying abstract value,
   regardless of the particular encoding used.

9.  IANA Considerations

   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
   attribute description option registry [BCP64] as indicated by the
   following template:

      Subject:
        Request for LDAP Attribute Description Option Registration
      Option Name: binary
      Family of Options: NO
      Person & email address to contact for further information:
        Steven Legg <[e-mail]>
      Specification: RFC 4522
      Author/Change Controller: IESG

10.  References

10.1.  Normative References

   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.





Legg                        Standards Track                     [Page 5]

RFC 4522            LDAP: The Binary Encoding Option           June 2006


   [BCP64]    Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
              Considerations for the Lightweight Directory Access
              Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): Technical Specification Road Map", RFC RFC 4510,
              June 2006.

   [RFC4511]  Sermersheim, J., "Lightweight Directory Access Protocol
              (LDAP): The Protocol", RFC 4511, June 2006.

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512, June
              2006.

   [RFC4517]  Legg, S., Ed., "Lightweight Directory Access Protocol
              (LDAP):  Syntaxes and Matching Rules", RFC 4517, June
              2006.

   [RFC4523]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP) Schema Definitions for X.509 Certificates", RFC
              4523, June 2006.

   [BER]      ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
              Information Technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER).

10.2.  Informative References

   [RFC2251]  Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
              Access Protocol (v3)", RFC 2251, December 1997.

   [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
              Protocol (v3): Technical Specification", RFC 3377,
              September 2002.

   [X.500]    ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001,
              Information technology - Open Systems Interconnection -
              The Directory:  Overview of concepts, models and services










Legg                        Standards Track                     [Page 6]

RFC 4522            LDAP: The Binary Encoding Option           June 2006


Author's Address

   Dr. Steven Legg
   eB2Bcom
   Suite 3, Woodhouse Corporate Centre
   935 Station Street
   Box Hill North, Victoria 3129
   AUSTRALIA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]







































Legg                        Standards Track                     [Page 7]

RFC 4522            LDAP: The Binary Encoding Option           June 2006


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
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Legg                        Standards Track                     [Page 8]