summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3727.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3727.txt')
-rw-r--r--doc/rfc/rfc3727.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc3727.txt b/doc/rfc/rfc3727.txt
new file mode 100644
index 0000000..97c4126
--- /dev/null
+++ b/doc/rfc/rfc3727.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+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]
+