]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc3727.txt
Sync with HEAD
[openldap] / doc / rfc / rfc3727.txt
1
2
3
4
5
6
7 Network Working Group                                            S. Legg
8 Request for Comments: 3727                           Adacel Technologies
9 Category: Standards Track                                  February 2004
10
11
12                     ASN.1 Module Definition for the
13                 LDAP and X.500 Component Matching Rules
14
15 Status 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
23 Copyright Notice
24
25    Copyright (C) The Internet Society (2004).  All Rights Reserved.
26
27 Abstract
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
37 1.  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
58 Legg                        Standards Track                     [Page 1]
59 \f
60 RFC 3727             Module for Component Matching         February 2004
61
62
63 2.  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
114 Legg                        Standards Track                     [Page 2]
115 \f
116 RFC 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
136 3.  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
143 4.  References
144
145 4.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
158 4.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
170 Legg                        Standards Track                     [Page 3]
171 \f
172 RFC 3727             Module for Component Matching         February 2004
173
174
175 5.  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
226 Legg                        Standards Track                     [Page 4]
227 \f
228 RFC 3727             Module for Component Matching         February 2004
229
230
231 6.  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
245 Intellectual 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
269 Acknowledgement
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
282 Legg                        Standards Track                     [Page 5]
283 \f