1
2
3
4
5
6
7Network Working Group                                            S. Legg
8Request for Comments: 3727                           Adacel Technologies
9Category: Standards Track                                  February 2004
10
11
12                    ASN.1 Module Definition for the
13                LDAP and X.500 Component Matching Rules
14
15Status of this Memo
16
17   This document specifies an Internet standards track protocol for the
18   Internet community, and requests discussion and suggestions for
19   improvements.  Please refer to the current edition of the "Internet
20   Official Protocol Standards" (STD 1) for the standardization state
21   and status of this protocol.  Distribution of this memo is unlimited.
22
23Copyright Notice
24
25   Copyright (C) The Internet Society (2004).  All Rights Reserved.
26
27Abstract
28
29   This document updates the specification of the component matching
30   rules for Lightweight Directory Access Protocol (LDAP) and X.500
31   directories (RFC3687) by collecting the Abstract Syntax Notation One
32   (ASN.1) definitions of the component matching rules into an
33   appropriately identified ASN.1 module so that other specifications
34   may reference the component matching rule definitions from within
35   their own ASN.1 modules.
36
371.  Introduction
38
39   The structure or data type of data held in an attribute of a
40   Lightweight Directory Access Protocol (LDAP) [LDAP] or X.500 [X500]
41   directory is described by the attribute's syntax.  Attribute syntaxes
42   range from simple data types, such as text string, integer, or
43   boolean, to complex data types, for example, the syntaxes of the
44   directory schema operational attributes.  RFC 3687 [CMR] defines a
45   generic way of matching user selected components in a directory
46   attribute value of any arbitrarily complex attribute syntax.
47
48   This document updates RFC 3687 by collecting the Abstract Syntax
49   Notation One (ASN.1) [ASN1] definitions of RFC 3687 into an
50   appropriately identified ASN.1 module so that other specifications
51   may reference these definitions from within their own ASN.1 modules.
52
53
54
55
56
57
58Legg                        Standards Track                     [Page 1]
59
60RFC 3727             Module for Component Matching         February 2004
61
62
632.  Module Definition for Component Matching
64
65   ComponentMatching
66       {iso(1) 2 36 79672281 xed(3) module(0) component-matching(4)}
67
68   --  Copyright (C) The Internet Society (2004).  This version of
69   --  this ASN.1 module is part of RFC 3727; see the RFC itself
70   --  for full legal notices.
71
72   DEFINITIONS
73   EXPLICIT TAGS
74   EXTENSIBILITY IMPLIED ::= BEGIN
75
76   IMPORTS
77       MATCHING-RULE,
78       RelativeDistinguishedName
79           FROM InformationFramework
80               {joint-iso-itu-t ds(5) module(1)
81                   informationFramework(1) 4} ;
82
83   ComponentAssertion ::= SEQUENCE {
84       component         ComponentReference (SIZE(1..MAX)) OPTIONAL,
85       useDefaultValues  BOOLEAN DEFAULT TRUE,
86       rule              MATCHING-RULE.&id,
87       value             MATCHING-RULE.&AssertionType }
88
89   ComponentReference ::= UTF8String
90
91   ComponentFilter ::= CHOICE {
92       item  [0] ComponentAssertion,
93       and   [1] SEQUENCE OF ComponentFilter,
94       or    [2] SEQUENCE OF ComponentFilter,
95       not   [3] ComponentFilter }
96
97   componentFilterMatch MATCHING-RULE ::= {
98       SYNTAX  ComponentFilter
99       ID      { 1 2 36 79672281 1 13 2 } }
100
101   allComponentsMatch MATCHING-RULE ::= {
102       ID      { 1 2 36 79672281 1 13 6 } }
103
104   directoryComponentsMatch MATCHING-RULE ::= {
105       ID      { 1 2 36 79672281 1 13 7 } }
106
107
108   -- Additional Useful Matching Rules --
109
110   rdnMatch MATCHING-RULE ::= {
111
112
113
114Legg                        Standards Track                     [Page 2]
115
116RFC 3727             Module for Component Matching         February 2004
117
118
119       SYNTAX  RelativeDistinguishedName
120       ID      { 1 2 36 79672281 1 13 3 } }
121
122   presentMatch MATCHING-RULE ::= {
123       SYNTAX  NULL
124       ID      { 1 2 36 79672281 1 13 5 } }
125
126   END
127
128   The InformationFramework ASN.1 module from which the MATCHING-RULE
129   and RelativeDistinguishedName definitions are imported is defined in
130   X.501 [X501].
131
132   The object identifiers used in this document have been assigned for
133   use in specifying the component matching rules by Adacel
134   Technologies, under an arc assigned to Adacel by Standards Australia.
135
1363.  Security Considerations
137
138   This document collects together the ASN.1 definitions of the
139   component matching rules into an ASN.1 module, but does not modify
140   those definitions in any way.  See RFC 3687 [CMR] for the security
141   considerations of using the component matching rules.
142
1434.  References
144
1454.1.  Normative References
146
147   [CMR]   Legg, S., "Lightweight Directory Access Protocol (LDAP) and
148           X.500 Component Matching Rules", RFC 3687, February 2004.
149
150   [X501]  ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
151           Information Technology - Open Systems Interconnection - The
152           Directory: Models
153
154   [ASN1]  ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
155           Information technology - Abstract Syntax Notation One
156           (ASN.1): Specification of basic notation
157
1584.2.  Informative References
159
160   [LDAP]  Hodges, J. and R. Morgan, "Lightweight Directory Access
161           Protocol (v3): Technical Specification", RFC 3377, September
162           2002.
163
164   [X500]  ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
165           Information Technology - Open Systems Interconnection - The
166           Directory: Overview of concepts, models and services
167
168
169
170Legg                        Standards Track                     [Page 3]
171
172RFC 3727             Module for Component Matching         February 2004
173
174
1755.  Author's Address
176
177   Steven Legg
178   Adacel Technologies Ltd.
179   250 Bay Street
180   Brighton, Victoria 3186
181   AUSTRALIA
182
183   Phone: +61 3 8530 7710
184   Fax:   +61 3 8530 7888
185   EMail: steven.legg@adacel.com.au
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226Legg                        Standards Track                     [Page 4]
227
228RFC 3727             Module for Component Matching         February 2004
229
230
2316.  Full Copyright Statement
232
233   Copyright (C) The Internet Society (2004).  This document is subject
234   to the rights, licenses and restrictions contained in BCP 78 and
235   except as set forth therein, the authors retain all their rights.
236
237   This document and the information contained herein are provided on an
238   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
239   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
240   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
241   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
242   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
243   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
244
245Intellectual Property
246
247   The IETF takes no position regarding the validity or scope of any
248   Intellectual Property Rights or other rights that might be claimed
249   to pertain to the implementation or use of the technology
250   described in this document or the extent to which any license
251   under such rights might or might not be available; nor does it
252   represent that it has made any independent effort to identify any
253   such rights.  Information on the procedures with respect to
254   rights in RFC documents can be found in BCP 78 and BCP 79.
255
256   Copies of IPR disclosures made to the IETF Secretariat and any
257   assurances of licenses to be made available, or the result of an
258   attempt made to obtain a general license or permission for the use
259   of such proprietary rights by implementers or users of this
260   specification can be obtained from the IETF on-line IPR repository
261   at http://www.ietf.org/ipr.
262
263   The IETF invites any interested party to bring to its attention
264   any copyrights, patents or patent applications, or other
265   proprietary rights that may cover technology that may be required
266   to implement this standard.  Please address the information to the
267   IETF at ietf-ipr@ietf.org.
268
269Acknowledgement
270
271   Funding for the RFC Editor function is currently provided by the
272   Internet Society.
273
274
275
276
277
278
279
280
281
282Legg                        Standards Track                     [Page 5]
283
284