mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-27 03:20:22 +08:00
284 lines
8.1 KiB
Plaintext
284 lines
8.1 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Network Working Group S. Legg
|
|||
|
Request for Comments: 3727 Adacel Technologies
|
|||
|
Category: Standards Track February 2004
|
|||
|
|
|||
|
|
|||
|
ASN.1 Module Definition for the
|
|||
|
LDAP and X.500 Component Matching Rules
|
|||
|
|
|||
|
Status of this Memo
|
|||
|
|
|||
|
This document specifies an Internet standards track protocol for the
|
|||
|
Internet community, and requests discussion and suggestions for
|
|||
|
improvements. Please refer to the current edition of the "Internet
|
|||
|
Official Protocol Standards" (STD 1) for the standardization state
|
|||
|
and status of this protocol. Distribution of this memo is unlimited.
|
|||
|
|
|||
|
Copyright Notice
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
|||
|
|
|||
|
Abstract
|
|||
|
|
|||
|
This document updates the specification of the component matching
|
|||
|
rules for Lightweight Directory Access Protocol (LDAP) and X.500
|
|||
|
directories (RFC3687) by collecting the Abstract Syntax Notation One
|
|||
|
(ASN.1) definitions of the component matching rules into an
|
|||
|
appropriately identified ASN.1 module so that other specifications
|
|||
|
may reference the component matching rule definitions from within
|
|||
|
their own ASN.1 modules.
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
The structure or data type of data held in an attribute of a
|
|||
|
Lightweight Directory Access Protocol (LDAP) [LDAP] or X.500 [X500]
|
|||
|
directory is described by the attribute's syntax. Attribute syntaxes
|
|||
|
range from simple data types, such as text string, integer, or
|
|||
|
boolean, to complex data types, for example, the syntaxes of the
|
|||
|
directory schema operational attributes. RFC 3687 [CMR] defines a
|
|||
|
generic way of matching user selected components in a directory
|
|||
|
attribute value of any arbitrarily complex attribute syntax.
|
|||
|
|
|||
|
This document updates RFC 3687 by collecting the Abstract Syntax
|
|||
|
Notation One (ASN.1) [ASN1] definitions of RFC 3687 into an
|
|||
|
appropriately identified ASN.1 module so that other specifications
|
|||
|
may reference these definitions from within their own ASN.1 modules.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Legg Standards Track [Page 1]
|
|||
|
|
|||
|
RFC 3727 Module for Component Matching February 2004
|
|||
|
|
|||
|
|
|||
|
2. Module Definition for Component Matching
|
|||
|
|
|||
|
ComponentMatching
|
|||
|
{iso(1) 2 36 79672281 xed(3) module(0) component-matching(4)}
|
|||
|
|
|||
|
-- Copyright (C) The Internet Society (2004). This version of
|
|||
|
-- this ASN.1 module is part of RFC 3727; see the RFC itself
|
|||
|
-- for full legal notices.
|
|||
|
|
|||
|
DEFINITIONS
|
|||
|
EXPLICIT TAGS
|
|||
|
EXTENSIBILITY IMPLIED ::= BEGIN
|
|||
|
|
|||
|
IMPORTS
|
|||
|
MATCHING-RULE,
|
|||
|
RelativeDistinguishedName
|
|||
|
FROM InformationFramework
|
|||
|
{joint-iso-itu-t ds(5) module(1)
|
|||
|
informationFramework(1) 4} ;
|
|||
|
|
|||
|
ComponentAssertion ::= SEQUENCE {
|
|||
|
component ComponentReference (SIZE(1..MAX)) OPTIONAL,
|
|||
|
useDefaultValues BOOLEAN DEFAULT TRUE,
|
|||
|
rule MATCHING-RULE.&id,
|
|||
|
value MATCHING-RULE.&AssertionType }
|
|||
|
|
|||
|
ComponentReference ::= UTF8String
|
|||
|
|
|||
|
ComponentFilter ::= CHOICE {
|
|||
|
item [0] ComponentAssertion,
|
|||
|
and [1] SEQUENCE OF ComponentFilter,
|
|||
|
or [2] SEQUENCE OF ComponentFilter,
|
|||
|
not [3] ComponentFilter }
|
|||
|
|
|||
|
componentFilterMatch MATCHING-RULE ::= {
|
|||
|
SYNTAX ComponentFilter
|
|||
|
ID { 1 2 36 79672281 1 13 2 } }
|
|||
|
|
|||
|
allComponentsMatch MATCHING-RULE ::= {
|
|||
|
ID { 1 2 36 79672281 1 13 6 } }
|
|||
|
|
|||
|
directoryComponentsMatch MATCHING-RULE ::= {
|
|||
|
ID { 1 2 36 79672281 1 13 7 } }
|
|||
|
|
|||
|
|
|||
|
-- Additional Useful Matching Rules --
|
|||
|
|
|||
|
rdnMatch MATCHING-RULE ::= {
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Legg Standards Track [Page 2]
|
|||
|
|
|||
|
RFC 3727 Module for Component Matching February 2004
|
|||
|
|
|||
|
|
|||
|
SYNTAX RelativeDistinguishedName
|
|||
|
ID { 1 2 36 79672281 1 13 3 } }
|
|||
|
|
|||
|
presentMatch MATCHING-RULE ::= {
|
|||
|
SYNTAX NULL
|
|||
|
ID { 1 2 36 79672281 1 13 5 } }
|
|||
|
|
|||
|
END
|
|||
|
|
|||
|
The InformationFramework ASN.1 module from which the MATCHING-RULE
|
|||
|
and RelativeDistinguishedName definitions are imported is defined in
|
|||
|
X.501 [X501].
|
|||
|
|
|||
|
The object identifiers used in this document have been assigned for
|
|||
|
use in specifying the component matching rules by Adacel
|
|||
|
Technologies, under an arc assigned to Adacel by Standards Australia.
|
|||
|
|
|||
|
3. Security Considerations
|
|||
|
|
|||
|
This document collects together the ASN.1 definitions of the
|
|||
|
component matching rules into an ASN.1 module, but does not modify
|
|||
|
those definitions in any way. See RFC 3687 [CMR] for the security
|
|||
|
considerations of using the component matching rules.
|
|||
|
|
|||
|
4. References
|
|||
|
|
|||
|
4.1. Normative References
|
|||
|
|
|||
|
[CMR] Legg, S., "Lightweight Directory Access Protocol (LDAP) and
|
|||
|
X.500 Component Matching Rules", RFC 3687, February 2004.
|
|||
|
|
|||
|
[X501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
|
|||
|
Information Technology - Open Systems Interconnection - The
|
|||
|
Directory: Models
|
|||
|
|
|||
|
[ASN1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
|
|||
|
Information technology - Abstract Syntax Notation One
|
|||
|
(ASN.1): Specification of basic notation
|
|||
|
|
|||
|
4.2. Informative References
|
|||
|
|
|||
|
[LDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access
|
|||
|
Protocol (v3): Technical Specification", RFC 3377, September
|
|||
|
2002.
|
|||
|
|
|||
|
[X500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
|
|||
|
Information Technology - Open Systems Interconnection - The
|
|||
|
Directory: Overview of concepts, models and services
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Legg Standards Track [Page 3]
|
|||
|
|
|||
|
RFC 3727 Module for Component Matching February 2004
|
|||
|
|
|||
|
|
|||
|
5. Author's Address
|
|||
|
|
|||
|
Steven Legg
|
|||
|
Adacel Technologies Ltd.
|
|||
|
250 Bay Street
|
|||
|
Brighton, Victoria 3186
|
|||
|
AUSTRALIA
|
|||
|
|
|||
|
Phone: +61 3 8530 7710
|
|||
|
Fax: +61 3 8530 7888
|
|||
|
EMail: steven.legg@adacel.com.au
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Legg Standards Track [Page 4]
|
|||
|
|
|||
|
RFC 3727 Module for Component Matching February 2004
|
|||
|
|
|||
|
|
|||
|
6. Full Copyright Statement
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2004). 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 currently provided by the
|
|||
|
Internet Society.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Legg Standards Track [Page 5]
|
|||
|
|