external/bsd/openldap/dist/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