diff --git a/doc/drafts/draft-leach-uuids-guids-01.txt b/doc/drafts/draft-leach-uuids-guids-xx.txt
similarity index 100%
rename from doc/drafts/draft-leach-uuids-guids-01.txt
rename to doc/drafts/draft-leach-uuids-guids-xx.txt
diff --git a/doc/drafts/draft-legg-ldap-acm-admin-xx.txt b/doc/drafts/draft-legg-ldap-acm-admin-xx.txt
new file mode 100644
index 0000000000000000000000000000000000000000..a4d4660823c118831a0c7381353a2631f1c6f43f
--- /dev/null
+++ b/doc/drafts/draft-legg-ldap-acm-admin-xx.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+INTERNET-DRAFT S. Legg
+draft-legg-ldap-acm-admin-01.txt Adacel Technologies
+Intended Category: Standards Track September 18, 2002
+
+
+ Access Control Administration in LDAP
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Distribution of this document is unlimited. Comments should be sent
+ to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
+ author.
+
+ This Internet-Draft expires on 18 March 2003.
+
+
+1. Abstract
+
+ This document adapts the X.500 directory administrative model, as it
+ pertains to access control administration, for use by the Lightweight
+ Directory Access Protocol. The administrative model partitions the
+ Directory Information Tree for various aspects of directory data
+ administration, e.g. subschema, access control and collective
+ attributes. This document provides the particular definitions that
+ support access control administration, but does not define a
+ particular access control scheme.
+
+
+
+Legg Expires 18 March 2003 [Page 1]
+
+INTERNET-DRAFT Access Control Administration September 18, 2002
+
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+2. Table of Contents
+
+ 1. Abstract .................................................... 1
+ 2. Table of Contents ........................................... 2
+ 3. Introduction ................................................ 2
+ 4. Access Control Administrative Areas ......................... 3
+ 5. Access Control Scheme Indication ............................ 3
+ 6. Access Control Information .................................. 4
+ 7. Access Control Subentries ................................... 4
+ 8. Applicable Access Control Information ....................... 5
+ 9. Security Considerations ..................................... 5
+ 10. Acknowledgements ........................................... 6
+ 11. Normative References ....................................... 6
+ 12. Informative References ..................................... 6
+ 13. Copyright Notice ........................................... 7
+ 14. Author's Address ........................................... 7
+
+
+3. Introduction
+
+ This document adapts the X.500 directory administrative model [X501],
+ as it pertains to access control administration, for use by the
+ Lightweight Directory Access Protocol (LDAP) [RFC2251].
+
+ The administrative model [ADMIN] partitions the Directory Information
+ Tree (DIT) for various aspects of directory data administration, e.g.
+ subschema, access control and collective attributes. The parts of
+ the administrative model that apply to every aspect of directory data
+ administration are described in [ADMIN]. This document describes the
+ administrative framework for access control.
+
+ An access control scheme describes the means by which access to
+ directory information, and potentially to access rights themselves,
+ may be controlled. This document describes the framework for
+ employing access control schemes but does not define a particular
+ access control scheme. Two access control schemes known as Basic
+ Access Control and Simplified Access Control are defined by [BAC].
+ Other access control schemes MAY be defined by other documents.
+
+ Schema definitions are provided using LDAP description formats
+ [RFC2252]. Note that the LDAP descriptions have been rendered with
+ additional white-space and line breaks for the sake of readability.
+
+
+
+
+Legg Expires 18 March 2003 [Page 2]
+
+INTERNET-DRAFT Access Control Administration September 18, 2002
+
+
+ This document is derived from, and duplicates substantial portions
+ of, Sections 4 and 8 of [X501].
+
+
+4. Access Control Administrative Areas
+
+ The specific administrative area [ADMIN] for access control is termed
+ an Access Control Specific Area (ACSA). The root of the ACSA is
+ termed an Access Control Specific Point (ACSP) and is represented in
+ the DIT by an administrative entry [ADMIN] which includes
+ accessControlSpecificArea as a value of its administrativeRole
+ operational attribute [SUBENTRY].
+
+ An ACSA MAY be partitioned into subtrees termed inner administrative
+ areas [ADMIN]. Each such inner area is termed an Access Control
+ Inner Area (ACIA). The root of the ACIA is termed an Access Control
+ Inner Point (ACIP) and is represented in the DIT by an administrative
+ entry which includes accessControlInnerArea as a value of its
+ administrativeRole operational attribute.
+
+ An administrative entry can never be both an ACSP and an ACIP. The
+ corresponding values can therefore never be present simultaneously in
+ the administrativeRole attribute.
+
+ Each entry necessarily falls within one and only one ACSA. Each such
+ entry may also fall within one or more ACIAs nested inside the ACSA
+ containing the entry.
+
+ An ACSP or ACIP has zero, one or more subentries that contain Access
+ Control Information (ACI).
+
+
+5. Access Control Scheme Indication
+
+ The access control scheme (e.g. Basic Access Control [BAC]) in force
+ in an ACSA is indicated by the accessControlScheme operational
+ attribute contained in the administrative entry for the relevant
+ ACSP.
+
+ The LDAP description [RFC2252] for the accessControlScheme
+ operational attribute is:
+
+ ( 2.5.24.1 NAME 'accessControlScheme'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE USAGE directoryOperation )
+
+ An access control scheme conforming to the access control framework
+
+
+
+Legg Expires 18 March 2003 [Page 3]
+
+INTERNET-DRAFT Access Control Administration September 18, 2002
+
+
+ described in this document MUST define a distinct OBJECT IDENTIFIER
+ value to identify it through the accessControlScheme attribute.
+
+ Only administrative entries for ACSPs are permitted to contain an
+ accessControlScheme attribute. If the accessControlScheme attribute
+ is absent from a given ACSP, the access control scheme in force in
+ the corresponding ACSA, and its effect on operations, results and
+ errors, is implementation defined.
+
+ Any entry or subentry in an ACSA is permitted to contain ACI if and
+ only if such ACI is permitted by, and consistent with, the access
+ control scheme identified by the value of the accessControlScheme
+ attribute of the ACSP.
+
+
+6. Access Control Information
+
+ There are three categories of Access Control Information (ACI):
+ entry, subentry and prescriptive.
+
+ Entry ACI applies to only the entry or subentry in which it appears,
+ and the contents thereof. Subject to the access control scheme, any
+ entry or subentry MAY hold entry ACI.
+
+ Subentry ACI applies to only the subentries of the administrative
+ entry in which it appears. Subject to the access control scheme, any
+ administrative entry, for any aspect of administration, MAY hold
+ subentry ACI.
+
+ Prescriptive ACI applies to all the entries within a subtree or
+ subtree refinement of an administrative area (either an ACSA or an
+ ACIA), as defined by the subtreeSpecification attribute of the
+ subentry in which it appears. Prescriptive ACI is only permitted in
+ subentries of an ACSP or ACIP. Prescriptive ACI in the subentries of
+ a particular administrative point never applies to the same or any
+ other subentry of that administrative point, but does apply to the
+ subentries of subordinate administrative points, where those
+ subentries are within the subtree or subtree refinement.
+
+
+7. Access Control Subentries
+
+ Each subentry which contains prescriptive ACI MUST have
+ accessControlSubentry as a value of its objectClass attribute. Such
+ a subentry is called an access control subentry.
+
+ The LDAP description [RFC2252] for the accessControlSubentry
+ auxiliary object class is:
+
+
+
+Legg Expires 18 March 2003 [Page 4]
+
+INTERNET-DRAFT Access Control Administration September 18, 2002
+
+
+ ( 2.5.17.1 NAME 'accessControlSubentry' AUXILIARY )
+
+ A subentry of this object class MUST contain at least one
+ prescriptive ACI attribute of a type consistent with the value of the
+ accessControlScheme attribute of the corresponding ACSP.
+
+ The subtree or subtree refinement for an access control subentry is
+ termed a Directory Access Control Domain (DACD). A DACD can contain
+ zero entries, and can encompass entries that have not yet been added
+ to the DIT, but does not extend beyond the scope of the ACSA or ACIA
+ with which it is associated.
+
+ Since a subtreeSpecification may define a subtree refinement, DACDs
+ within a given ACSA may arbitrarily overlap.
+
+
+8. Applicable Access Control Information
+
+ Although particular items of ACI may specify attributes or values as
+ the protected items, ACI is logically associated with entries.
+
+ The ACI that is considered in access control decisions regarding an
+ entry includes:
+
+ (1) Entry ACI from that particular entry.
+
+ (2) Prescriptive ACI from access control subentries whose DACDs
+ contain the entry. Each of these access control subentries is
+ necessarily either a subordinate of the ACSP for the ACSA
+ containing the entry, or a subordinate of the ACIP for an ACIA
+ that contains the entry.
+
+ The ACI that is considered in access control decisions regarding a
+ subentry includes:
+
+ (1) Entry ACI from that particular subentry.
+
+ (2) Prescriptive ACI from access control subentries whose DACDs
+ contain the subentry, excluding those belonging to the same
+ administrative point as the subentry for which the decision is
+ being made.
+
+ (3) Subentry ACI from the administrative point associated with the
+ subentry.
+
+
+9. Security Considerations
+
+
+
+
+Legg Expires 18 March 2003 [Page 5]
+
+INTERNET-DRAFT Access Control Administration September 18, 2002
+
+
+ This document defines a framework for employing an access control
+ scheme, i.e. the means by which access to directory information and
+ potentially to access rights themselves may be controlled, but does
+ not itself define any particular access control scheme. The degree
+ of protection provided, and any security risks, are determined by the
+ provisions of the access control schemes (defined elsewhere) making
+ use of this framework.
+
+ Security considerations that apply to directory administration in
+ general [ADMIN] also apply to access control administration.
+
+
+10. Acknowledgements
+
+ This document is derived from, and duplicates substantial portions
+ of, Sections 4 and 8 of [X501].
+
+
+11. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [ADMIN] Legg, S., "Directory Administrative Model in LDAP",
+ draft-legg-ldap-admin-xx.txt, a work in progress,
+ September 2002.
+
+ [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
+ draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
+ August 2002.
+
+
+12. Informative References
+
+ [BAC] Legg, S., "Basic and Simplified Access Control in LDAP",
+ draft-legg-ldap-acm-bac-xx.txt, a work in progress,
+ September 2002.
+
+ [COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
+ draft-zeilenga-ldap-collective-xx.txt, a work in progress,
+ August 2002.
+
+
+
+Legg Expires 18 March 2003 [Page 6]
+
+INTERNET-DRAFT Access Control Administration September 18, 2002
+
+
+ [X501] ITU-T Recommendation X.501 (02/2001), Information
+ technology - Open Systems Interconnection - The Directory:
+ Models
+
+
+13. Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+
+14. Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 405-409 Ferntree Gully Road
+ Mount Waverley, Victoria 3149
+ AUSTRALIA
+
+ Phone: +61 3 9451 2107
+ Fax: +61 3 9541 2121
+ EMail: steven.legg@adacel.com.au
+
+
+15. Appendix A - Changes From Previous Drafts
+
+
+
+Legg Expires 18 March 2003 [Page 7]
+
+INTERNET-DRAFT Access Control Administration September 18, 2002
+
+
+15.1 Changes in Draft 01
+
+ Section 4 has been extracted to become a separate Internet draft,
+ draft-legg-ldap-admin-00.txt. The subsections of Section 5 have
+ become the new Sections 4 to 8. Editorial changes have been made to
+ accommodate this split. No technical changes have been introduced.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 18 March 2003 [Page 8]
+
diff --git a/doc/drafts/draft-legg-ldap-admin-xx.txt b/doc/drafts/draft-legg-ldap-admin-xx.txt
new file mode 100644
index 0000000000000000000000000000000000000000..1ccd27c48c9317d56cbe87484745277baec943f7
--- /dev/null
+++ b/doc/drafts/draft-legg-ldap-admin-xx.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+INTERNET-DRAFT S. Legg
+draft-legg-ldap-admin-00.txt Adacel Technologies
+Intended Category: Standards Track September 18, 2002
+
+
+ Directory Administrative Model in LDAP
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Distribution of this document is unlimited. Comments should be sent
+ to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
+ author.
+
+ This Internet-Draft expires on 18 March 2003.
+
+
+1. Abstract
+
+ This document adapts the X.500 directory administrative model for use
+ by the Lightweight Directory Access Protocol. The administrative
+ model partitions the Directory Information Tree for various aspects
+ of directory data administration, e.g. subschema, access control and
+ collective attributes. The generic framework that applies to every
+ aspect of administration is described in this document. The
+ definitions that apply for a specific aspect of administration, e.g.
+ access control administration, are described in other documents.
+
+
+
+Legg Expires 18 March 2003 [Page 1]
+
+INTERNET-DRAFT Directory Administrative Model September 18, 2002
+
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+2. Table of Contents
+
+ 1. Abstract .................................................... 1
+ 2. Table of Contents ........................................... 2
+ 3. Introduction ................................................ 2
+ 4. Administrative Areas ........................................ 2
+ 5. Autonomous Administrative Areas ............................. 3
+ 6. Specific Administrative Areas ............................... 3
+ 7. Inner Administrative Areas .................................. 4
+ 8. Administrative Entries ...................................... 5
+ 9. Security Considerations ..................................... 5
+ 10. Acknowledgements ........................................... 5
+ 11. Normative References ....................................... 5
+ 12. Informative References ..................................... 6
+ 13. Copyright Notice ........................................... 6
+ 14. Author's Address ........................................... 6
+
+
+3. Introduction
+
+ This document adapts the X.500 directory administrative model [X501]
+ for use by the Lightweight Directory Access Protocol (LDAP)
+ [RFC2251]. The administrative model partitions the Directory
+ Information Tree (DIT) for various aspects of directory data
+ administration, e.g. subschema, access control and collective
+ attributes. This document provides the definitions for the generic
+ parts of the administrative model that apply to every aspect of
+ directory data administration.
+
+ Sections 4 to 8, in conjunction with [SUBENTRY], describe the means
+ by which administrative authority is aportioned and exercised in the
+ DIT.
+
+ Aspects of administration that conform to the administrative model
+ described in this document are detailed elsewhere, e.g. access
+ control administration is described in [ACA] and collective attribute
+ administration is described in [COLLECT].
+
+ This document is derived from, and duplicates substantial portions
+ of, Sections 4 and 8 of [X501].
+
+
+4. Administrative Areas
+
+
+
+Legg Expires 18 March 2003 [Page 2]
+
+INTERNET-DRAFT Directory Administrative Model September 18, 2002
+
+
+ An administrative area is a subtree of the DIT considered from the
+ perspective of administration. The root entry of the subtree is an
+ administrative point. An administrative point is represented by an
+ entry holding an administrativeRole attribute [SUBENTRY]. The values
+ of this attribute identify the kind of administrative point.
+
+
+5. Autonomous Administrative Areas
+
+ The DIT may be partitioned into one or more non-overlapping subtrees
+ termed autonomous administrative areas. It is expected that the
+ entries in an autonomous administrative area are all administered by
+ the same administrative authority.
+
+ An administrative authority may be responsible for several autonomous
+ administrative areas in separated parts of the DIT but it SHOULD NOT
+ arbitrarily partition the collection of entries under its control
+ into autonomous administrative areas (thus creating adjacent
+ autonomous areas administered by the same authority).
+
+ The root entry of an autonomous administrative area's subtree is
+ called an autonomous administrative point. An autonomous
+ administrative area extends from its autonomous administrative point
+ downwards until another autonomous administrative point is
+ encountered, at which point another autonomous administrative area
+ begins.
+
+
+6. Specific Administrative Areas
+
+ Entries in an administrative area may be considered in terms of a
+ specific administrative function. When viewed in this context, an
+ administrative area is termed a specific administrative area.
+
+ Examples of specific administrative areas are subschema specific
+ administrative areas, access control specific areas and collective
+ attribute specific areas.
+
+ An autonomous administrative area may be considered as implicitly
+ defining a single specific administrative area for each specific
+ aspect of administration. In this case, there is a precise
+ correspondence between each such specific administrative area and the
+ autonomous administrative area.
+
+ Alternatively, for each specific aspect of administration, the
+ autonomous administrative area may be partitioned into
+ non-overlapping specific administrative areas.
+
+
+
+
+Legg Expires 18 March 2003 [Page 3]
+
+INTERNET-DRAFT Directory Administrative Model September 18, 2002
+
+
+ If so partitioned for a particular aspect of administration, each
+ entry of the autonomous administrative area is contained in one and
+ only one specific administrative area for that aspect, i.e. specific
+ administrative areas do not overlap.
+
+ The root entry of a specific administrative area's subtree is called
+ a specific administrative point. A specific administrative area
+ extends from its specific administrative point downwards until
+ another specific administrative point of the same administrative
+ aspect is encountered, at which point another specific administrative
+ area begins. Specific administrative areas are always bounded by the
+ autonomous administrative area they partition.
+
+ Where an autonomous administrative area is not partitioned for a
+ specific aspect of administration, the specific administrative area
+ for that aspect coincides with the autonomous administrative area.
+ In this case, the autonomous administrative point is also the
+ specific administrative point for this aspect of administration. A
+ particular administrative point may be the root of an autonomous
+ administrative area and may be the root of one or more specific
+ administrative areas for different aspects of administration.
+
+ It is not necessary for an administrative point to represent each
+ specific aspect of administrative authority. For example, there
+ might be an administrative point, subordinate to the root of the
+ autonomous administrative area, which is used for access control
+ purposes only.
+
+
+7. Inner Administrative Areas
+
+ For some aspects of administration, e.g. access control or collective
+ attributes, inner administrative areas may be defined within the
+ specific administrative areas, to allow a limited form of delegation,
+ or for administrative or operational convenience.
+
+ An inner administrative area may be nested within another inner
+ administrative area. The rules for nested inner areas are defined as
+ part of the definition of the specific administrative aspect for
+ which they are allowed.
+
+ The root entry of an inner administrative area's subtree is called an
+ inner administrative point. An inner administrative area (within a
+ specific administrative area) extends from its inner administrative
+ point downwards until a specific administrative point of the same
+ administrative aspect is encountered. An inner administrative area
+ is bounded by the specific administrative area within which it is
+ defined.
+
+
+
+Legg Expires 18 March 2003 [Page 4]
+
+INTERNET-DRAFT Directory Administrative Model September 18, 2002
+
+
+8. Administrative Entries
+
+ An entry located at an administrative point is an administrative
+ entry. Administrative entries MAY have subentries [SUBENTRY] as
+ immediate subordinates. The administrative entry and its associated
+ subentries are used to control the entries encompassed by the
+ associated administrative area. Where inner administrative areas are
+ used, the scopes of these areas may overlap. Therefore, for each
+ specific aspect of administrative authority, a definition is required
+ of the method of combination of administrative information when it is
+ possible for entries to be included in more than one subtree or
+ subtree refinement associated with an inner area defined for that
+ aspect.
+
+
+9. Security Considerations
+
+ This document defines a generic framework for employing policy of
+ various kinds, e.g. access controls, to entries in the DIT. Such
+ policy can only be correctly enforced at a directory server holding a
+ replica of a portion of the DIT if the administrative entries for
+ administrative areas that overlap the portion of the DIT being
+ replicated, and the subentries of those administrative entries
+ relevant to any aspect of policy that is required to be enforced at
+ the replica, are included in the replicated information.
+
+ Administrative entries and subentries SHOULD be protected from
+ unauthorized examination or changes by appropriate access controls.
+
+
+10. Acknowledgements
+
+ This document is derived from, and duplicates substantial portions
+ of, Sections 4 and 8 of [X501].
+
+
+11. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
+ draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
+ August 2002.
+
+
+
+
+Legg Expires 18 March 2003 [Page 5]
+
+INTERNET-DRAFT Directory Administrative Model September 18, 2002
+
+
+12. Informative References
+
+ [ACA] Legg, S., "Access Control Administration in LDAP",
+ draft-legg-ldap-acm-admin-xx.txt, a work in progress,
+ September 2002.
+
+ [COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
+ draft-zeilenga-ldap-collective-xx.txt, a work in progress,
+ August 2002.
+
+ [X501] ITU-T Recommendation X.501 (02/2001), Information
+ technology - Open Systems Interconnection - The Directory:
+ Models
+
+
+13. Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+
+14. Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+
+
+
+Legg Expires 18 March 2003 [Page 6]
+
+INTERNET-DRAFT Directory Administrative Model September 18, 2002
+
+
+ 405-409 Ferntree Gully Road
+ Mount Waverley, Victoria 3149
+ AUSTRALIA
+
+ Phone: +61 3 9451 2107
+ Fax: +61 3 9541 2121
+ EMail: steven.legg@adacel.com.au
+
+
+15. Appendix A - Changes From Previous Drafts
+
+ This document reproduces Section 4 from
+ draft-legg-ldap-acm-admin-00.txt as a standalone document. All
+ changes made are purely editorial. No technical changes have been
+ introduced.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 18 March 2003 [Page 7]
+
diff --git a/doc/drafts/draft-legg-ldap-gser-abnf-xx.txt b/doc/drafts/draft-legg-ldap-gser-abnf-xx.txt
new file mode 100644
index 0000000000000000000000000000000000000000..fec416fb228206ae596628ba688c62f43c3af160
--- /dev/null
+++ b/doc/drafts/draft-legg-ldap-gser-abnf-xx.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+INTERNET-DRAFT S. Legg
+draft-legg-ldap-gser-abnf-04.txt Adacel Technologies
+Intended Category: Informational August 19, 2002
+
+
+ Common Elements of GSER Encodings
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Distribution of this document is unlimited. Comments should be sent
+ to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
+ or to the author.
+
+ This Internet-Draft expires on 19 February 2002.
+
+
+1. Abstract
+
+ The Generic String Encoding Rules (GSER) describe a human readable
+ text encoding for an ASN.1 value of any ASN.1 type. Specifications
+ making use of GSER may wish to provide an equivalent ABNF description
+ of the GSER encoding for a particular ASN.1 type as a convenience for
+ implementors. This document supports such specifications by
+ providing equivalent ABNF for the GSER encodings for ASN.1 types
+ commonly occuring in Lightweight Directory Access Protocol (LDAP)
+ syntaxes.
+
+
+
+Legg Expires 19 February 2002 [Page 1]
+
+INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+
+
+2. Table of Contents
+
+ 1. Abstract .................................................... 1
+ 2. Table of Contents ........................................... 2
+ 3. Introduction ................................................ 2
+ 4. Conventions ................................................. 2
+ 5. Separators .................................................. 2
+ 6. ASN.1 Built-in Types ........................................ 3
+ 7. ASN.1 Restricted String Types ............................... 7
+ 8. Directory ASN.1 Types ....................................... 8
+ 9. Security Considerations ..................................... 9
+ 10. Normative References ....................................... 10
+ 11. Informative References ..................................... 10
+ 12. Copyright Notice ........................................... 10
+ 13. Author's Address ........................................... 11
+
+
+3. Introduction
+
+ The Generic String Encoding Rules (GSER) defined in [9] define a
+ human readable text encoding, based on ASN.1 [7] value notation, for
+ an ASN.1 value of any ASN.1 type. Specifications making use of GSER
+ may wish to provide a non-normative equivalent ABNF [3] description
+ of the GSER encoding for a particular ASN.1 type as a convenience for
+ implementors unfamiliar with ASN.1. This document supports such
+ specifications by providing equivalent ABNF for the GSER encodings
+ for ASN.1 types commonly occuring in LDAP [8] or X.500 [10] attribute
+ and assertion syntaxes, as well as equivalent ABNF for the GSER
+ encodings for the ASN.1 built-in types.
+
+ The ABNF given in this document does not replace or alter GSER in any
+ way. If there is a discrepancy between the ABNF specified here and
+ the encoding defined by GSER in [9] then [9] is to be taken as
+ definitive.
+
+
+4. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [1].
+
+
+5. Separators
+
+ Certain separators are commonly used in constructing equivalent ABNF
+ for SET and SEQUENCE types.
+
+
+
+
+Legg Expires 19 February 2002 [Page 2]
+
+INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+
+
+ sp = *%x20 ; zero, one or more space characters
+ msp = 1*%x20 ; one or more space characters
+
+ sep = [ "," ]
+
+ The <sep> rule is used in the ABNF description of the encoding for
+ ASN.1 SET or SEQUENCE types where all the components are either
+ OPTIONAL or DEFAULT. It encodes to an empty string if and only if
+ the immediately preceding character in the encoding is "{", i.e. it
+ is only empty for the first optional component actually present in
+ the SET or SEQUENCE value being encoded.
+
+
+6. ASN.1 Built-in Types
+
+ This section describes the GSER encoding of values of the ASN.1
+ built-in types, except for the restricted character string types.
+
+ The <BIT-STRING> rule describes the GSER encoding of values of the
+ BIT STRING type without a named bit list.
+
+ BIT-STRING = bstring / hstring
+
+ If the number of bits in a BIT STRING value is a multiple of four the
+ <hstring> form of <BIT-STRING> MAY be used. The <bstring> form of
+ <BIT-STRING> is used otherwise. The <bstring> rule encodes each bit
+ as the character "0" or "1" in order from the first bit to the last
+ bit. The <hstring> rule encodes each group of four bits as a
+ hexadecimal number where the first bit is the most significant. An
+ odd number of hexadecimal digits is permitted.
+
+ hstring = squote *hexadecimal-digit squote %x48 ; '...'H
+ hexadecimal-digit = %x30-39 / ; "0" to "9"
+ %x41-46 ; "A" to "F"
+
+ bstring = squote *binary-digit squote %x42 ; '...'B
+ binary-digit = "0" / "1"
+
+ squote = %x27 ; ' (single quote)
+
+ The <BOOLEAN> rule describes the GSER encoding of values of the
+ BOOLEAN type.
+
+ BOOLEAN = %x54.52.55.45 / ; "TRUE"
+ %x46.41.4C.53.45 ; "FALSE"
+
+ The <CHARACTER-STRING> rule describes the GSER encoding of values of
+ the associated type for the unrestricted CHARACTER STRING type.
+
+
+
+Legg Expires 19 February 2002 [Page 3]
+
+INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+
+
+ CHARACTER-STRING = "{" sp id-identification msp Identification ","
+ sp id-data-value msp OCTET-STRING
+ sp "}"
+
+ id-identification = %x69.64.65.6E.74.69.66.69.63.61.74.69.6F.6E
+ ; "identification"
+ id-data-value = %x64.61.74.61.2D.76.61.6C.75.65 ; "data-value"
+
+ Identification = ( id-syntaxes ":" Syntaxes ) /
+ ( id-syntax ":" OBJECT-IDENTIFIER ) /
+ ( id-presentation-context-id ":" INTEGER ) /
+ ( id-context-negotiation ":"
+ ContextNegotiation ) /
+ ( id-transfer-syntax ":" OBJECT-IDENTIFIER ) /
+ ( id-fixed ":" NULL )
+
+ id-syntaxes = %x73.79.6E.74.61.78.65.73
+ ; "syntaxes"
+ id-syntax = %x73.79.6E.74.61.78 ; "syntax"
+ id-presentation-context-id = %x70.72.65.73.65.6E.74.61.74.69.6F.6E
+ %x2D.63.6F.6E.74.65.78.74.2D.69.64
+ ; "presentation-context-id"
+ id-context-negotiation = %x63.6F.6E.74.65.78.74.2D.6E.65.67.6F
+ %x74.69.61.74.69.6F.6E
+ ; "context-negotiation"
+ id-transfer-syntax = %x74.72.61.6E.73.66.65.72.2D.73.79.6E
+ %x74.61.78 ; "transfer-syntax"
+ id-fixed = %x66.69.78.65.64 ; "fixed"
+
+ Syntaxes = "{" sp id-abstract msp OBJECT-IDENTIFIER ","
+ sp id-transfer msp OBJECT-IDENTIFIER
+ sp "}"
+ id-abstract = %x61.62.73.74.72.61.63.74 ; "abstract"
+ id-transfer = %x74.72.61.6E.73.66.65.72 ; "transfer"
+
+ ContextNegotiation = "{" sp id-presentation-context-id msp
+ INTEGER ","
+ sp id-transfer-syntax msp
+ OBJECT-IDENTIFIER
+ sp "}"
+
+ The <INTEGER> rule describes the GSER encoding of values of the
+ INTEGER type without a named number list. The <INTEGER-0-MAX> rule
+ describes the GSER encoding of values of the constrained type INTEGER
+ (0..MAX). The <INTEGER-1-MAX> rule describes the GSER encoding of
+ values of the constrained type INTEGER (1..MAX).
+
+ INTEGER = "0" / positive-number / ("-" positive-number)
+
+
+
+Legg Expires 19 February 2002 [Page 4]
+
+INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+
+
+ INTEGER-0-MAX = "0" / positive-number
+ INTEGER-1-MAX = positive-number
+ positive-number = non-zero-digit *decimal-digit
+ decimal-digit = %x30-39 ; "0" to "9"
+ non-zero-digit = %x31-39 ; "1" to "9"
+
+ The <EMBEDDED-PDV> rule describes the GSER encoding of values of the
+ associated type for the EMBEDDED PDV type.
+
+ EMBEDDED-PDV = "{" sp id-identification msp Identification
+ [ "," sp id-data-value-descriptor msp
+ ObjectDescriptor ]
+ "," sp id-data-value msp OCTET-STRING
+ sp "}"
+
+ id-data-value-descriptor = %x64.61.74.61.2D.76.61.6C.75.65.2D.64
+ %x65.73.63.72.69.70.74.6F.72
+ ; "data-value-descriptor"
+
+ The <EXTERNAL> rule describes the GSER encoding of values of the
+ associated type for the EXTERNAL type.
+
+ EXTERNAL = "{" sp id-identification msp E-Identification
+ [ "," sp id-data-value-descriptor msp
+ ObjectDescriptor ]
+ "," sp id-data-value msp OCTET-STRING
+ sp "}"
+
+ E-Identification = ( id-syntax ":" OBJECT-IDENTIFIER ) /
+ ( id-presentation-context-id ":" INTEGER ) /
+ ( id-context-negotiation ":"
+ ContextNegotiation )
+
+ The <NULL> rule describes the GSER encoding of values of the NULL
+ type.
+
+ NULL = %x4E.55.4C.4C ; "NULL"
+
+ The <OBJECT-IDENTIFIER> rule describes the GSER encoding of values of
+ the OBJECT IDENTIFIER type.
+
+ OBJECT-IDENTIFIER = numeric-oid / descr
+ numeric-oid = oid-component 1*( "." oid-component )
+ oid-component = "0" / positive-number
+
+ An OBJECT IDENTIFIER value is encoded using either the dotted decimal
+ representation or an object descriptor name, i.e. <descr>. The
+ <descr> rule is described in [4]. An object descriptor name is
+
+
+
+Legg Expires 19 February 2002 [Page 5]
+
+INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+
+
+ potentially ambiguous and should be used with care.
+
+ The <OCTET-STRING> rule describes the GSER encoding of values of the
+ OCTET STRING type.
+
+ OCTET-STRING = hstring
+
+ The octets are encoded in order from the first octet to the last
+ octet. Each octet is encoded as a pair of hexadecimal digits where
+ the first digit corresponds to the four most significant bits of the
+ octet. If the hexadecimal string does not have an even number of
+ digits the four least significant bits in the last octet are assumed
+ to be zero.
+
+ The <REAL> rule describes the GSER encoding of values of the REAL
+ type.
+
+ REAL = "0" ; zero
+ / PLUS-INFINITY ; positive infinity
+ / MINUS-INFINITY ; negative infinity
+ / realnumber ; positive base 10 REAL value
+ / ( "-" realnumber ) ; negative base 10 REAL value
+ / real-sequence-value ; non-zero base 2 or 10 REAL value
+
+ PLUS-INFINITY = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59
+ ; "PLUS-INFINITY"
+ MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59
+ ; "MINUS-INFINITY"
+
+ realnumber = mantissa exponent
+ mantissa = (positive-number [ "." *decimal-digit ])
+ / ( "0." *("0") positive-number )
+ exponent = "E" ( "0" / ([ "-" ] positive-number))
+
+ real-sequence-value = "{" sp id-mantissa msp INTEGER ","
+ sp id-base msp ( "2" / "10" ) ","
+ sp id-exponent msp INTEGER sp "}"
+ id-mantissa = %x6D.61.6E.74.69.73.73.61 ; "mantissa"
+ id-base = %x62.61.73.65 ; "base"
+ id-exponent = %x65.78.70.6F.6E.65.6E.74 ; "exponent"
+
+ A value of the REAL type MUST be encoded as "0" if it is zero.
+
+ The <RELATIVE-OID> rule describes the GSER encoding of values of the
+ RELATIVE-OID type.
+
+ RELATIVE-OID = oid-component *( "." oid-component )
+
+
+
+
+Legg Expires 19 February 2002 [Page 6]
+
+INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+
+
+7. ASN.1 Restricted String Types
+
+ This section describes the GSER encoding of values of the ASN.1
+ restricted character string types. The characters of a value of a
+ restricted character string type are always encoded as a UTF8
+ character string between double quotes. For some of the ASN.1 string
+ types this requires a translation to or form the UTF8 encoding. Some
+ of the ASN.1 string types permit only a subset of the characters
+ representable in UTF8. Any double quote characters in the character
+ string, where allowed by the character set, are escaped by being
+ repeated.
+
+ The <UTF8String> rule describes the GSER encoding of values of the
+ UTF8String type. The characters of this string type do not require
+ any translation before being encoded.
+
+ UTF8String = StringValue
+ StringValue = dquote *SafeUTF8Character dquote
+
+ dquote = %x22 ; " (double quote)
+
+ SafeUTF8Character = %x00-21 / %x23-7F / ; ASCII minus dquote
+ dquote dquote / ; escaped double quote
+ %xC0-DF %x80-BF / ; 2 byte UTF8 character
+ %xE0-EF 2(%x80-BF) / ; 3 byte UTF8 character
+ %xF0-F7 3(%x80-BF) / ; 4 byte UTF8 character
+ %xF8-FB 4(%x80-BF) / ; 5 byte UTF8 character
+ %xFC-FD 5(%x80-BF) ; 6 byte UTF8 character
+
+ The <NumericString>, <PrintableString>, <VisibleString>,
+ <ISO646String>, <IA5String>, <GeneralizedTime> and <UTCTime> rules
+ describe the GSER encoding of values of the correspondingly named
+ ASN.1 types. The characters of these string types are compatible
+ with UTF8 and do not require any translation before being encoded.
+ The GeneralizedTime and UTCTime types use the VisibleString character
+ set, but have a strictly defined format.
+
+ NumericString = dquote *(decimal-digit / space) dquote
+ space = %x20
+
+ PrintableString = dquote *PrintableCharacter dquote
+ PrintableCharacter = decimal-digit / space
+ / %x41-5A ; A to Z
+ / %x61-7A ; a to z
+ / %x27-29 ; ' ( )
+ / %x2B-2F ; + , - . /
+ / %x3A ; :
+ / %x3D ; =
+
+
+
+Legg Expires 19 February 2002 [Page 7]
+
+INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+
+
+ / %x3F ; ?
+
+ ISO646String = VisibleString
+ VisibleString = dquote *SafeVisibleCharacter dquote
+ SafeVisibleCharacter = %x20-21
+ / %x23-7E ; printable ASCII minus dquote
+ / dquote dquote ; escaped double quote
+
+ IA5String = dquote *SafeIA5Character dquote
+ SafeIA5Character = %x00-21 / %x23-7F ; ASCII minus dquote
+ / dquote dquote ; escaped double quote
+
+ UTCTime = dquote 10(decimal-digit) [2(decimal-digit)]
+ [ "Z" / u-differential ] dquote
+ u-differential = ( "-" / "+" ) 4(decimal-digit)
+ GeneralizedTime = dquote 10(decimal-digit)
+ *2(2(decimal-digit))
+ fraction [ "Z" / g-differential ] dquote
+ fraction = ( "." / "," ) 1*decimal-digit
+ g-differential = ( "-" / "+" ) 1*2(2(decimal-digit))
+
+ The <BMPString> and <UniversalString> rules describe the GSER
+ encoding of values of the BMPString and UniversalString types
+ respectively. BMPString (UCS-2) and UniversalString (UCS-4) values
+ are translated into UTF8 [6] character strings before being encoded
+ according to <StringValue>.
+
+ BMPString = StringValue
+ UniversalString = StringValue
+
+ The <TeletexString>, <T61String>, <VideotexString>, <GraphicString>,
+ <GeneralString> and <ObjectDescriptor> rules describe the GSER
+ encoding of values of the correspondingly named ASN.1 types. Values
+ of these string types are translated into UTF8 character strings
+ before being encoded according to <StringValue>. The
+ ObjectDescriptor type uses the GraphicString character set.
+
+ TeletexString = StringValue
+ T61String = StringValue
+ VideotexString = StringValue
+ GraphicString = StringValue
+ GeneralString = StringValue
+ ObjectDescriptor = GraphicString
+
+
+8. Directory ASN.1 Types
+
+ This section describes the GSER encoding of values of selected ASN.1
+
+
+
+Legg Expires 19 February 2002 [Page 8]
+
+INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+
+
+ types defined for LDAP and X.500. The ABNF rule names beginning with
+ uppercase letters describe the GSER encoding of values of the ASN.1
+ type with the same name.
+
+ AttributeType = OBJECT-IDENTIFIER
+
+ The characters of a DirectoryString are translated into UTF8
+ characters as required before being encoded between double quotes
+ with any embedded double quotes escaped by being repeated.
+
+ DirectoryString = dquote *SafeUTF8Character dquote
+
+ The <RDNSequence> rule describes the GSER encoding of values of the
+ RDNSequence type, which is syntactically equivalent to the
+ DistinguishedName and LocalName types. The <RDNSequence> rule
+ encodes a name as an LDAPDN character string between double quotes.
+ The character string is first derived according to the
+ <distinguishedName> rule in Section 3 of [5], and then it is encoded
+ between double quotes with any embedded double quotes escaped by
+ being repeated.
+
+ DistinguishedName = RDNSequence
+ LocalName = RDNSequence
+ RDNSequence = dquote *SafeUTF8Character dquote
+
+ The <RelativeDistinguishedName> rule describes the GSER encoding of
+ values of the RelativeDistinguishedName type that are not part of an
+ RDNSequence value. The <RelativeDistinguishedName> rule encodes an
+ RDN as a double quoted string containing the RDN as it would appear
+ in an LDAPDN character string. The character string is first derived
+ according to the <name-component> rule in Section 3 of [6], and then
+ any embedded double quote characters are escaped by being repeated.
+ This resulting string is output between double quotes.
+
+ RelativeDistinguishedName = dquote *SafeUTF8Character dquote
+
+ The <ORAddress> rule encodes an X.400 address as an IA5 character
+ string between double quotes. The character string is first derived
+ according to Section 4.1 of [2], and then any embedded double quotes
+ are escaped by being repeated. This resulting string is output
+ between double quotes.
+
+ ORAddress = dquote *SafeIA5Character dquote
+
+
+9. Security Considerations
+
+ GSER, and therefore the ABNF encodings described in this document, do
+
+
+
+Legg Expires 19 February 2002 [Page 9]
+
+INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+
+
+ not necessarily enable the exact octet encoding of values of the
+ TeletexString, VideotexString, GraphicString or GeneralString types
+ to be reconstructed, so a transformation from DER to GSER and back to
+ DER may not reproduce the original DER encoding. This has
+ consequences for the verification of digital signatures.
+
+
+10. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
+ between X.400 and RFC 822/MIME", RFC 2156, January 1998.
+
+ [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [5] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished
+ Names", RFC 2253, December 1997.
+
+ [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+ 2279, January 1998.
+
+ [7] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
+ Information Technology - Abstract Syntax Notation One (ASN.1):
+ Specification of basic notation
+
+
+11. Informative References
+
+ [8] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [9] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
+ draft-legg-ldap-gser-xx.txt, a work in progress, August 2002.
+
+ [10] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Overview of concepts, models and services
+
+
+12. Copyright Notice
+
+
+
+Legg Expires 19 February 2002 [Page 10]
+
+INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+
+13. Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 405-409 Ferntree Gully Road
+ Mount Waverley, Victoria 3149
+ AUSTRALIA
+
+ Phone: +61 3 9451 2107
+ Fax: +61 3 9541 2121
+ EMail: steven.legg@adacel.com.au
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 19 February 2002 [Page 11]
+
diff --git a/doc/drafts/draft-legg-ldap-gser-xx.txt b/doc/drafts/draft-legg-ldap-gser-xx.txt
new file mode 100644
index 0000000000000000000000000000000000000000..6a34445acceefff56b909a9911c35bc478b2a5de
--- /dev/null
+++ b/doc/drafts/draft-legg-ldap-gser-xx.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+INTERNET-DRAFT S. Legg
+draft-legg-ldap-gser-01.txt Adacel Technologies
+Intended Category: Standard Track August 19, 2002
+
+
+ Generic String Encoding Rules for ASN.1 Types
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Distribution of this document is unlimited. Comments should be sent
+ to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
+ or to the author.
+
+ This Internet-Draft expires on 19 February 2002.
+
+
+1. Abstract
+
+ This document defines a set of Abstract Syntax Notation One (ASN.1)
+ encoding rules, called the Generic String Encoding Rules, that
+ produce a human readable text encoding for values of any given ASN.1
+ data type.
+
+
+
+
+
+
+
+Legg Expires 19 February 2002 [Page 1]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+2. Table of Contents
+
+ 1. Abstract ...................................................... 1
+ 2. Table of Contents ............................................. 2
+ 3. Introduction .................................................. 2
+ 4. Conventions ................................................... 3
+ 5. Generic String Encoding Rules ................................. 3
+ 5.1 Type Referencing Notations ................................ 4
+ 5.2 Restricted Character String Types ......................... 4
+ 5.3 ChoiceOfStrings Types ..................................... 5
+ 5.4 Identifiers ............................................... 7
+ 5.5 BIT STRING ................................................ 7
+ 5.6 BOOLEAN ................................................... 8
+ 5.7 ENUMERATED ................................................ 8
+ 5.8 INTEGER ................................................... 8
+ 5.9 NULL ...................................................... 8
+ 5.10 OBJECT IDENTIFIER and RELATIVE-OID ....................... 9
+ 5.11 OCTET STRING ............................................. 9
+ 5.12 CHOICE ................................................... 9
+ 5.13 SEQUENCE and SET ......................................... 10
+ 5.14 SEQUENCE OF and SET OF ................................... 11
+ 5.15 CHARACTER STRING ......................................... 11
+ 5.16 EMBEDDED PDV ............................................. 11
+ 5.17 EXTERNAL ................................................. 11
+ 5.18 INSTANCE OF .............................................. 12
+ 5.19 REAL ..................................................... 12
+ 5.20 Variant Encodings ........................................ 12
+ 6. GSER Transfer Syntax .......................................... 13
+ 7. Security Considerations ....................................... 13
+ 8. Normative References .......................................... 13
+ 9. Informative References ........................................ 14
+ 10. Copyright Notice ............................................. 15
+ 11. Author's Address ............................................. 15
+
+
+3. Introduction
+
+ This document defines a set of ASN.1 [8] encoding rules, called the
+ Generic String Encoding Rules or GSER, that produce a human readable
+ UTF8 [6] character string encoding of ASN.1 values of any given
+ arbitrary ASN.1 type.
+
+ Note that "ASN.1 value" does not mean a BER [17] encoded value. The
+ ASN.1 value is an abstract concept that is independent of any
+ particular encoding. BER is just one possible encoding of an ASN.1
+ value.
+
+ GSER is based on ASN.1 value notation [8], with changes to
+
+
+
+Legg Expires 19 February 2002 [Page 2]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+ accommodate the notation's use as a transfer syntax, and to support
+ well established ad-hoc string encodings for LDAP [13] directory data
+ types.
+
+ Though primarily intended for defining the LDAP-specific encoding of
+ new LDAP attribute syntaxes and assertion syntaxes, these encoding
+ rules could also be used in other domains where human readable
+ renderings of ASN.1 values would be useful.
+
+ Referencing the Generic String Encoding Rules (GSER) is sufficient to
+ define a human readable text encoding for values of a specific ASN.1
+ type, however other specifications may wish to provide a customized
+ ABNF [3] description, independent of the ASN.1, as a convenience for
+ the implementor (equivalent ABNF for the GSER encodings for ASN.1
+ types commonly occuring in LDAP syntaxes is provided in [14]). Such
+ a specification SHOULD state that if there is a discrepancy between
+ the customized ABNF and the GSER encoding defined by this document,
+ that the GSER encoding takes precedence.
+
+
+4. Conventions
+
+ Throughout this document "type" shall be taken to mean an ASN.1 type,
+ and "value" shall be taken to mean an ASN.1 value.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [1].
+
+
+5. Generic String Encoding Rules
+
+ The GSER encoding of a value of any ASN.1 type is described by the
+ following ABNF [3]:
+
+ Value = BitStringValue /
+ BooleanValue /
+ CharacterStringValue /
+ ChoiceValue /
+ EmbeddedPDVValue /
+ EnumeratedValue /
+ ExternalValue /
+ GeneralizedTimeValue /
+ IntegerValue /
+ InstanceOfValue /
+ NullValue /
+ ObjectDescriptorValue /
+ ObjectIdentifierValue /
+
+
+
+Legg Expires 19 February 2002 [Page 3]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+ OctetStringValue /
+ RealValue /
+ RelativeOIDValue /
+ SequenceOfValue /
+ SequenceValue /
+ SetOfValue /
+ SetValue /
+ StringValue /
+ UTCTimeValue /
+ VariantEncoding
+
+ The ABNF for each of the above rules is given in the following
+ sections.
+
+
+5.1 Type Referencing Notations
+
+ A value of a type with a defined type name is encoded according to
+ the type definition on the right hand side of the type assignment for
+ the type name.
+
+ A value of a type denoted by the use of a parameterized type with
+ actual parameters is encoded according to the parameterized type with
+ the DummyReferences [12] substituted with the actual parameters.
+
+ A value of a tagged or constrained type is encoded as a value of the
+ type without the tag or constraint, respectively. Tags do not appear
+ in the string encodings defined by this document. See [8] and [11]
+ for the details of ASN.1 constraint notation.
+
+ A value of an open type denoted by an ObjectClassFieldType (Clause 14
+ of [10]) is encoded according to the specific type of the value.
+
+ A value of a fixed type denoted by an ObjectClassFieldType is encoded
+ according to that fixed type.
+
+ A value of a selection type is encoded according to the type
+ referenced by the selection type.
+
+ A value of a type described by TypeFromObject notation (Clause 15 of
+ [10]) is encoded according to the denoted type.
+
+ A value of a type described by ValueSetFromObjects notation (Clause
+ 15 of [10]) is encoded according to the governing type.
+
+
+5.2 Restricted Character String Types
+
+
+
+
+Legg Expires 19 February 2002 [Page 4]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+ The contents of a string value are encoded as a UTF8 character string
+ between double quotes, regardless of the ASN.1 string type.
+ Depending on the ASN.1 string type, and an application's internal
+ representation of that string type, a translation to or from the UTF8
+ character encoding may be required. NumericString, PrintableString,
+ IA5String, VisibleString (ISO646String) are compatible with UTF8 and
+ do not require any translation. BMPString (UCS-2) and
+ UniversalString (UCS-4) have a direct mapping to and from UTF8 [6].
+ For the remaining string types see [8]. Any embedded double quotes
+ in the resulting UTF8 character string are escaped by repeating the
+ double quote characters.
+
+ A value of the NumericString, PrintableString, TeletexString
+ (T61String), VideotexString, IA5String, GraphicString, VisibleString
+ (ISO646String), GeneralString, BMPString, UniversalString or
+ UTF8String type is encoded according to the <StringValue> rule.
+
+ StringValue = dquote *SafeUTF8Character dquote
+
+ dquote = %x22 ; " (double quote)
+
+ SafeUTF8Character = %x00-21 / %x23-7F / ; ASCII minus dquote
+ dquote dquote / ; escaped double quote
+ %xC0-DF %x80-BF / ; 2 byte UTF8 character
+ %xE0-EF 2(%x80-BF) / ; 3 byte UTF8 character
+ %xF0-F7 3(%x80-BF) / ; 4 byte UTF8 character
+ %xF8-FB 4(%x80-BF) / ; 5 byte UTF8 character
+ %xFC-FD 5(%x80-BF) ; 6 byte UTF8 character
+
+ A value of the GeneralizedTime type, UTCTime type or ObjectDescriptor
+ type is encoded as a string value. GeneralizedTime and UTCTime use
+ the VisibleString character set so the conversion to UTF8 is trivial.
+ ObjectDescriptor uses the GraphicString type.
+
+ GeneralizedTimeValue = StringValue
+ UTCTimeValue = StringValue
+ ObjectDescriptorValue = StringValue
+
+
+5.3 ChoiceOfStrings Types
+
+ It is not uncommon for ASN.1 specifications to define types that are
+ a CHOICE between two or more alternative ASN.1 string types, where
+ the particular alternative chosen carries no semantic significance
+ (DirectoryString [7] being a prime example). Such types are defined
+ to avoid having to use a complicated character encoding for all
+ values when most values could use a simpler string type, or to deal
+ with evolving requirements that compel the use of a broader character
+
+
+
+Legg Expires 19 February 2002 [Page 5]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+ set while still maintaining backward compatibility.
+
+ GSER encodes values of all the ASN.1 string types as UTF8 character
+ strings so the alternative chosen in a purely syntactic CHOICE of
+ string types makes no material difference to the final encoding of
+ the string value.
+
+ While there are certain ASN.1 constructs that betray the semantic
+ significance of the alternatives within a CHOICE type, the absence of
+ those constructs does not necessarily mean a CHOICE type is purely
+ syntactic. Therefore, it is necessary for specifications to declare
+ the purely syntactic CHOICE types so that they may be more compactly
+ encoded (see Section 5.12). These declared CHOICE types are referred
+ to as ChoiceOfStrings types.
+
+ To be eligible to be declared a ChoiceOfStrings type an ASN.1 type
+ MUST satisfy the following conditions.
+
+ a) The type is a CHOICE type.
+
+ b) The component type of each alternative is one of the following
+ ASN.1 restricted string types: NumericString, PrintableString,
+ TeletexString (T61String), VideotexString, IA5String,
+ GraphicString, VisibleString (ISO646String), GeneralString,
+ BMPString, UniversalString or UTF8String.
+
+ c) All the alternatives are of different restricted string types,
+ i.e. no two alternatives have the same ASN.1 restricted string
+ type.
+
+ d) Either none of the alternatives has a constraint, or all of the
+ alternatives have exactly the same constraint.
+
+ Tagging on the alternative types is ignored.
+
+ Consider the ASN.1 parameterized type definition of DirectoryString.
+
+ DirectoryString { INTEGER : maxSize } ::= CHOICE {
+ teletexString TeletexString (SIZE (1..maxSize)),
+ printableString PrintableString (SIZE (1..maxSize)),
+ bmpString BMPString (SIZE (1..maxSize)),
+ universalString UniversalString (SIZE (1..maxSize)),
+ uTF8String UTF8String (SIZE (1..maxSize)) }
+
+ Any use of the DirectoryString parameterized type with an actual
+ parameter defines a ASN.1 type that satisfies the above conditions.
+ Recognising that the alternative within a DirectoryString carries no
+ semantic significance, this document declares (each and every use of)
+
+
+
+Legg Expires 19 February 2002 [Page 6]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+ DirectoryString{} to be a ChoiceOfStrings type.
+
+ Other specifications MAY declare other types satisfying the above
+ conditions to be ChoiceOfStrings types. The declaration SHOULD be
+ made at the point where the ASN.1 type is defined, otherwise it
+ SHOULD be made at the point where it is introduced as, or in, an LDAP
+ attribute or assertion syntax.
+
+
+5.4 Identifiers
+
+ An <identifier> conforms to the definition of an identifier in ASN.1
+ notation (Clause 11.3 of [8]). It begins with a lowercase letter and
+ is followed by zero or more letters, digits, and hyphens. A hyphen
+ is not permitted to be the last character and a hyphen is not
+ permitted to be followed by another hyphen. The case of letters in
+ an identifier is always significant.
+
+ identifier = lowercase *alphanumeric *(hyphen 1*alphanumeric)
+ alphanumeric = uppercase / lowercase / decimal-digit
+ uppercase = %x41-5A ; "A" to "Z"
+ lowercase = %x61-7A ; "a" to "z"
+ decimal-digit = %x30-39 ; "0" to "9"
+ hyphen = "-"
+
+
+5.5 BIT STRING
+
+ A value of the BIT STRING type is encoded according to the
+ <BitStringValue> rule. If the definition of the BIT STRING type
+ includes a named bit list, the <bit-list> form of <BitStringValue>
+ rule MAY be used. If the number of bits in a BIT STRING value is a
+ multiple of four the <hstring> form of <BitStringValue> MAY be used.
+ The <bstring> form of <BitStringValue> is used otherwise.
+
+ BitStringValue = bstring / hstring / bit-list
+
+ The <bit-list> rule encodes the one bits in the bit string value as a
+ comma separated list of identifiers. Each <identifier> MUST be one
+ of those in the named bit list. An <identifier> MUST NOT appear more
+ than once in the same <bit-list>. The <bstring> rule encodes each
+ bit as the character "0" or "1" in order from the first bit to the
+ last bit. The <hstring> rule encodes each group of four bits as a
+ hexadecimal number where the first bit is the most significant. An
+ odd number of hexadecimal digits is permitted.
+
+ bit-list = "{" [ sp identifier
+ *( "," sp identifier ) ] sp "}"
+
+
+
+Legg Expires 19 February 2002 [Page 7]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+ hstring = squote *hexadecimal-digit squote %x48 ; '...'H
+ hexadecimal-digit = %x30-39 / ; "0" to "9"
+ %x41-46 ; "A" to "F"
+
+ bstring = squote *binary-digit squote %x42 ; '...'B
+ binary-digit = "0" / "1"
+
+ sp = *%x20 ; zero, one or more space characters
+ squote = %x27 ; ' (single quote)
+
+
+5.6 BOOLEAN
+
+ A value of the BOOLEAN type is encoded according to the
+ <BooleanValue> rule.
+
+ BooleanValue = %x54.52.55.45 / ; "TRUE"
+ %x46.41.4C.53.45 ; "FALSE"
+
+
+5.7 ENUMERATED
+
+ A value of the ENUMERATED type is encoded according to the
+ <EnumeratedValue> rule. The <identifier> MUST be one of those in the
+ list of enumerations in the definition of the ENUMERATED type.
+
+ EnumeratedValue = identifier
+
+
+5.8 INTEGER
+
+ A value of the INTEGER type is encoded according to the
+ <IntegerValue> rule. If the definition of the INTEGER type includes
+ a named number list, the <identifier> form of <IntegerValue> MAY be
+ used, in which case the <identifier> MUST be one of those in the
+ named number list.
+
+ IntegerValue = "0" /
+ positive-number /
+ ("-" positive-number) /
+ identifier
+
+ positive-number = non-zero-digit *decimal-digit
+ non-zero-digit = %x31-39 ; "1" to "9"
+
+
+5.9 NULL
+
+
+
+
+Legg Expires 19 February 2002 [Page 8]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+ A value of the NULL type is encoded according to the <NullValue>
+ rule.
+
+ NullValue = %x4E.55.4C.4C ; "NULL"
+
+
+5.10 OBJECT IDENTIFIER and RELATIVE-OID
+
+ A value of the OBJECT IDENTIFIER type is encoded according to the
+ <ObjectIdentifierValue> rule. The <ObjectIdentifierValue> rule
+ allows either a dotted decimal representation of the OBJECT
+ IDENTIFIER value or an object descriptor name, i.e. <descr>. The
+ <descr> rule is described in [4]. An object descriptor name is
+ potentially ambiguous and should be used with care.
+
+ ObjectIdentifierValue = numeric-oid / descr
+ numeric-oid = oid-component 1*( "." oid-component )
+ oid-component = "0" / positive-number
+
+ A value of the RELATIVE-OID [9] type is encoded according to the
+ <RelativeOIDValue> rule.
+
+ RelativeOIDValue = oid-component *( "." oid-component )
+
+
+5.11 OCTET STRING
+
+ A value of the OCTET STRING type is encoded according to the
+ <OctetStringValue> rule. The octets are encoded in order from the
+ first octet to the last octet. Each octet is encoded as a pair of
+ hexadecimal digits where the first digit corresponds to the four most
+ significant bits of the octet. If the hexadecimal string does not
+ have an even number of digits the four least significant bits in the
+ last octet are assumed to be zero.
+
+ OctetStringValue = hstring
+
+
+5.12 CHOICE
+
+ A value of a CHOICE type is encoded according to the <ChoiceValue>
+ rule. The <ChoiceOfStringsValue> encoding MAY be used if the
+ corresponding CHOICE type has been declared a ChoiceOfStrings type.
+ This document declares DirectoryString to be a ChoiceOfStrings type
+ (see Section 5.3). The <IdentifiedChoiceValue> form of <ChoiceValue>
+ is used otherwise.
+
+ ChoiceValue = IdentifiedChoiceValue /
+
+
+
+Legg Expires 19 February 2002 [Page 9]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+ ChoiceOfStringsValue
+
+ IdentifiedChoiceValue = identifier ":" Value
+ ChoiceOfStringsValue = StringValue
+
+ For implementations that recognise the internal structure of the
+ DirectoryString CHOICE type (e.g. X.500 directories [15]), if the
+ character string between the quotes in a <StringValue> contains only
+ characters that are permitted in a PrintableString the
+ DirectoryString is assumed to use the printableString alternative,
+ otherwise it is assumed to use the uTF8String alternative. The
+ <IdentifiedChoiceValue> rule MAY be used for a value of type
+ DirectoryString to indicate a different alternative to the one that
+ would otherwise be assumed from the string contents. No matter what
+ alternative is chosen, the <Value> will still be a UTF8 encoded
+ character string, however it is a syntax error if the characters in
+ the UTF8 string cannot be represented in the string type of the
+ chosen alternative.
+
+ Implementations that don't care about the internal structure of a
+ DirectoryString value MUST be able to parse the
+ <IdentifiedChoiceValue> form for a DirectoryString value, though the
+ particular identifier found will be of no interest.
+
+5.13 SEQUENCE and SET
+
+ A value of a SEQUENCE type is encoded according to the
+ <SequenceValue> rule. The <ComponentList> rule encodes a comma
+ separated list of the particular component values present in the
+ SEQUENCE value, where each component value is preceded by the
+ corresponding identifier from the SEQUENCE type definition. The
+ components are encoded in the order of their definition in the
+ SEQUENCE type.
+
+ SequenceValue = ComponentList
+
+ ComponentList = "{" [ sp NamedValue *( "," sp NamedValue) ] sp "}"
+ NamedValue = identifier msp Value
+ msp = 1*%x20 ; one or more space characters
+
+ A value of a SET type is encoded according to the <SetValue> rule.
+ The components are encoded in the order of their definition in
+ the SET type (i.e. just like a SEQUENCE value).
+ This is a deliberate departure from ASN.1 value notation where
+ the components of a SET can be written in any order.
+
+ SetValue = ComponentList
+
+
+
+
+Legg Expires 19 February 2002 [Page 10]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+ SEQUENCE and SET type definitions are sometimes extended by the
+ inclusion of additional component types, so an implementation SHOULD
+ be capable of skipping over any <NamedValue> encoding with an
+ identifier that is not recognised, on the assumption that the sender
+ is using a more recent definition of the SEQUENCE or SET type.
+
+
+5.14 SEQUENCE OF and SET OF
+
+ A value of a SEQUENCE OF type is encoded according to the
+ <SequenceOfValue> rule, as a comma separated list of the instances in
+ the value. Each instance is encoded according to the component type
+ of the SEQUENCE OF type.
+
+ SequenceOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
+
+ A value of a SET OF type is encoded according to the <SetOfValue>
+ rule, as a list of the instances in the value. Each instance is
+ encoded according to the component type of the SET OF type.
+
+ SetOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
+
+
+5.15 CHARACTER STRING
+
+ A value of the unrestricted CHARACTER STRING type is encoded
+ according to the corresponding SEQUENCE type defined in Clause 39.5
+ of [8] (see [14] for equivalent ABNF).
+
+ CharacterStringValue = SequenceValue
+
+
+5.16 EMBEDDED PDV
+
+ A value of the EMBEDDED PDV type is encoded according to the
+ corresponding SEQUENCE type defined in Clause 32.5 of [8] (see [14]
+ for equivalent ABNF).
+
+ EmbeddedPDVValue = SequenceValue
+
+
+5.17 EXTERNAL
+
+ A value of the EXTERNAL type is encoded according to the
+ corresponding SEQUENCE type defined in Clause 33.5 of [8] (see [14]
+ for equivalent ABNF).
+
+ ExternalValue = SequenceValue
+
+
+
+Legg Expires 19 February 2002 [Page 11]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+5.18 INSTANCE OF
+
+ A value of the INSTANCE OF type is encoded according to the
+ corresponding SEQUENCE type defined in Annex C of [10].
+
+ InstanceOfValue = SequenceValue
+
+
+5.19 REAL
+
+ A value of the REAL type MUST be encoded as "0" if it is zero,
+ otherwise it is encoded as either the special value <PLUS-INFINITY>,
+ the special value <MINUS-INFINITY>, an optionally signed <realnumber>
+ (based on the extended value notation for REAL from [16]) or as a
+ value of the corresponding SEQUENCE type for REAL defined in Clause
+ 20.5 of [8] (see [14] for equivalent ABNF).
+
+ RealValue = "0" ; zero REAL value
+ / PLUS-INFINITY ; positive infinity
+ / MINUS-INFINITY ; negative infinity
+ / realnumber ; positive base 10 REAL value
+ / "-" realnumber ; negative base 10 REAL value
+ / SequenceValue ; non-zero REAL value, base 2 or 10
+ realnumber = mantissa exponent
+ mantissa = (positive-number [ "." *decimal-digit ])
+ / ( "0." *("0") positive-number )
+ exponent = "E" ( "0" / ([ "-" ] positive-number))
+
+ PLUS-INFINITY = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59
+ ; "PLUS-INFINITY"
+ MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59
+ ; "MINUS-INFINITY"
+
+
+5.20 Variant Encodings
+
+ The values of some named complex ASN.1 types have special string
+ encodings. These special encodings are always used instead of the
+ encoding that would otherwise apply based on the ASN.1 type
+ definition.
+
+ VariantEncoding = RDNSequenceValue /
+ RelativeDistinguishedNameValue /
+ ORAddressValue
+
+ A value of the RDNSequence type, i.e. a distinguished name, is
+ encoded according to the <RDNSequenceValue> rule, as a quoted LDAPDN
+ character string. The character string is first derived according to
+
+
+
+Legg Expires 19 February 2002 [Page 12]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+ the <distinguishedName> rule in Section 3 of [5], and then it is
+ encoded as if it were a UTF8String value, i.e. between double quotes
+ with any embedded double quotes escaped by being repeated.
+
+ RDNSequenceValue = StringValue
+
+ A RelativeDistinguishedName value that is not part of an RDNSequence
+ value is encoded according to the <RelativeDistinguishedNameValue>
+ rule as a quoted character string. The character string is first
+ derived according to the <name-component> rule in Section 3 of [5],
+ and then it is encoded as if it were a UTF8String value.
+
+ RelativeDistinguishedNameValue = StringValue
+
+ A value of the ORAddress type is encoded according to the
+ <ORAddressValue> rule as a quoted character string. The character
+ string is first derived according to the textual representation of
+ MTS.ORAddress from [2], and then it is encoded as if it were an
+ IA5String value.
+
+ ORAddressValue = StringValue
+
+
+6. GSER Transfer Syntax
+
+ The following OBJECT IDENTIFIER has been assigned to identify the
+ Generic String Encoding Rules:
+
+ { 1 2 36 79672281 0 0 }
+
+ This OBJECT IDENTIFIER would be used, for example, to describe the
+ transfer syntax for a GSER encoded data-value in an EXTERNAL or
+ EMBEDDED PDV value.
+
+
+7. Security Considerations
+
+ The Generic String Encoding Rules do not necessarily enable the exact
+ octet encoding of values of the TeletexString, VideotexString,
+ GraphicString or GeneralString types to be reconstructed, so a
+ transformation from DER to GSER and back to DER may not reproduce the
+ original DER encoding. This has consequences for the verification of
+ digital signatures.
+
+
+8. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+
+
+
+Legg Expires 19 February 2002 [Page 13]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
+ between X.400 and RFC 822/MIME", RFC 2156, January 1998.
+
+ [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished
+ Names", RFC 2253, December 1997.
+
+ [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+ 2279, January 1998.
+
+ [7] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Selected attribute types
+
+ [8] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
+ Information Technology - Abstract Syntax Notation One (ASN.1):
+ Specification of basic notation
+
+ [9] ITU-T Recommendation X.680 - Amendment 1 (06/99) | ISO/IEC
+ 8824-1:1998/Amd 1:2000 Relative object identifiers
+
+ [10] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998
+ Information Technology - Abstract Syntax Notation One (ASN.1):
+ Information object specification
+
+ [11] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998
+ Information Technology - Abstract Syntax Notation One (ASN.1):
+ Constraint specification
+
+ [12] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998
+ Information Technology - Abstract Syntax Notation One (ASN.1):
+ Parameterization of ASN.1 specifications
+
+
+9. Informative References
+
+ [13] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+
+
+
+Legg Expires 19 February 2002 [Page 14]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+ [14] Legg, S., "Common Elements of GSER Encodings",
+ draft-legg-ldap-gser-abnf-xx.txt, a work in progress, August
+ 2002.
+
+ [15] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Overview of concepts, models and services
+
+ [16] ITU-T Recommendation X.680 - Corrigendum 3 (02/2001)
+
+ [17] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
+ Information Technology - ASN.1 encoding rules: Specification of
+ Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)
+
+
+10. Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+
+11. Author's Address
+
+ Steven Legg
+
+
+
+Legg Expires 19 February 2002 [Page 15]
+
+INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+
+
+ Adacel Technologies Ltd.
+ 405-409 Ferntree Gully Road
+ Mount Waverley, Victoria 3149
+ AUSTRALIA
+
+ Phone: +61 3 9451 2107
+ Fax: +61 3 9541 2121
+ EMail: steven.legg@adacel.com.au
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 19 February 2002 [Page 16]
+
diff --git a/doc/drafts/draft-legg-ldapext-component-matching-xx.txt b/doc/drafts/draft-legg-ldapext-component-matching-xx.txt
new file mode 100644
index 0000000000000000000000000000000000000000..e308c467407ef38670cb218d1b43be8e2c2befe8
--- /dev/null
+++ b/doc/drafts/draft-legg-ldapext-component-matching-xx.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+INTERNET-DRAFT S. Legg
+draft-legg-ldapext-component-matching-08.txt Adacel Technologies
+Intended Category: Standard Track April 19, 2002
+
+
+ LDAP & X.500 Component Matching Rules
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Distribution of this document is unlimited. Comments should be sent
+ to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
+ or to the author.
+
+ This Internet-Draft expires on 19 October 2002.
+
+
+1. Abstract
+
+ The syntaxes of attributes in a Lightweight Directory Access Protocol
+ or X.500 directory range from simple data types, such as text string,
+ integer, or boolean, to complex structured data types, such as the
+ syntaxes of the directory schema operational attributes. The
+ matching rules defined for the complex syntaxes, if any, usually only
+ provide the most immediately useful matching capability. This
+ document defines generic matching rules that can match any user
+ selected component parts in an attribute value of any arbitrarily
+
+
+
+Legg Expires 19 October 2002 [Page 1]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ complex attribute syntax.
+
+
+2. Table of Contents
+
+ 1. Abstract ...................................................... 1
+ 2. Table of Contents ............................................. 2
+ 3. Introduction .................................................. 2
+ 4. Conventions ................................................... 4
+ 5. ComponentAssertion ............................................ 5
+ 5.1 Component Reference ....................................... 5
+ 5.1.1 Component Type Substitutions ......................... 7
+ 5.1.2 Referencing SET, SEQUENCE and CHOICE Components ...... 8
+ 5.1.3 Referencing SET OF and SEQUENCE OF Components ........ 9
+ 5.1.4 Referencing Components of Parameterized Types ........ 10
+ 5.1.5 Component Referencing Example ........................ 10
+ 5.1.6 Referencing Components of Open Types ................. 11
+ 5.1.6.1 Open Type Referencing Example ................... 12
+ 5.1.7 Referencing Contained Types .......................... 13
+ 5.1.7.1 Contained Type Referencing Example .............. 14
+ 5.2 Matching of Components .................................... 15
+ 5.2.1 Applicability of Existing Matching Rules ............. 16
+ 5.2.1.1 String Matching ................................. 16
+ 5.2.1.2 Telephone Number Matching ....................... 17
+ 5.2.1.3 Distinguished Name Matching ..................... 17
+ 5.2.2 Additional Useful Matching Rules ..................... 17
+ 5.2.2.1 The rdnMatch Matching Rule ...................... 18
+ 5.2.2.2 The presentMatch Matching Rule .................. 18
+ 5.2.3 Summary of Useful Matching Rules ..................... 19
+ 6. ComponentFilter ............................................... 21
+ 7. The componentFilterMatch Matching Rule ........................ 22
+ 8. Equality Matching of Complex Components ....................... 23
+ 8.1 The OpenAssertionType Syntax .............................. 24
+ 8.2 The allComponentsMatch Matching Rule ...................... 25
+ 8.3 Deriving Component Equality Matching Rules ................ 27
+ 8.4 The directoryComponentsMatch Matching Rule ................ 28
+ 9. Component Matching Examples ................................... 29
+ 10. Security Considerations ...................................... 36
+ 11. Acknowledgements ............................................. 36
+ 12. Normative References ......................................... 36
+ 13. Informative References ....................................... 37
+ 14. Intellectual Property Notice ................................. 38
+ 15. Copyright Notice ............................................. 38
+ 16. Author's Address ............................................. 39
+
+
+3. Introduction
+
+
+
+
+Legg Expires 19 October 2002 [Page 2]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ The structure or data type of data held in an attribute of an LDAP
+ [3] or X.500 [18] 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.
+
+ In X.500, the attribute syntaxes are explicitly described by ASN.1
+ [11] type definitions. ASN.1 type notation has a number of simple
+ data types (e.g. PrintableString, INTEGER, BOOLEAN), and combining
+ types (i.e. SET, SEQUENCE, SET OF, SEQUENCE OF, and CHOICE) for
+ constructing arbitrarily complex data types from simpler component
+ types. In LDAP, the attribute syntaxes are usually described by ABNF
+ [2] though there is an implied association between the LDAP attribute
+ syntaxes and the X.500 ASN.1 types. To a large extent, the data
+ types of attribute values in either an LDAP or X.500 directory are
+ described by ASN.1 types. This formal description can be exploited
+ to identify component parts of an attribute value for a variety of
+ purposes. This document addresses attribute value matching.
+
+ With any complex attribute syntax there is normally a requirement to
+ partially match an attribute value of that syntax by matching only
+ selected components of the value. Typically, matching rules specific
+ to the attribute syntax are defined to fill this need. These highly
+ specific matching rules usually only provide the most immediately
+ useful matching capability. Some complex attribute syntaxes don't
+ even have an equality matching rule let alone any additional matching
+ rules for partial matching. This document defines a generic way of
+ matching user selected components in an attribute value of any
+ arbitrarily complex attribute syntax, where that syntax is described
+ using ASN.1 type notation. All of the type notations defined in [11]
+ are supported.
+
+ Section 5 describes the ComponentAssertion, a testable assertion
+ about the value of a component of an attribute value of any complex
+ syntax.
+
+ Section 6 introduces the ComponentFilter assertion, which is an
+ expression of ComponentAssertions. The ComponentFilter enables more
+ powerful filter matching of components in an attribute value.
+
+ Section 7 defines the componentFilterMatch matching rule, which
+ enables a ComponentFilter to be evaluated against attribute values.
+
+ Section 8 defines matching rules for component-wise equality matching
+ of attribute values of any syntax described by an ASN.1 type
+ definition.
+
+ Examples showing the usage of componentFilterMatch are in Section 9.
+
+
+
+Legg Expires 19 October 2002 [Page 3]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ For a new attribute syntax, the Generic String Encoding Rules [7] and
+ the specifications in sections 5 to 8 of this document make it
+ possible to fully and precisely define, the LDAP-specific encoding,
+ the LDAP and X.500 binary encoding (and possibly other encodings in
+ the future, e.g. XML via XER), a suitable equality matching rule, and
+ a comprehensive collection of component matching capabilities, by
+ simply writing down an ASN.1 type definition for the syntax. These
+ implicit definitions are also automatically extended if the ASN.1
+ type is later extended. The algorithmic relationship between the
+ ASN.1 type definition, the various encodings and the component
+ matching behaviour makes directory server implementation support for
+ the component matching rules amenable to automatic code generation
+ from ASN.1 type definitions.
+
+ Schema designers have the choice of storing related items of data as
+ a single attribute value of a complex syntax in some entry, or as a
+ subordinate entry where the related data items are stored as separate
+ attribute values of simpler syntaxes. The inability to search
+ component parts of a complex syntax has been used as an argument for
+ favouring the subordinate entries approach. The component matching
+ rules provide the analogous matching capability on an attribute value
+ of a complex syntax that a search filter has on a subordinate entry.
+
+ Most LDAP syntaxes have corresponding ASN.1 type definitions, though
+ they are usually not reproduced or referenced alongside the formal
+ definition of the LDAP syntax. Syntaxes defined with only a
+ character string encoding, i.e. without an explicit or implied
+ corresponding ASN.1 type definition, cannot use the component
+ matching capabilities described in this document unless and until a
+ semantically equivalent ASN.1 type definition is defined for them.
+
+
+4. Conventions
+
+ Throughout this document "type" shall be taken to mean an ASN.1 type
+ unless explicitly qualified as an attribute type, and "value" shall
+ be taken to mean an ASN.1 value unless explicitly qualified as an
+ attribute value.
+
+ Note that "ASN.1 value" does not mean a BER [19] encoded value. The
+ ASN.1 value is an abstract concept that is independent of any
+ particular encoding. BER is just one possible encoding of an ASN.1
+ value. The component matching rules operate at the abstract level
+ without regard for the possible encodings of a value.
+
+ Attribute type and matching rule definitions in this document are
+ provided in both the X.500 [8] and LDAP [4] description formats. Note
+ that the LDAP descriptions have been rendered with additional
+
+
+
+Legg Expires 19 October 2002 [Page 4]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ white-space and line breaks for the sake of readability.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [1].
+
+
+5. ComponentAssertion
+
+ A ComponentAssertion is an assertion about the presence, or values
+ of, components within an ASN.1 value, i.e. an instance of an ASN.1
+ type. The ASN.1 value is typically an attribute value, where the
+ ASN.1 type is the syntax of the attribute. However a
+ ComponentAssertion may also be applied to a component part of an
+ attribute value. The assertion evaluates to either TRUE, FALSE or
+ undefined for each tested ASN.1 value.
+
+ A ComponentAssertion is described by the following ASN.1 type
+ (assumed to be defined with "EXPLICIT TAGS" in force):
+
+ ComponentAssertion ::= SEQUENCE {
+ component ComponentReference,
+ useDefaultValues BOOLEAN DEFAULT TRUE,
+ rule MATCHING-RULE.&id,
+ value MATCHING-RULE.&AssertionType }
+
+ ComponentReference ::= UTF8String
+
+ MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching
+ rule. MATCHING-RULE.&AssertionType is an open type (formally known
+ as the ANY type).
+
+ The "component" field of a ComponentAssertion identifies which
+ component part of a value of some ASN.1 type is to be tested, the
+ "useDefaultValues" field indicates whether DEFAULT values are to be
+ substituted for absent component values, the "rule" field indicates
+ how the component is to be tested, and the "value" field is an
+ asserted ASN.1 value against which the component is tested. The
+ ASN.1 type of the asserted value is determined by the chosen rule.
+
+ The fields of a ComponentAssertion are described in detail in the
+ following sections.
+
+
+5.1 Component Reference
+
+ The component field in a ComponentAssertion is a UTF8 character
+ string [6] whose textual content is a component reference,
+
+
+
+Legg Expires 19 October 2002 [Page 5]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ identifying a component part of some ASN.1 type or value. A
+ component reference conforms to the following ABNF [2], which extends
+ the notation defined in Clause 14 of [11]:
+
+ component-reference = ComponentId *( "." ComponentId )
+ ComponentId = identifier /
+ from-beginning /
+ count /
+ from-end / ; extends Clause 14
+ content / ; extends Clause 14
+ select / ; extends Clause 14
+ all
+
+ identifier = lowercase *alphanumeric
+ *(hyphen 1*alphanumeric)
+ alphanumeric = uppercase / lowercase / decimal-digit
+ uppercase = %x41-5A ; "A" to "Z"
+ lowercase = %x61-7A ; "a" to "z"
+ hyphen = "-"
+
+ from-beginning = positive-number
+ count = "0"
+ from-end = "-" positive-number
+ content = %x63.6F.6E.74.65.6E.74 ; "content"
+ select = "(" Value *( "," Value ) ")"
+ all = "*"
+
+
+ positive-number = non-zero-digit *decimal-digit
+
+ decimal-digit = %x30-39 ; "0" to "9"
+ non-zero-digit = %x31-39 ; "1" to "9"
+
+ An <identifier> conforms to the definition of an identifier in ASN.1
+ notation (Clause 11.3 of [11]). It begins with a lowercase letter
+ and is followed by zero or more letters, digits, and hyphens. A
+ hyphen is not permitted to be the last character and a hyphen is not
+ permitted to be followed by another hyphen.
+
+ The <Value> rule is described in [7].
+
+ A component reference is a sequence of one or more ComponentIds where
+ each successive ComponentId identifies either an inner component at
+ the next level of nesting of an ASN.1 combining type, i.e. SET,
+ SEQUENCE, SET OF, SEQUENCE OF, or CHOICE, or a specific type within
+ an ASN.1 open type.
+
+ A component reference is always considered in the context of a
+
+
+
+Legg Expires 19 October 2002 [Page 6]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ particular complex ASN.1 type. When applied to the ASN.1 type the
+ component reference identifies a specific component type. When
+ applied to a value of the ASN.1 type a component reference identifies
+ zero, one or more component values of that component type. The
+ component values are potentially in a DEFAULT value if
+ useDefaultValues is TRUE. The specific component type identified by
+ the component reference determines what matching rules are capable of
+ being used to match the component values.
+
+ An empty string for a component reference, which would identify the
+ whole ASN.1 value, is NOT supported since assertions about a whole
+ value are already possible by the direct application of a matching
+ rule to an attribute value.
+
+ A valid component reference for a particular complex ASN.1 type is
+ constructed by starting with the outermost combining type and
+ repeatedly selecting one of the permissible forms of ComponentId to
+ identify successively deeper nested components. A component
+ reference MAY identify a component with a complex ASN.1 type, i.e. it
+ is NOT required that the component type identified by a component
+ reference be a simple ASN.1 type.
+
+
+5.1.1 Component Type Substitutions
+
+ ASN.1 type notation has a number of constructs for referencing other
+ defined types, and constructs that are irrelevant for matching
+ purposes. These constructs are not represented in a component
+ reference in any way and substitutions of the component type are
+ performed to eliminate them from further consideration. These
+ substitutions automatically occur prior to each ComponentId, whether
+ constructing or interpreting a component reference, but do not occur
+ after the last ComponentId, except as allowed by Section 5.2.
+
+ If the ASN.1 type is an ASN.1 type reference then the component type
+ is taken to be the actual definition on the right hand side of the
+ type assignment for the referenced type.
+
+ If the ASN.1 type is a tagged type then the component type is taken
+ to be the type without the tag.
+
+ If the ASN.1 type is a constrained type (see [11] and [14] for the
+ details of ASN.1 constraint notation) then the component type is
+ taken to be the type without the constraint.
+
+ If the ASN.1 type is an ObjectClassFieldType (Clause 14 of [13]) that
+ denotes a specific ASN.1 type (e.g. MATCHING-RULE.&id denotes the
+ OBJECT IDENTIFIER type) then the component type is taken to be the
+
+
+
+Legg Expires 19 October 2002 [Page 7]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ denoted type. Section 5.1.6 describes the case where the
+ ObjectClassFieldType denotes an open type.
+
+ If the ASN.1 type is a selection type other than one used in the list
+ of components for a SET or SEQUENCE type then the component type is
+ taken to be the selected alternative type from the named CHOICE.
+
+ If the ASN.1 type is a TypeFromObject (Clause 15 of [13]) then the
+ component type is taken to be the denoted type.
+
+ If the ASN.1 type is a ValueSetFromObjects (Clause 15 of [13]) then
+ the component type is taken to be the governing type of the denoted
+ values.
+
+
+5.1.2 Referencing SET, SEQUENCE and CHOICE Components
+
+ If the ASN.1 type is a SET or SEQUENCE type then the <identifier>
+ form of ComponentId MAY be used to identify the component type within
+ that SET or SEQUENCE having that identifier. If <identifier>
+ references an OPTIONAL component type and that component is not
+ present in a particular value then there are no corresponding
+ component values. If <identifier> references a DEFAULT component
+ type and useDefaultValues is TRUE (the default setting for
+ useDefaultValues) and that component is not present in a particular
+ value then the component value is taken to be the default value. If
+ <identifier> references a DEFAULT component type and useDefaultValues
+ is FALSE and that component is not present in a particular value then
+ there are no corresponding component values.
+
+ If the ASN.1 type is a CHOICE type then the <identifier> form of
+ ComponentId MAY be used to identify the alternative type within that
+ CHOICE having that identifier. If <identifier> references an
+ alternative other than the one used in a particular value then there
+ are no corresponding component values.
+
+ The COMPONENTS OF notation in Clause 24 of [11] augments the defined
+ list of components in a SET or SEQUENCE type by including all the
+ components of another defined SET or SEQUENCE type respectively.
+ These included components are referenced directly by identifier as
+ though they were defined in-line in the SET or SEQUENCE type
+ containing the COMPONENTS OF notation.
+
+ The SelectionType (Clause 29 of [11]), when used in the list of
+ components for a SET or SEQUENCE type, includes a single component
+ from a defined CHOICE type. This included component is referenced
+ directly by identifier as though it was defined in-line in the SET or
+ SEQUENCE type.
+
+
+
+Legg Expires 19 October 2002 [Page 8]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ The REAL type is treated as though it is the SEQUENCE type defined in
+ Clause 20.5 of [11].
+
+ The EMBEDDED PDV type is treated as though it is the SEQUENCE type
+ defined in Clause 32.5 of [11].
+
+ The EXTERNAL type is treated as though it is the SEQUENCE type
+ defined in Clause 33.5 of [11].
+
+ The unrestricted CHARACTER STRING type is treated as though it is the
+ SEQUENCE type defined in Clause 39.5 of [11].
+
+ The INSTANCE OF type is treated as though it is the SEQUENCE type
+ defined in Annex C of [13].
+
+ The <identifier> form MUST NOT be used on any other ASN.1 type.
+
+
+5.1.3 Referencing SET OF and SEQUENCE OF Components
+
+ If the ASN.1 type is a SET OF or SEQUENCE OF type then the
+ <from-beginning>, <from-end>, <count> and <all> forms of ComponentId
+ can be used.
+
+ The <from-beginning> form of ComponentId MAY be used to identify one
+ instance (i.e. value) of the component type of the SET OF or SEQUENCE
+ OF type (e.g. if Foo ::= SET OF Bar, then Bar is the component type),
+ where the instances are numbered from one upwards. If
+ <from-beginning> references a higher numbered instance than the last
+ instance in a particular value of the SET OF or SEQUENCE OF type then
+ there is no corresponding component value.
+
+ The <from-end> form of ComponentId MAY be used to identify one
+ instance of the component type of the SET OF or SEQUENCE OF type,
+ where "-1" is the last instance, "-2" is the second last instance,
+ and so on. If <from-end> references a lower numbered instance than
+ the first instance in a particular value of the SET OF or SEQUENCE OF
+ type then there is no corresponding component value.
+
+ The <count> form of ComponentId identifies a notional count of the
+ number of instances of the component type in a value of the SET OF or
+ SEQUENCE OF type. This count is not explicitly represented but for
+ matching purposes it has an assumed ASN.1 type of INTEGER (0..MAX).
+ A ComponentId of the <count> form MUST be the last ComponentId in a
+ component reference.
+
+ The <all> form of ComponentId MAY be used to simultaneously identify
+ all instances of the component type of the SET OF or SEQUENCE OF
+
+
+
+Legg Expires 19 October 2002 [Page 9]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ type. It is through the <all> form that a component reference can
+ identify more than one component value. However, if a particular
+ value of the SET OF or SEQUENCE OF type is an empty list there are no
+ corresponding component values.
+
+ Where multiple component values are identified, the remaining
+ ComponentIds in the component reference, if any, can identify zero,
+ one or more subcomponent values for each of the higher level
+ component values.
+
+ The corresponding ASN.1 type for the <from-beginning>, <from-end>,
+ and <all> forms of ComponentId is the component type of the SET OF or
+ SEQUENCE OF type.
+
+ The <from-beginning>, <count>, <from-end> and <all> forms MUST NOT be
+ used on ASN.1 types other than SET OF or SEQUENCE OF.
+
+
+5.1.4 Referencing Components of Parameterized Types
+
+ A component reference cannot be formed for a parameterized type
+ unless the type has been used with actual parameters, in which case
+ the type is treated as though the DummyReferences [15] have been
+ substituted with the actual parameters.
+
+
+5.1.5 Component Referencing Example
+
+ Consider the following ASN.1 type definitions.
+
+ ExampleType ::= SEQUENCE {
+ part1 [0] INTEGER,
+ part2 [1] ExampleSet,
+ part3 [2] SET OF OBJECT IDENTIFIER,
+ part4 [3] ExampleChoice }
+
+ ExampleSet ::= SET {
+ option PrintableString,
+ setting BOOLEAN }
+
+ ExampleChoice ::= CHOICE {
+ eeny-meeny BIT STRING,
+ miney-mo OCTET STRING }
+
+ Following are component references constructed with respect to the
+ type ExampleType.
+
+ The component reference "part1" identifies a component of a value of
+
+
+
+Legg Expires 19 October 2002 [Page 10]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ ExampleType having the ASN.1 tagged type [0] INTEGER.
+
+ The component reference "part2" identifies a component of a value of
+ ExampleType having the ASN.1 type of [1] ExampleSet
+
+ The component reference "part2.option" identifies a component of a
+ value of ExampleType having the ASN.1 type of PrintableString. A
+ ComponentAssertion could also be applied to a value of ASN.1 type
+ ExampleSet, in which case the component reference "option" would
+ identify the same kind of information.
+
+ The component reference "part3" identifies a component of a value of
+ ExampleType having the ASN.1 type of [2] SET OF OBJECT IDENTIFIER.
+
+ The component reference "part3.2" identifies the second instance of
+ the part3 SET OF. The instance has the ASN.1 type of OBJECT
+ IDENTIFIER.
+
+ The component reference "part3.0" identifies the count of the number
+ of instances in the part3 SET OF. The count has the corresponding
+ ASN.1 type of INTEGER (0..MAX).
+
+ The component reference "part3.*" identifies all the instances in the
+ part3 SET OF. Each instance has the ASN.1 type of OBJECT IDENTIFIER.
+
+ The component reference "part4" identifies a component of a value of
+ ExampleType having the ASN.1 type of [3] ExampleChoice.
+
+ The component reference "part4.miney-mo" identifies a component of a
+ value of ExampleType having the ASN.1 type of OCTET STRING.
+
+
+5.1.6 Referencing Components of Open Types
+
+ If a sequence of ComponentIds identifies an ObjectClassFieldType
+ denoting an open type (e.g. ATTRIBUTE.&Type denotes an open type)
+ then the ASN.1 type of the component varies. An open type is
+ typically constrained by some other component(s) in an outer
+ enclosing type, either formally through the use of a component
+ relation constraint [14], or informally in the accompanying text, so
+ the actual ASN.1 type of a value of the open type will generally be
+ known. The constraint will also limit the range of permissible
+ types. The <select> form of ComponentId MAY be used to identify one
+ of these permissible types in an open type. Subcomponents of that
+ type can then be identified with further ComponentIds.
+
+ The other components constraining the open type are termed the
+ referenced components (using the terminology in [14]). The <select>
+
+
+
+Legg Expires 19 October 2002 [Page 11]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ form contains a list of one or more values which take the place of
+ the value(s) of the referenced component(s) to uniquely identify one
+ of the permissable types of the open type.
+
+ Where the open type is constrained by a component relation
+ constraint, there is a <Value> in the <select> form for each of the
+ referenced components in the component relation constraint, appearing
+ in the same order. The ASN.1 type of each of these values is the
+ same as the ASN.1 type of the corresponding referenced component.
+ The type of a referenced component is potentially any ASN.1 type
+ however it is typically an OBJECT IDENTIFIER or INTEGER, which means
+ that the <Value> in the <select> form of ComponentId will nearly
+ always be an <ObjectIdentifierValue> or <IntegerValue> (see [7]).
+ Furthermore, component relation constraints typically have only one
+ referenced component.
+
+ Where the open type is not constrained by a component relation
+ constraint, the specification introducing the syntax containing the
+ open type SHOULD explicitly nominate the referenced components and
+ their order, so that the <select> form can be used.
+
+ If an instance of <select> contains a value other than the value of
+ the referenced component used in a particular value of the outer
+ enclosing type then there are no corresponding component values for
+ the open type.
+
+
+5.1.6.1 Open Type Referencing Example
+
+ The ASN.1 type AttributeTypeAndValue from [8] describes a single
+ attribute value of a nominated attribute type.
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type ATTRIBUTE.&id ({SupportedAttributes}),
+ value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) }
+
+ ATTRIBUTE.&id denotes an OBJECT IDENTIFIER and
+ ({SupportedAttributes}) constrains the OBJECT IDENTIFIER to be a
+ supported attribute type.
+
+ ATTRIBUTE.&Type denotes an open type, in this case an attribute
+ value, and ({SupportedAttributes}{@type}) is a component relation
+ constraint that constrains the open type to be of the attribute
+ syntax for the attribute type. The component relation constraint
+ references only the "type" component, which has the ASN.1 type of
+ OBJECT IDENTIFIER, thus if the <select> form of ComponentId is used
+ to identify attribute values of specific attribute types it will
+ contain a single OBJECT IDENTIFIER value.
+
+
+
+Legg Expires 19 October 2002 [Page 12]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ The component reference "value" on AttributeTypeAndValue refers to
+ the open type.
+
+ One of the X.500 standard attributes is facsimileTelephoneNumber
+ [10], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is
+ defined to have the following syntax.
+
+ FacsimileTelephoneNumber ::= SEQUENCE {
+ telephoneNumber PrintableString(SIZE(1..ub-telephone-number)),
+ parameters G3FacsimileNonBasicParameters OPTIONAL }
+
+ The component reference "value.(2.5.4.23)" on AttributeTypeAndValue
+ specifies an attribute value with the FacsimileTelephoneNumber
+ syntax.
+
+ The component reference "value.(2.5.4.23).telephoneNumber" on
+ AttributeTypeAndValue identifies the telephoneNumber component of a
+ facsimileTelephoneNumber attribute value. The component reference
+ "value.(facsimileTelephoneNumber)" is equivalent to
+ "value.(2.5.4.23)".
+
+ If the AttributeTypeAndValue ASN.1 value contains an attribute type
+ other than facsimileTelephoneNumber then there are no corresponding
+ component values for the component references "value.(2.5.4.23)" and
+ "value.(2.5.4.23).telephoneNumber".
+
+
+5.1.7 Referencing Contained Types
+
+ Sometimes the contents of a BIT STRING or OCTET STRING value are
+ required to be the encodings of other ASN.1 values of specific ASN.1
+ types. For example, the extnValue component of the Extension type
+ component in the Certificate type [9] is an OCTET STRING that is
+ required to contain a DER encoding of a certificate extension value.
+ It is useful to be able to refer to the embedded encoded value and
+ its components. An embedded encoded value is here referred to as a
+ contained value and its associated type as the contained type.
+
+ If the ASN.1 type is a BIT STRING or OCTET STRING type containing
+ encodings of other ASN.1 values then the <content> form of
+ ComponentId MAY be used to identify the contained type.
+ Subcomponents of that type can then be identified with further
+ ComponentIds.
+
+ The contained type may be (effectively) an open type, constrained by
+ some other component in an outer enclosing type (e.g. in a
+ certificate Extension, extnValue is constrained by the chosen
+ extnId). In these cases the next ComponentId, if any, MUST be of the
+
+
+
+Legg Expires 19 October 2002 [Page 13]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ <select> form.
+
+ For the purpose of building component references, the content of the
+ extnValue OCTET STRING in the Extension type is assumed to be an open
+ type having a notional component relation constraint with the extnId
+ component as the single referenced component, i.e.
+
+ EXTENSION.&ExtnType ({ExtensionSet}{@extnId})
+
+ The data-value component of the associated types for the EXTERNAL,
+ EMBEDDED PDV and CHARACTER STRING types is an OCTET STRING containing
+ the encoding of a data value described by the identification
+ component. For the purpose of building component references, the
+ content of the data-value OCTET STRING in these types is assumed to
+ be an open type having a notional component relation constraint with
+ the identification component as the single referenced component.
+
+
+5.1.7.1 Contained Type Referencing Example
+
+ The Extension ASN.1 type from [9] describes a single certificate
+ extension value of a nominated extension type.
+
+ Extension ::= SEQUENCE {
+ extnId EXTENSION.&id ({ExtensionSet}),
+ critical BOOLEAN DEFAULT FALSE,
+ extnValue OCTET STRING
+ -- contains a DER encoding of a value of type &ExtnType
+ -- for the extension object identified by extnId -- }
+
+ EXTENSION.&id denotes an OBJECT IDENTIFIER and ({ExtensionSet})
+ constrains the OBJECT IDENTIFIER to be the identifier of a supported
+ certificate extension.
+
+ The component reference "extnValue" on Extension refers to a
+ component type of OCTET STRING. The corresponding component values
+ will be OCTET STRING values. The component reference
+ "extnValue.content" on Extension refers to the type of the contained
+ type, which in this case is an open type.
+
+ One of the X.509 [X.509] standard extensions is basicConstraints,
+ which is identified with the OBJECT IDENTIFIER 2.5.29.19 and is
+ defined to have the following syntax.
+
+ BasicConstraintsSyntax ::= SEQUENCE {
+ cA BOOLEAN DEFAULT FALSE,
+ pathLenConstraint INTEGER (0..MAX) OPTIONAL }
+
+
+
+
+Legg Expires 19 October 2002 [Page 14]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ The component reference "extnValue.content.(2.5.29.19)" on Extension
+ specifies a BasicConstraintsSyntax extension value and the component
+ reference "extnValue.content.(2.5.29.19).cA" identifies the cA
+ component of a BasicConstraintsSyntax extension value.
+
+
+5.2 Matching of Components
+
+ The rule in a ComponentAssertion specifies how the zero, one or more
+ component values identified by the component reference are tested by
+ the assertion. Attribute matching rules are used to specify the
+ semantics of the test.
+
+ Each matching rule has a notional set of attribute syntaxes
+ (typically one), defined as ASN.1 types, to which it may be applied.
+ When used in a ComponentAssertion these matching rules apply to the
+ same ASN.1 types, only in this context the corresponding ASN.1 values
+ are not complete attribute values.
+
+ Note that the referenced component type may be a tagged and/or
+ constrained version of the expected attribute syntax (e.g. [0]
+ INTEGER, whereas integerMatch would expect simply INTEGER), or an
+ open type. Additional type substitutions of the kind described in
+ Section 5.1.1 are performed as required to reduce the component type
+ to the same type as the attribute syntax expected by the matching
+ rule. If an open type is encountered the actual ASN.1 type of the
+ component value is substituted before continuing.
+
+ If a matching rule applies to more than one attribute syntax (e.g.
+ objectIdentifierFirstComponentMatch [10]) then the minimum number of
+ substitutions required to conform to any one of those syntaxes are
+ performed. If a matching rule can apply to any attribute syntax
+ (e.g. the allComponentsMatch rule defined in Section 8.2) then the
+ referenced component type is used as is, with no additional
+ substitutions.
+
+ The value in a ComponentAssertion will be of the assertion syntax
+ (i.e. ASN.1 type) required by the chosen matching rule. Note that
+ the assertion syntax of a matching rule is not necessarily the same
+ as the attribute syntax(es) to which the rule may be applied.
+
+ Some matching rules do not have a fixed assertion syntax (e.g.
+ allComponentsMatch). The required assertion syntax is determined in
+ each instance of use by the syntax of the attribute type to which the
+ matching rule is applied. For these rules the ASN.1 type of the
+ referenced component is used in place of an attribute syntax to
+ decide the required assertion syntax.
+
+
+
+
+Legg Expires 19 October 2002 [Page 15]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ The ComponentAssertion is undefined if:
+
+ a) the matching rule in the ComponentAssertion is not known to the
+ evaluating procedure,
+
+ b) if no part of the component reference identifies an open type and
+ the matching rule is not applicable to the referenced component
+ type, even with the additional type substitutions,
+
+ c) the value in the ComponentAssertion does not conform to the
+ assertion syntax defined for the matching rule,
+
+ d) an open type in the tested value cannot be decoded, or
+
+ e) the implementation does not support the particular combination of
+ component reference and matching rule.
+
+ If the ComponentAssertion is not undefined then the
+ ComponentAssertion evaluates to TRUE if there is at least one
+ component value for which the matching rule applied to that component
+ value returns TRUE, and evaluates to FALSE otherwise (which includes
+ the case where there are no component values).
+
+ If some part of the component reference identifies an open type and
+ the matching rule is not applicable to the referenced component type
+ the ComponentAssertion evaluates to FALSE.
+
+
+5.2.1 Applicability of Existing Matching Rules
+
+5.2.1.1 String Matching
+
+ ASN.1 has a number of built in restricted character string types with
+ different character sets and/or different character encodings. A
+ directory user generally has little interest in the particular
+ character set or encoding used to represent a character string
+ component value, and some directory server implementations make no
+ distinction between the different string types in their internal
+ representation of values. So rather than define string matching
+ rules for each of the restricted character string types, the existing
+ case ignore and case exact string matching rules are extended to
+ apply to component values of any of the restricted character string
+ types and any ChoiceOfStrings type [7], in addition to component
+ values of the DirectoryString type. This extension is only for the
+ purposes of component matching described in this document.
+
+ The relevant string matching rules are: caseIgnoreMatch,
+ caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, caseExactMatch,
+
+
+
+Legg Expires 19 October 2002 [Page 16]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ caseExactOrderingMatch and caseExactSubstringsMatch. The relevant
+ restricted character string types are: NumericString,
+ PrintableString, VisibleString, IA5String, UTF8String, BMPString,
+ UniversalString, TeletexString, VideotexString, GraphicString and
+ GeneralString. A ChoiceOfStrings type is a purely syntactic CHOICE
+ of these ASN.1 string types. Note that [7] declares each and every
+ use of the DirectoryString{} parameterized type to be a
+ ChoiceOfStrings type.
+
+ The assertion syntax of the string matching rules is still
+ DirectoryString regardless of the string syntax of the component
+ being matched. Thus an implementation will be called upon to compare
+ a DirectoryString value to a value of one of the restricted character
+ string types, or a ChoiceOfStrings type. As is the case when
+ comparing two DirectoryStrings where the chosen alternatives are of
+ different string types, the comparison proceeds so long as the
+ corresponding characters are representable in both character sets.
+ Otherwise matching returns FALSE.
+
+
+5.2.1.2 Telephone Number Matching
+
+ Early editions of X.520 [10] gave the syntax of the telephoneNumber
+ attribute as a constrained PrintableString. The fourth edition of
+ X.520 equates the ASN.1 type name TelephoneNumber to the constrained
+ PrintableString and uses TelephoneNumber as the attribute and
+ assertion syntax. For the purposes of component matching,
+ telephoneNumberMatch and telephoneNumberSubstringsMatch are permitted
+ to be applied to any PrintableString value, as well as to
+ TelephoneNumber values.
+
+
+5.2.1.3 Distinguished Name Matching
+
+ The DistinguishedName type is defined by assignment to be the same as
+ the RDNSequence type, however RDNSequence is sometimes directly used
+ in other type definitions. For the purposes of component matching,
+ distinguishedNameMatch is also permitted to be applied to values of
+ the RDNSequence type.
+
+
+5.2.2 Additional Useful Matching Rules
+
+ This section defines additional matching rules that may prove useful
+ in ComponentAssertions. These rules MAY also be used in
+ extensibleMatch search filters [3].
+
+
+
+
+
+Legg Expires 19 October 2002 [Page 17]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+5.2.2.1 The rdnMatch Matching Rule
+
+ The distinguishedNameMatch matching rule can match whole
+ distinguished names but it is sometimes useful to be able to match
+ specific RDNs in a DN without regard for the other RDNs in the DN.
+ The rdnMatch matching rule allows component RDNs of a DN to be
+ tested.
+
+ The LDAP-style definitions for rdnMatch and its assertion syntax are:
+
+ ( 1.2.36.79672281.1.13.3 NAME 'rdnMatch'
+ SYNTAX 1.2.36.79672281.1.5.0 )
+
+ ( 1.2.36.79672281.1.5.0 DESC 'RDN' )
+
+ The LDAP-specific encoding for a value of the RDN syntax is given by
+ the <RelativeDistinguishedNameValue> rule in [7].
+
+ The X.500-style definition for rdnMatch is:
+
+ rdnMatch MATCHING-RULE ::= {
+ SYNTAX RelativeDistinguishedName
+ ID { 1 2 36 79672281 1 13 3 } }
+
+ The rdnMatch rule evaluates to true if the component value and
+ assertion value are the same RDN, using the same RDN comparison
+ method as distinguishedNameMatch.
+
+ When using rdnMatch to match components of DNs it is important to
+ note that the LDAP-specific encoding of a DN [5] reverses the order
+ of the RDNs. So for the DN represented in LDAP as "cn=Steven
+ Legg,o=Adacel,c=AU", the RDN "cn=Steven Legg" corresponds to the
+ component reference "3", or alternatively, "-1".
+
+
+5.2.2.2 The presentMatch Matching Rule
+
+ At times it would be useful to test not if a specific value of a
+ particular component is present, but whether any value of a
+ particular component is present. The presentMatch matching rule
+ allows the presence of a particular component value to be tested.
+
+ The LDAP-style definitions for presentMatch and its assertion syntax
+ are:
+
+ ( 1.2.36.79672281.1.13.5 NAME 'presentMatch'
+ SYNTAX 1.2.36.79672281.1.5.1 )
+
+
+
+
+Legg Expires 19 October 2002 [Page 18]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ ( 1.2.36.79672281.1.5.1 DESC 'NULL' )
+
+ The LDAP-specific encoding for a value of the NULL syntax is given by
+ the <NullValue> rule in [7].
+
+ The X.500-style definition for presentMatch is:
+
+ presentMatch MATCHING-RULE ::= {
+ SYNTAX NULL
+ ID { 1 2 36 79672281 1 13 5 } }
+
+ When used in a extensible match filter item, presentMatch behaves
+ like the "present" case of a regular search filter. In a
+ ComponentAssertion, presentMatch evaluates to TRUE if and only if the
+ component reference identifies one or more component values,
+ regardless of the actual component value contents. Note that if
+ useDefaultValues is TRUE then the identified component values may be
+ (part of) a DEFAULT value.
+
+ The notional count referenced by the <count> form of ComponentId is
+ taken to be present if the SET OF value is present, and absent
+ otherwise. Note that in ASN.1 notation an absent SET OF value is
+ distinctly different from a SET OF value that is present but empty.
+ It is up to the specification using the ASN.1 notation to decide
+ whether the distinction matters. Often an empty SET OF component and
+ an absent SET OF component are treated as semantically equivalent.
+ If a SET OF value is present, but empty, a presentMatch on the SET OF
+ component SHALL return TRUE and the notional count SHALL be regarded
+ as present and equal to zero.
+
+
+5.2.3 Summary of Useful Matching Rules
+
+ The following is a non-exhaustive list of useful matching rules and
+ the ASN.1 types to which they can be applied, taking account of all
+ the extensions described in Section 5.2.1, and the new matching rules
+ defined in Section 5.2.2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 19 October 2002 [Page 19]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ +================================+==============================+
+ | Matching Rule | ASN.1 Type |
+ +================================+==============================+
+ | bitStringMatch | BIT STRING |
+ +--------------------------------+------------------------------+
+ | booleanMatch | BOOLEAN |
+ +--------------------------------+------------------------------+
+ | caseIgnoreMatch | NumericString |
+ | caseIgnoreOrderingMatch | PrintableString |
+ | caseIgnoreSubstringsMatch | VisibleString (ISO646String) |
+ | caseExactMatch | IA5String |
+ | caseExactOrderingMatch | UTF8String |
+ | caseExactSubstringsMatch | BMPString (UCS-2, UNICODE) |
+ | | UniversalString (UCS-4) |
+ | | TeletexString (T61String) |
+ | | VideotexString |
+ | | GraphicString |
+ | | GeneralString |
+ | | any ChoiceOfStrings type |
+ +--------------------------------+------------------------------+
+ | caseIgnoreIA5Match | IA5String |
+ | caseExactIA5Match | |
+ +--------------------------------+------------------------------+
+ | distinguishedNameMatch | DistinguishedName |
+ | | RDNSequence |
+ +--------------------------------+------------------------------+
+ | generalizedTimeMatch | GeneralizedTime |
+ | generalizedTimeOrderingMatch | |
+ +--------------------------------+------------------------------+
+ | integerMatch | INTEGER |
+ | integerOrderingMatch | |
+ +--------------------------------+------------------------------+
+ | numericStringMatch | NumericString |
+ | numericStringOrderingMatch | |
+ | numericStringSubstringsMatch | |
+ +--------------------------------+------------------------------+
+ | objectIdentifierMatch | OBJECT IDENTIFIER |
+ +--------------------------------+------------------------------+
+ | octetStringMatch | OCTET STRING |
+ | octetStringOrderingMatch | |
+ | octetStringSubstringsMatch | |
+ +--------------------------------+------------------------------+
+ | presentMatch | any ASN.1 type |
+ +--------------------------------+------------------------------+
+ | rdnMatch | RelativeDistinguishedName |
+ +--------------------------------+------------------------------+
+ | telephoneNumberMatch | PrintableString |
+ | telephoneNumberSubstringsMatch | TelephoneNumber |
+
+
+
+Legg Expires 19 October 2002 [Page 20]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ +--------------------------------+------------------------------+
+ | uTCTimeMatch | UTCTime |
+ | uTCTimeOrderingMatch | |
+ +--------------------------------+------------------------------+
+
+ Note that the allComponentsMatch matching rule defined in Section 8.2
+ can be used for equality matching of values of the ENUMERATED, NULL,
+ REAL and RELATIVE-OID ASN.1 types, among other things.
+
+
+6. ComponentFilter
+
+ The ComponentAssertion allows the value(s) of any one component type
+ in a complex ASN.1 type to be matched, but there is often a desire to
+ match the values of more than one component type. A ComponentFilter
+ is an assertion about the presence, or values of, multiple components
+ within an ASN.1 value.
+
+ The ComponentFilter assertion, an expression of ComponentAssertions,
+ evaluates to either TRUE, FALSE or undefined for each tested ASN.1
+ value.
+
+ A ComponentFilter is described by the following ASN.1 type (assumed
+ to be defined with "EXPLICIT TAGS" in force):
+
+ ComponentFilter ::= CHOICE {
+ item [0] ComponentAssertion,
+ and [1] SEQUENCE OF ComponentFilter,
+ or [2] SEQUENCE OF ComponentFilter,
+ not [3] ComponentFilter }
+
+ Note: despite the use of SEQUENCE OF instead of SET OF for the "and"
+ and "or" alternatives in ComponentFilter, the order of the component
+ filters is not significant.
+
+ A ComponentFilter that is a ComponentAssertion evaluates to TRUE if
+ the ComponentAssertion is TRUE, evaluates to FALSE if the
+ ComponentAssertion is FALSE, and evaluates to undefined otherwise.
+
+ The "and" of a sequence of component filters evaluates to TRUE if the
+ sequence is empty or if each component filter evaluates to TRUE,
+ evaluates to FALSE if at least one component filter is FALSE, and
+ evaluates to undefined otherwise.
+
+ The "or" of a sequence of component filters evaluates to FALSE if the
+ sequence is empty or if each component filter evaluates to FALSE,
+ evaluates to TRUE if at least one component filter is TRUE, and
+ evaluates to undefined otherwise.
+
+
+
+Legg Expires 19 October 2002 [Page 21]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ The "not" of a component filter evaluates to TRUE if the component
+ filter is FALSE, evaluates to FALSE if the component filter is TRUE,
+ and evaluates to undefined otherwise.
+
+
+7. The componentFilterMatch Matching Rule
+
+ The componentFilterMatch matching rule allows a ComponentFilter to be
+ applied to an attribute value. The result of the matching rule is
+ the result of applying the ComponentFilter to the attribute value.
+
+ The LDAP-style definitions for componentFilterMatch and its assertion
+ syntax are:
+
+ ( 1.2.36.79672281.1.13.2 NAME 'componentFilterMatch'
+ SYNTAX 1.2.36.79672281.1.5.2 )
+
+ ( 1.2.36.79672281.1.5.2 DESC 'ComponentFilter' )
+
+ The LDAP-specific encoding for the ComponentFilter assertion syntax
+ is specified by the Generic String Encoding Rules in [7].
+
+ As a convenience to implementors, an equivalent ABNF description of
+ the GSER encoding for ComponentFilter is provided here. In the event
+ that there is a discrepancy between this ABNF and the encoding
+ determined by [7], [7] is to be taken as definitive. The GSER
+ encoding of a ComponentFilter is described by the following
+ equivalent ABNF:
+
+ ComponentFilter = filter-item /
+ and-filter /
+ or-filter /
+ not-filter
+
+ filter-item = item-chosen ComponentAssertion
+ and-filter = and-chosen SequenceOfComponentFilter
+ or-filter = or-chosen SequenceOfComponentFilter
+ not-filter = not-chosen ComponentFilter
+
+ item-chosen = %x69.74.65.6D.3A ; "item:"
+ and-chosen = %x61.6E.64.3A ; "and:"
+ or-chosen = %x6F.72.3A ; "or:"
+ not-chosen = %x6E.6F.74.3A ; "not:"
+
+ SequenceOfComponentFilter = "{" [ sp ComponentFilter
+ *( "," sp ComponentFilter) ] sp "}"
+
+ ComponentAssertion = "{" sp component ","
+
+
+
+Legg Expires 19 October 2002 [Page 22]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ [ sp useDefaultValues "," ]
+ sp rule ","
+ sp assertion-value sp "}"
+ component = component-label msp
+ dquote component-reference dquote
+ useDefaultValues = use-defaults-label msp BooleanValue
+ rule = rule-label msp ObjectIdentifierValue
+ assertion-value = value-label msp Value
+
+ component-label = %x63.6F.6D.70.6F.6E.65.6E.74 ; "component"
+ use-defaults-label = %x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75
+ %x65.73 ; "useDefaultValues"
+ rule-label = %x72.75.6C.65 ; "rule"
+ value-label = %x76.61.6C.75.65 ; "value"
+
+ sp = *%x20 ; zero, one or more space characters
+ msp = 1*%x20 ; one or more space characters
+ dquote = %x22 ; " (double quote)
+
+ The ABNF for <Value>, <ObjectIdentifierValue> and <BooleanValue> is
+ defined in [7].
+
+ The ABNF descriptions of LDAP-specific encodings for attribute
+ syntaxes typically do not clearly or consistently delineate the
+ component parts of an attribute value. A regular and uniform
+ character string encoding for arbitrary component data types is
+ needed to encode the assertion value in a ComponentAssertion. The
+ <Value> rule from [7] provides a human readable text encoding for a
+ component value of any arbitrary ASN.1 type.
+
+ The X.500-style definition [8] for componentFilterMatch is:
+
+ componentFilterMatch MATCHING-RULE ::= {
+ SYNTAX ComponentFilter
+ ID { 1 2 36 79672281 1 13 2 } }
+
+ A ComponentAssertion can potentially use any matching rule, including
+ componentFilterMatch, so componentFilterMatch MAY be nested. The
+ component references in a nested componentFilterMatch are relative to
+ the component corresponding to the containing ComponentAssertion. In
+ Section 9, an example search on the seeAlso attribute shows this
+ usage.
+
+
+8. Equality Matching of Complex Components
+
+ It is possible to test if an attribute value of a complex ASN.1
+ syntax is the same as some purported (i.e. assertion) value by using
+
+
+
+Legg Expires 19 October 2002 [Page 23]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ a complicated ComponentFilter that tests if corresponding components
+ are the same. However, it would be more convenient to be able to
+ present a whole assertion value to a matching rule that could do the
+ component-wise comparison of an attribute value with the assertion
+ value for any arbitrary attribute syntax. Similarly, the ability to
+ do a straightforward equality comparison of a component value that is
+ itself of a complex ASN.1 type would also be convenient.
+
+ It would be difficult to define a single matching rule that
+ simultaneously satisfies all notions of what the equality matching
+ semantics should be. For example, in some instances a case sensitive
+ comparison of string components may be preferable to a case
+ insensitive comparison. Therefore a basic equality matching rule,
+ allComponentsMatch, is defined in Section 8.2, and the means to
+ derive new matching rules from it with slightly different equality
+ matching semantics are described in Section 8.3.
+
+ The directoryComponentsMatch defined in Section 8.4 is a derivation
+ of allComponentsMatch that suits typical uses of the directory.
+ Other specifications are free to derive new rules from
+ allComponentsMatch or directoryComponentsMatch, that suit their usage
+ of the directory.
+
+ The allComponentsMatch rule, the directoryComponentsMatch rule and
+ any matching rules derived from them are collectively called
+ component equality matching rules.
+
+
+8.1 The OpenAssertionType Syntax
+
+ The component equality matching rules have a variable assertion
+ syntax. In X.500 this is indicated by omitting the optional SYNTAX
+ field in the MATCHING-RULE information object. The assertion syntax
+ then defaults to the target attribute's syntax in actual usage,
+ unless the description of the matching rule says otherwise. The
+ SYNTAX field in the LDAP-specific encoding of a
+ MatchingRuleDescription is mandatory, so the OpenAssertionType syntax
+ is defined to fill the same role. That is, the OpenAssertionType
+ syntax is semantically equivalent to an omitted SYNTAX field in an
+ X.500 MATCHING-RULE information object. OpenAssertionType MUST NOT
+ be used as the attribute syntax in an attribute type definition.
+
+ Unless explicitly varied by the description of a particular matching
+ rule, if an OpenAssertionType assertion value appears in a
+ ComponentAssertion its LDAP-specific encoding is described by the
+ <Value> rule in [7], otherwise its LDAP-specific encoding is the
+ encoding defined for the syntax of the attribute type to which the
+ matching rule with the OpenAssertionType assertion syntax is applied.
+
+
+
+Legg Expires 19 October 2002 [Page 24]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ The LDAP definition for the OpenAssertionType syntax is:
+
+ ( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' )
+
+
+8.2 The allComponentsMatch Matching Rule
+
+ The LDAP-style definition for allComponentsMatch is:
+
+ ( 1.2.36.79672281.1.13.6 NAME 'allComponentsMatch'
+ SYNTAX 1.2.36.79672281.1.5.3 )
+
+ The X.500-style definition for allComponentsMatch is:
+
+ allComponentsMatch MATCHING-RULE ::= {
+ ID { 1 2 36 79672281 1 13 6 } }
+
+ When allComponentsMatch is used in a ComponentAssertion the assertion
+ syntax is the same as the ASN.1 type of the identified component.
+ Otherwise, the assertion syntax of allComponentsMatch is the same as
+ the attribute syntax of the attribute to which the matching rule is
+ applied.
+
+ Broadly speaking, this matching rule evaluates to true if and only if
+ corresponding components of the assertion value and the attribute or
+ component value are the same.
+
+ In detail, equality is determined by the following cases applied
+ recursively.
+
+ a) Two values of a SET or SEQUENCE type are the same if and only if,
+ for each component type, the corresponding component values are
+ either,
+
+ 1) both absent,
+
+ 2) both present and the same, or
+
+ 3) absent or the same as the DEFAULT value for the component, if a
+ DEFAULT value is defined.
+
+ Values of an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER
+ STRING, or INSTANCE OF type are compared according to their
+ respective SEQUENCE type (see Section 5.1.2).
+
+ b) Two values of a SEQUENCE OF type are the same if and only if, the
+ values have the same number of (possibly duplicated) instances and
+ corresponding instances are the same.
+
+
+
+Legg Expires 19 October 2002 [Page 25]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ c) Two values of a SET OF type are the same if and only if, the
+ values have the same number of instances and each distinct
+ instance occurs in both values the same number of times, i.e. both
+ values have the same instances, including duplicates, but in any
+ order.
+
+ d) Two values of a CHOICE type are the same if and only if, both
+ values are of the same chosen alternative and the component values
+ are the same.
+
+ e) Two BIT STRING values are the same if and only if the values have
+ the same number of bits and corresponding bits are the same. If
+ the BIT STRING type is defined with a named bit list then trailing
+ zero bits in the values are treated as absent for the purposes of
+ this comparison.
+
+ f) Two BOOLEAN values are the same if and only if both are TRUE or
+ both are FALSE.
+
+ g) Two values of a string type are the same if and only if the values
+ have the same number of characters and corresponding characters
+ are the same. Letter case is significant. For the purposes of
+ allComponentsMatch, the string types are NumericString,
+ PrintableString, TeletexString (T61String), VideotexString,
+ IA5String, GraphicString, VisibleString (ISO646String),
+ GeneralString, UniversalString, BMPString, UTF8String,
+ GeneralizedTime, UTCTime and ObjectDescriptor.
+
+ h) Two INTEGER values are the same if and only if the integers are
+ equal.
+
+ i) Two ENUMERATED values are the same if and only if the enumeration
+ item identifiers are the same (equivalently, if the integer values
+ associated with the identifiers are equal).
+
+ j) Two NULL values are always the same, unconditionally.
+
+ k) Two OBJECT IDENTIFIER values are the same if and only if the
+ values have the same number of arcs and corresponding arcs are the
+ same.
+
+ l) Two OCTET STRING values are the same if and only if the values
+ have the same number of octets and corresponding octets are the
+ same.
+
+ m) Two REAL values are the same if and only if they are both the same
+ special value, or neither is a special value and they have the
+ same base and represent the same real number. The special values
+
+
+
+Legg Expires 19 October 2002 [Page 26]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ for REAL are zero, PLUS-INFINITY and MINUS-INFINITY.
+
+ n) Two RELATIVE-OID [12] values are the same if and only if the
+ values have the same number of arcs and corresponding arcs are the
+ same. The respective starting nodes for the RELATIVE-OID values
+ are disregarded in the comparison, i.e. they are assumed to be the
+ same.
+
+ o) Two values of an open type are the same if and only if both are of
+ the same ASN.1 type and are the same according to that type.
+
+ Tags and constraints, being part of the type definition and not part
+ of the abstract values, are ignored for matching purposes.
+
+ The allComponentsMatch rule MAY be used as the defined equality
+ matching rule for an attribute.
+
+
+8.3 Deriving Component Equality Matching Rules
+
+ A new component equality matching rule with more refined matching
+ semantics MAY be derived from allComponentsMatch, or any other
+ component equality matching rule, using the convention described in
+ this section.
+
+ The matching behaviour of a derived component equality matching rule
+ is specified by nominating, for each of one or more identified
+ components, a commutative equality matching rule that will be used to
+ match values of that component. This overrides the matching that
+ would otherwise occur for values of that component using the base
+ rule for the derivation. These overrides can be conveniently
+ represented as rows in a table of the following form.
+
+ Component | Matching Rule
+ ============+===============
+ |
+ |
+
+ Usually, all component values of a particular ASN.1 type are to be
+ matched the same way. An ASN.1 type reference (e.g.
+ DistinguishedName) or an ASN.1 built-in type name (e.g. INTEGER) in
+ the Component column of the table specifies that the nominated
+ equality matching rule is to be applied to all values of the named
+ type, regardless of context.
+
+ An ASN.1 type reference with a component reference appended
+ (separated by a ".") specifies that the nominated matching rule
+ applies only to the identified components of values of the named
+
+
+
+Legg Expires 19 October 2002 [Page 27]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ type. Other component values that happen to be of the same ASN.1
+ type are not selected.
+
+ Additional type substitutions as described in Section 5.2 are assumed
+ to be performed to align the component type with the matching rule
+ assertion syntax.
+
+ Conceptually, the rows in a table for the base rule are appended to
+ the rows in the table for a derived rule for the purpose of deciding
+ the matching semantics of the derived rule. Notionally,
+ allComponentsMatch has an empty table.
+
+ A row specifying values of an outer containing type (e.g.
+ DistinguishedName) takes precedence over a row specifying values of
+ an inner component type (e.g. RelativeDistinguishedName), regardless
+ of their order in the table. Specifying a row for component values
+ of an inner type is only useful if a value of the type can also
+ appear on its own, or as a component of values of a different outer
+ type. For example, if there is a row for DistinguishedName then a
+ row for RelativeDistinguishedName can only ever apply to
+ RelativeDistinguishedName component values that are not part of a
+ DistinguishedName. A row for values of an outer type in the table
+ for the base rule takes precedence over a row for values of an inner
+ type in the table for the derived rule.
+
+ Where more than one row applies to a particular component value the
+ earlier row takes precedence over the later row. Thus rows in the
+ table for the derived rule take precedence over any rows for the same
+ component in the table for the base rule.
+
+
+8.4 The directoryComponentsMatch Matching Rule
+
+ The directoryComponentsMatch matching rule is derived from the
+ allComponentsMatch matching rule.
+
+ The LDAP-style definition for directoryComponentsMatch is:
+
+ ( 1.2.36.79672281.1.13.7 NAME 'directoryComponentsMatch'
+ SYNTAX 1.2.36.79672281.1.5.3 )
+
+ The X.500-style definition for directoryComponentsMatch is:
+
+ directoryComponentsMatch MATCHING-RULE ::= {
+ ID { 1 2 36 79672281 1 13 7 } }
+
+ The matching semantics of directoryComponentsMatch are described by
+ the following table, using the convention described in Section 8.3.
+
+
+
+Legg Expires 19 October 2002 [Page 28]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ ASN.1 Type | Matching Rule
+ =========================================+========================
+ RDNSequence | distinguishedNameMatch
+ RelativeDistinguishedName | rdnMatch
+ TelephoneNumber | telephoneNumberMatch
+ FacsimileTelephoneNumber.telephoneNumber | telephoneNumberMatch
+ NumericString | numericStringMatch
+ GeneralizedTime | generalizedTimeMatch
+ UTCTime | uTCTimeMatch
+ DirectoryString{} | caseIgnoreMatch
+ BMPString | caseIgnoreMatch
+ GeneralString | caseIgnoreMatch
+ GraphicString | caseIgnoreMatch
+ IA5String | caseIgnoreMatch
+ PrintableString | caseIgnoreMatch
+ TeletexString | caseIgnoreMatch
+ UniversalString | caseIgnoreMatch
+ UTF8String | caseIgnoreMatch
+ VideotexString | caseIgnoreMatch
+ VisibleString | caseIgnoreMatch
+
+ Notes.
+
+ 1) The DistinguishedName type is defined by assignment to be the same
+ as the RDNSequence type. Some types (e.g. Name and LocalName)
+ directly reference RDNSequence rather than DistinguishedName.
+ Specifying RDNSequence captures all these DN-like types.
+
+ 2) A RelativeDistinguishedName value is only matched by rdnMatch if
+ it is not part of an RDNSequence value.
+
+ 3) The telephone number component of the FacsimileTelephoneNumber
+ ASN.1 type [10] is defined as a constrained PrintableString.
+ PrintableString component values that are part of a
+ FacsimileTelephoneNumber value can be identified separately from
+ other components of PrintableString type by the specifier
+ FacsimileTelephoneNumber.telephoneNumber, so that
+ telephoneNumberMatch can be selectively applied. The fourth
+ edition of X.520 defines the telephoneNumber component of
+ FacsimileTelephoneNumber to be of the type TelephoneNumber, making
+ the row for FacsimileTelephoneNumber.telephoneNumber components
+ redundant.
+
+ The directoryComponentsMatch rule MAY be used as the defined equality
+ matching rule for an attribute.
+
+
+9. Component Matching Examples
+
+
+
+Legg Expires 19 October 2002 [Page 29]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ This section contains examples of search filters using the
+ componentFilterMatch matching rule. The filters are described using
+ the string representation of LDAP search filters from [17]. Note
+ that [17] requires asterisks to be escaped in assertion values (in
+ these examples the assertion values are all <ComponentAssertion>
+ encodings). The asterisks have not been escaped in these examples
+ for the sake of clarity, and to avoid confusing the LDAP protocol
+ representation of search filter assertion values, where such escaping
+ does not apply. Line breaks and indenting have been added only as an
+ aid to readability.
+
+ The example search filters are all single extensible match filter
+ items, though there is no reason why componentFilterMatch can't be
+ used in more complicated search filters.
+
+ The first examples describe searches over the objectClasses schema
+ operational attribute, which has an attribute syntax described by the
+ ASN.1 type ObjectClassDescription [8], and holds the definitions of
+ the object classes known to a directory server. The definition of
+ ObjectClassDescription is as follows:
+
+ ObjectClassDescription ::= SEQUENCE {
+ identifier OBJECT-CLASS.&id,
+ name SET OF DirectoryString {ub-schema} OPTIONAL,
+ description DirectoryString {ub-schema} OPTIONAL,
+ obsolete BOOLEAN DEFAULT FALSE,
+ information [0] ObjectClassInformation }
+
+ ObjectClassInformation ::= SEQUENCE {
+ subclassOf SET OF OBJECT-CLASS.&id OPTIONAL,
+ kind ObjectClassKind DEFAULT structural,
+ mandatories [3] SET OF ATTRIBUTE.&id OPTIONAL,
+ optionals [4] SET OF ATTRIBUTE.&id OPTIONAL }
+
+ ObjectClassKind ::= ENUMERATED {
+ abstract (0),
+ structural (1),
+ auxiliary (2) }
+
+ OBJECT-CLASS.&id and ATTRIBUTE.&id are equivalent to the OBJECT
+ IDENTIFIER ASN.1 type. A value of OBJECT-CLASS.&id is an OBJECT
+ IDENTIFIER for an object class. A value of ATTRIBUTE.&id is an
+ OBJECT IDENTIFIER for an attribute type.
+
+ The following search filter finds the object class definition for the
+ object class identified by the OBJECT IDENTIFIER 2.5.6.18:
+
+ (objectClasses:componentFilterMatch:=
+
+
+
+Legg Expires 19 October 2002 [Page 30]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ item:{ component "identifier",
+ rule objectIdentifierMatch, value 2.5.6.18 })
+
+ A match on the "identifier" component of objectClasses values is
+ equivalent to the objectIdentifierFirstComponentMatch matching rule
+ applied to attribute values of the objectClasses attribute type. The
+ componentFilterMatch matching rule subsumes the functionality of the
+ objectIdentifierFirstComponentMatch, integerFirstComponentMatch and
+ directoryStringFirstComponentMatch matching rules.
+
+ The following search filter finds the object class definition for the
+ object class called foobar:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "name.*",
+ rule caseIgnoreMatch, value "foobar" })
+
+ An object class definition can have multiple names and the above
+ filter will match an objectClasses value if any one of the names is
+ "foobar".
+
+ The component reference "name.0" identifies the notional count of the
+ number of names in an object class definition. The following search
+ filter finds object class definitions with exactly one name:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "name.0", rule integerMatch, value 1 })
+
+ The "description" component of an ObjectClassDescription is defined
+ to be an OPTIONAL DirectoryString. The following search filter finds
+ object class definitions that have descriptions, regardless of the
+ contents of the description string:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "description",
+ rule presentMatch, value NULL })
+
+ The presentMatch returns TRUE if the description component is present
+ and FALSE otherwise.
+
+ The following search filter finds object class definitions that don't
+ have descriptions:
+
+ (objectClasses:componentFilterMatch:=
+ not:item:{ component "description",
+ rule presentMatch, value NULL })
+
+ The following search filter finds object class definitions with the
+
+
+
+Legg Expires 19 October 2002 [Page 31]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ word "bogus" in the description:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "description",
+ rule caseIgnoreSubstringsMatch,
+ value { any:"bogus" } })
+
+ The assertion value is of the SubstringAssertion syntax, i.e.
+
+ SubstringAssertion ::= SEQUENCE OF CHOICE {
+ initial [0] DirectoryString {ub-match},
+ any [1] DirectoryString {ub-match},
+ final [2] DirectoryString {ub-match} }
+
+ The "obsolete" component of an ObjectClassDescription is defined to
+ be DEFAULT FALSE. An object class is obsolete if the "obsolete"
+ component is present and set to TRUE. The following search filter
+ finds all obsolete object classes:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "obsolete", rule booleanMatch, value TRUE })
+
+ An object class is not obsolete if the "obsolete" component is not
+ present, in which case it defaults to FALSE, or is present but is
+ explicitly set to FALSE. The following search filter finds all non-
+ obsolete object classes:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "obsolete", rule booleanMatch, value FALSE })
+
+ The useDefaultValues flag in the ComponentAssertion defaults to TRUE
+ so the componentFilterMatch rule treats an absent "obsolete"
+ component as being present and set to FALSE. The following search
+ filter finds only object class definitions where the "obsolete"
+ component has been explicitly set to FALSE, rather than implicitly
+ defaulting to FALSE:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "obsolete", useDefaultValues FALSE,
+ rule booleanMatch, value FALSE })
+
+ With the useDefaultValues flag set to FALSE, if the "obsolete"
+ component is absent the component reference identifies no component
+ value and the matching rule will return FALSE. The matching rule can
+ only return TRUE if the component is present and set to FALSE.
+
+ The "information.kind" component of the ObjectClassDescription is an
+ ENUMERATED type. The allComponentsMatch matching rule can be used to
+
+
+
+Legg Expires 19 October 2002 [Page 32]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ match values of an ENUMERATED type. The following search filter
+ finds object class definitions for auxiliary object classes:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "information.kind",
+ rule allComponentsMatch, value auxiliary })
+
+ The following search filter finds auxiliary object classes with
+ commonName (cn or 2.5.4.3) as a mandatory attribute:
+
+ (objectClasses:componentFilterMatch:=and:{
+ item:{ component "information.kind",
+ rule allComponentsMatch, value auxiliary },
+ item:{ component "information.mandatories.*",
+ rule objectIdentifierMatch, value cn } })
+
+ The following search filter finds auxiliary object classes with
+ commonName as a mandatory or optional attribute:
+
+ (objectClasses:componentFilterMatch:=and:{
+ item:{ component "information.kind",
+ rule allComponentsMatch, value auxiliary },
+ or:{
+ item:{ component "information.mandatories.*",
+ rule objectIdentifierMatch, value cn },
+ item:{ component "information.optionals.*",
+ rule objectIdentifierMatch, value cn } } })
+
+ Extra care is required when matching optional SEQUENCE OF or SET OF
+ components because of the distinction between an absent list of
+ instances and a present, but empty, list of instances. The following
+ search filter finds object class definitions with less than three
+ names, including object class definitions with a present but empty
+ list of names, but does not find object class definitions with an
+ absent list of names:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "name.0",
+ rule integerOrderingMatch, value 3 })
+
+ If the "name" component is absent the "name.0" component is also
+ considered to be absent and the ComponentAssertion evaluates to
+ FALSE. If the "name" component is present, but empty, the "name.0"
+ component is also present and equal to zero, so the
+ ComponentAssertion evaluates to TRUE. To also find the object class
+ definitions with an absent list of names the following search filter
+ would be used:
+
+
+
+
+Legg Expires 19 October 2002 [Page 33]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ (objectClasses:componentFilterMatch:=or:{
+ not:item:{ component "name", rule presentMatch, value NULL },
+ item:{ component "name.0",
+ rule integerOrderingMatch, value 3 } })
+
+ Distinguished names embedded in other syntaxes can be matched with a
+ componentFilterMatch. The uniqueMember attribute type has an
+ attribute syntax described by the ASN.1 type NameAndOptionalUID.
+
+ NameAndOptionalUID ::= SEQUENCE {
+ dn DistinguishedName,
+ uid UniqueIdentifier OPTIONAL }
+
+ The following search filter finds values of the uniqueMember
+ attribute containing the author's DN:
+
+ (uniqueMember:componentFilterMatch:=
+ item:{ component "dn",
+ rule distinguishedNameMatch,
+ value "cn=Steven Legg,o=Adacel,c=AU" })
+
+ The DistinguishedName and RelativeDistinguishedName ASN.1 types are
+ also complex ASN.1 types so the component matching rules can be
+ applied to their inner components.
+
+ DistinguishedName ::= RDNSequence
+
+ RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+ RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
+ AttributeTypeAndValue
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type AttributeType ({SupportedAttributes}),
+ value AttributeValue ({SupportedAttributes}{@type}) }
+
+ AttributeType ::= ATTRIBUTE.&id
+
+ AttributeValue ::= ATTRIBUTE.&Type
+
+ ATTRIBUTE.&Type is an open type. A value of ATTRIBUTE.&Type is
+ constrained by the type component of AttributeTypeAndValue to be of
+ the attribute syntax of the nominated attribute type. Note: the
+ fourth edition of X.500 extends and renames the AttributeTypeAndValue
+ SEQUENCE type.
+
+ The seeAlso attribute has the DistinguishedName syntax. The
+ following search filter finds seeAlso attribute values containing the
+
+
+
+Legg Expires 19 October 2002 [Page 34]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ RDN, "o=Adacel", anywhere in the DN:
+
+ (seeAlso:componentFilterMatch:=
+ item:{ component "*", rule rdnMatch, value "o=Adacel" })
+
+ The following search filter finds all seeAlso attribute values with
+ "cn=Steven Legg" as the RDN of the named entry (i.e. the "first" RDN
+ in an LDAPDN or the "last" RDN in an X.500 DN):
+
+ (seeAlso:componentFilterMatch:=
+ item:{ component "-1",
+ rule rdnMatch, value "cn=Steven Legg" })
+
+ The following search filter finds all seeAlso attribute values naming
+ entries in the DIT subtree of "o=Adacel,c=AU":
+
+ (seeAlso:componentFilterMatch:=and:{
+ item:{ component "1", rule rdnMatch, value "c=AU" },
+ item:{ component "2", rule rdnMatch, value "o=Adacel" } })
+
+ The following search filter finds all seeAlso attribute values
+ containing the naming attribute types commonName (cn) and
+ telephoneNumber in the same RDN:
+
+ (seeAlso:componentFilterMatch:=
+ item:{ component "*", rule componentFilterMatch,
+ value and:{
+ item:{ component "*.type",
+ rule objectIdentifierMatch, value cn },
+ item:{ component "*.type",
+ rule objectIdentifierMatch,
+ value telephoneNumber } } })
+
+ The following search filter would find all seeAlso attribute values
+ containing the attribute types commonName and telephoneNumber, but
+ not necessarily in the same RDN:
+
+ (seeAlso:componentFilterMatch:=and:{
+ item:{ component "*.*.type",
+ rule objectIdentifierMatch, value cn },
+ item:{ component "*.*.type",
+ rule objectIdentifierMatch, value telephoneNumber } })
+
+ The following search filter finds all seeAlso attribute values
+ containing the word "Adacel" in any organizationalUnitName (ou)
+ attribute value in any AttributeTypeAndValue of any RDN:
+
+ (seeAlso:componentFilterMatch:=
+
+
+
+Legg Expires 19 October 2002 [Page 35]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ item:{ component "*.*.value.(2.5.4.11)",
+ rule caseIgnoreSubstringsMatch,
+ value { any:"Adacel" } })
+
+ The component reference "*.*.value" identifies an open type, in this
+ case an attribute value. In a particular AttributeTypeAndValue, if
+ the attribute type is not organizationalUnitName then the
+ ComponentAssertion evaluates to FALSE. Otherwise the substring
+ assertion is evaluated against the attribute value.
+
+
+10. Security Considerations
+
+ The component matching rules described in this document allow for a
+ compact specification of matching capabilities that could otherwise
+ have been defined by a plethora of specific matching rules, i.e.
+ despite their expressiveness and flexibility the component matching
+ rules do not behave in a way uncharacteristic of other matching
+ rules, so the security issues for component matching rules are no
+ different than for any other matching rule. However, because the
+ component matching rules are applicable to any attribute syntax,
+ support for them in a directory server may allow searching of
+ attributes that were previously unsearchable by virtue of there not
+ being a suitable matching rule. Such attribute types ought to be
+ properly protected with appropriate access controls.
+
+
+11. Acknowledgements
+
+ The author would like to thank Tom Gindin for private email
+ discussions that clarified and refined the ideas presented in this
+ document.
+
+
+12. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+
+
+Legg Expires 19 October 2002 [Page 36]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ [5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished
+ Names", RFC 2253, December 1997.
+
+ [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+ 2279, January 1998.
+
+ [7] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
+ draft-legg-ldap-gser-xx.txt, a work in progress, March 2002.
+
+ [8] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Models
+
+ [9] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Authentication Framework
+
+ [10] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Selected attribute types
+
+ [11] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
+ Information Technology - Abstract Syntax Notation One (ASN.1):
+ Specification of basic notation
+
+ [12] ITU-T Recommendation X.680 - Amendment 1 (06/99) | ISO/IEC
+ 8824-1:1998/Amd 1:2000 Relative object identifiers
+
+ [13] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998
+ Information Technology - Abstract Syntax Notation One (ASN.1):
+ Information object specification
+
+ [14] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998
+ Information Technology - Abstract Syntax Notation One (ASN.1):
+ Constraint specification
+
+ [15] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998
+ Information Technology - Abstract Syntax Notation One (ASN.1):
+ Parameterization of ASN.1 specifications
+
+
+13. Informative References
+
+ [16] Hovey, R. and S. Bradner, "The Organizations Involved in the
+ IETF Standards Process", BCP 11, RFC 2028, October 1996.
+
+ [17] Howes, T., "The String Representation of LDAP Search Filters",
+
+
+
+Legg Expires 19 October 2002 [Page 37]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ RFC 2254, December 1997.
+
+ [18] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Overview of concepts, models and services
+
+ [19] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
+ Information Technology - ASN.1 encoding rules: Specification of
+ Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)
+
+
+14. Intellectual Property Notice
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. [16] Copies
+ of claims of rights made available for publication 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 implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+15. Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+
+
+
+Legg Expires 19 October 2002 [Page 38]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+
+16. Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 405-409 Ferntree Gully Road
+ Mount Waverley, Victoria 3149
+ AUSTRALIA
+
+ Phone: +61 3 9451 2107
+ Fax: +61 3 9541 2121
+ EMail: steven.legg@adacel.com.au
+
+
+17. Appendix A - Changes From Previous Drafts
+
+17.1 Changes in Draft 01
+
+ Section 4.1.7 (now 5.1.7) was added to enable component matching of
+ values embedded in encoded form into BIT STRINGs or OCTET STRINGs.
+ In particular, this is to allow component matching of values in
+ Certificate extensions. The <content> rule was added in Section 4.1
+ (now 5.1) to allow the OCTET STRING contents to be treated as either
+ raw octets or as an embedded value.
+
+ References to a companion document summarizing the ASN.1 types of
+ LDAP syntaxes were removed to avoid holding up this document.
+
+ The OpenType syntax was renamed to OpenAssertionType.
+
+ Object identifiers for the new syntax and matching rule definitions
+ have been allocated from an arc belonging to Adacel Technologies Ltd.
+
+
+
+
+Legg Expires 19 October 2002 [Page 39]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+17.2 Changes in Draft 02
+
+ The context specific tagging in the ComponentAssertion ASN.1 type was
+ unnecessary and has been removed.
+
+ The encoding of OpenAssertionType assertion values outside of
+ ComponentAssertions has been clarified, and the description of
+ OpenAssertionType has been promoted to its own section.
+
+17.3 Changes in Draft 03
+
+ The default matching by allComponentsMatch of component values of BIT
+ STRING types with named bit lists has been changed to ignore trailing
+ zero bits.
+
+ Typographical errors in the <SafeUTF8Character> rule have been fixed.
+
+17.4 Changes in Draft 04
+
+ When the matching rule in a ComponentAssertion has a variable
+ assertion syntax it is not possible to determine the syntax of the
+ value component from the ComponentAssertion alone when the associated
+ component reference has referenced through an open type. Deducing
+ what that syntax should be from inspection of the other
+ ComponentAssertions in a ComponentFilter is difficult to implement in
+ any comprehensive way. The <select> form of ComponentId has been
+ introduced so that the syntax can always be determined from the
+ contents of the ComponentAssertion alone. This not only simplifies
+ implementation but can lead to simpler ComponentFilters since there
+ is no longer a requirement to test that the components constraining
+ an open type have particular values. The open type referencing
+ example has been changed accordingly. The contained type referencing
+ example has also been changed because it is an example of a contained
+ open type.
+
+ The presentationAddressMatch rule is not commutative so it has been
+ removed from the table defining directoryComponentsMatch. The default
+ behaviour of allComponentsMatch is already a suitable commutative
+ substitute for matching PresentationAddress values.
+
+ The null character has been included in the range of legal characters
+ for <SafeUTF8Character>.
+
+ The ASN.1 type of the notional iteration count associated with SET OF
+ and SEQUENCE OF values has been refined to INTEGER (0..MAX).
+
+ The encoding rules in Section 8 (now draft-legg-ldap-gser-xx.txt)
+ have been formally named the Generic String Encoding Rules (GSER) and
+
+
+
+Legg Expires 19 October 2002 [Page 40]
+
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+
+
+ a transfer syntax object identifier has been assigned.
+
+ The term "LDAP string encoding" has been replaced by the term "native
+ LDAP-specific encoding" to align with terminology anticipated to be
+ used in the revision of RFC 2252.
+
+17.5 Changes in Draft 05
+
+ Reformatted the draft to conform to recent and proposed RFC editorial
+ policy.
+
+ The use of the <oid> rule from RFC 2252 has been replaced by a local
+ definition to specifically outlaw leading zero characters in OBJECT
+ IDENTIFIER components.
+
+ Provisions for the RELATIVE-OID ASN.1 type defined in Amendment 1 to
+ X.680 have been added.
+
+ The comparison of REAL values has been clarified and the GSER
+ encoding of REAL values has been extended.
+
+ Removed extraneous spaces from example DNs.
+
+17.6 Changes in Draft 06
+
+ An ABNF syntax error in the <exponent> rule was fixed.
+
+17.7 Changes in Draft 07
+
+ The term "native LDAP encoding" has been replaced by the term "LDAP-
+ specific encoding" to align with terminology anticipated to be used
+ in the revision of RFC 2252.
+
+ Section 8 has been extracted to become a separate Internet draft,
+ draft-legg-ldap-gser-00.txt. The specifications for ChoiceOfStrings
+ types have also been moved to this new Internet draft. Various
+ editorial changes have been made to this draft to accommodate this
+ split.
+
+17.8 Changes in Draft 08
+
+ The enumeratedMatch matching rule duplicates a subset of the
+ functionality of allComponentsMatch so it has been removed. The
+ enumeratedMatch rule has been replaced by allComponentsMatch in the
+ examples. The description of the OpenAssertionType syntax has been
+ moved into Section 8.
+
+
+
+
+
+Legg Expires 19 October 2002 [Page 41]
+
diff --git a/doc/drafts/draft-zeilenga-ldap-t-f-02.txt b/doc/drafts/draft-zeilenga-ldap-t-f-xx.txt
similarity index 100%
rename from doc/drafts/draft-zeilenga-ldap-t-f-02.txt
rename to doc/drafts/draft-zeilenga-ldap-t-f-xx.txt