WPCq 2%.Bpz W"S^11>bbu"::Dg1:11bbbbbbbbbb11gggbuuuk1Xubuukuuuk111Rb:bbXbb1bb''X'bbbb:X1bXXXX;.;g:=::m:::mmmmm::::::mm:k1mubububububXubububub11111111bbbbbbbbbuXubbkbuXmmmmumububXXXXbububububbmbbbbbb:k:k::=kmmX:uXb'b:b:b:b'bmbbbb:::uXuXuXuXk:k:k:mbbbmbuXkXkXKQmmmm^b:kbbbbmbA@mmbmmbmmmmmmm:b:mmmbbmmmmmmmmmmmmXXmmmmmmmmmmmmmmmmmmcm`m`mm`m:mmmmmm}}}mjjmmmmmmmmmmmmmmm0mm}mmmmmmmmmmmmmmmmmmmmmmm}Mmmmmmmmmmmmmjmmmtmmmmmmmmm`'mmm`mmjmlWmmmmmmmmmmmmmmmmmmmW`mmmmjmM#|xaHelveticaCourierCourier Bold4PkCQMS PS Jet Plus /800 II QPJPII.PRSPl`D4PkCg2W _a.s|x-HelveticaCourierHelveticaCourierCourier BoldHelvetica BoldmQrrr r  @C2M.IzPw@ ,`H1`D4PkCmQrrr r  @CmQrrrr  `C"S^1:Sbb1::Dg1:11bbbbbbbbbb::gggkuk1bkuukuuuk:1:gb1bkbkb:kk11b1kkkkDb:kbbbXD1Dg:=::r:::rrrrr::::::rr:k1rbbbbbbubububub11111111kkkkkkkkkubbkkkubrrrrrbbbbbbkububububkrkkkkkk:k:k::=krrb:bk1k:k:k:k1krkkkkDDDububububk:k:k:rkkkrkubkXkXKQrrrrbb:kbbbbrbA@rrbrrbrrrrrrrXb::rrbbrrrrrrrrrrrrkkrrrrrrrrrrrrrrrrrrcr`r`rr`r:rrrrrr}}}rjjrrrrrrrrrrrrrrr0rr}rrrrrrrrrrrrrrrrrrrrrrr}Mrrrrrrrrrrrrjrrrtrrrrrrrrr`'rrr`rrjrlWrrrrrrrrrrrrrrrrrrrW`rrrrjrM@ ,`H1`D4PkCmQrrr r  @CmQrrrr  `C@,dK1dD4p}wC2.' . "S^"55U@ %8 55555555558885a@@EE@;KE0@5PEK@KE@;E@[@@;-5 55055550P5555 050E000  8 " m mmmmm mm ;m@5@5@5@5@5`UE0@5@5@5@5E5K5K5K5K5E5E5E5E5@0@5E5K;K5@0mmmmmm@5@5E0E0E0E0E5@5@5@5@5K5mmK5K5K5K5E5E5 ; ; ";mm0 @055 5 5 5E5mmE5E5K5K5`[E E E @0@0@0@0; ; ; mmE5E5E5mmE5[E@0;0;0K,mmmm45 ;5555m5$#mm5mmLL5mmmmmmm 5` mmm55Ummmmmmmmmmmm00`mmmmmmmmmmmmmmmmmm`cm5m5mm5m mmmmmJmDDDm::mdmmmmmmmmmmmmmmmmDmmmmmmmmmmmm__mmdmmmmmmmmmD*Ommmmmmmmmmmm:mmm?mmmmmmmmm5'mmm5mm:m;/mmmmmmmmmmmmmmmmmmm/H5Jmmmm:m*@ ,`H1`D4PkCmQrrr r  @CmQrrrr  `C@,dK1dD4p}wC@H4': 4D4PkC"S^ .55UE %8 5555555555 888;^EEEE@;KE5E;PEK@KE@;E@[@@;  855;5;5 ;;5U;;;;%5 ;5K550%%8 " r rrrrr rr ;rE5E5E5E5E5`UE5@5@5@5@5E;K;K;K;K;E;E;E;E;@5E5E;K;K;@5rrrrrrE5E5E5E5E5E5E;@5@5@5@5K;rrK;K;K;K;E;E; ; ; ";rr5 E5;; ; ; ;E;rrE;E;K;K;`[E%E%E%@5@5@5@5; ; ; rrE;E;E;rrE;[K@5;0;0K,rrrr55 ;5555r5$#rr5rrLL5rrrrrrr05` rr55Urrrrrrrrrrrr;;`rrrrrrrrrrrrrrrrrr`cr5r5rr5r rrrrrJrDDDr::rdrrrrrrrrrrrrrrrrDrrrrrrrrrrrr__rrdrrrrrrrrrD*Orrrrrrrrrrrr:rrr?rrrrrrrrr5'rrr5rr:r;/rrrrrrrrrrrrrrrrrrr/H5Jrrrr:r*@ ,`H1`D4PkCmQrrr r  @CmQrrrr  `C@,dK1dD4p}wC@H4': 4D4PkC@H7)T7D4p}wC2 L#xo@ ,`H1`D4PkCmQrrr r  @CmQrrrr  `C@,dK1dD4p}wC@H4': 4D4PkC@H7)T7D4p}wC;,>>> >  @C  X` hp x (#%'( ,x-    3'3'Standard6'6'StandardC6QMS $=R- y:$  x|@   Fascicle VIII.8 Rec. X.511 y:& x|@  Fascicle VIII.8 Rec. X.511    Recommendation X.511  THE DIRECTORY ABSTRACT SERVICE DEFINITION 1)ă "(Melbourne, 1988) * * * * &CONTENTS * 0Introduction 1Scope and field of application SECTION 1 General 2References 3Definitions 4Abbreviations 5Conventions SECTION 2 Abstract service 6Overview of the directory service 7Information types 8Bind and unbind operations 9Directory read operations 10Directory search operations 11Directory modify operations 12Errors Annex A Abstract service in ASN.1 Annex B Directory object identifiers 0  Introduction  0.1This document, together with the others of the series, has been produced to facilitate the interconnection of information processing systems to provide directory services. The set of all such systems, together with the directory information which they hold, can be viewed as an integrated whole, called the Directory. The information held by the Directory, collectively known as the Directory Information Base (DIB), is typically used to facilitate communication between, with or about objects such as applicationentities, people, terminals, and distribution lists.  0.2The Directory plays a significant role in Open Systems Interconnection, whose aim is to allow, with a minimum of technical agreement outside of the interconnection standards themselves, the interconnection of information processing systems: ( from different manufacturers; 0Ԍ ( under different managements; ( of different levels of complexity; and ( of different ages.  0.3This Recommendation defines the capabilities provided by the Directory to its users.  0.4Annex A provides the ASN.1 module which contains all the definitions associated with the abstract service. 1  Scope and field of application  1.1This Recommendation defines in an abstract way the externally visible service provided by the Directory. 1.2This Recommendation does not specify individual implementation or products. SECTION 1 General 2  References Recommendation X.200 Open Systems Interconnection Basic Reference Model. Recommendation X.208 Specification of Abstract Syntax Notation One (ASN.1). Recommendation X.500 The Directory Overview of Concepts, Models and Services. Recommendation X.501 The Directory Models. Recommendation X.518 The Directory Procedures for Distributed Operation. Recommendation X.519 The Directory Protocol Specifications. Recommendation X.520 The Directory Selected Attribute Types. Recommendation X.521 The Directory Selected Object Classes. Recommendation X.509 The Directory Authentication Framework. Recommendation X.219 Remote Operations Model, Notation and Service Definition. Recommendation X.229 Remote Operations Protocol Specification. Recommendation X.407 Abstract Service Definition Conventions. 3  Definitions 3.1Basic Directory definitions  This Recommendation makes use of the following terms defined in Recommendation X.500: a)( Directory; b)( Directory Information Base (DIB); c)( (Directory) User. 3.2Directory model definitions  This Recommendation makes use of the following terms defined in RecommendationX.501: a) ( Directory System Agent; b)( Directory User Agent. 3.3Directory information base definitions  This Recommendation makes use of the following terms defined in Recommendation X.501: a)( alias entry; b)( Directory Information Tree; c)( (Directory) entry; d)( immediate superior; e)( immediately superior entry/object; 0Ԍf)( object; g)( object class; h)( object entry; i)( subordinate; j)( superior. 3.4Directory entry definitions  This Recommendation makes use of the following terms defined in RecommendationX.501: a)( attribute; b)( attribute type; c)( attribute value; d)( attribute value assertion. 3.5Name definitions  This Recommendation makes use of the following terms defined in Recommendation X.501: a)( alias, alias name; b)( distinguished name; c)( (directory) name; d)( purported name; e)( relative distinguished name. 3.6Distributed operations definitions  This Recommendation makes use of the following terms defined in Recommendation X.518: a)( chaining; b)( referral. 3.7Abstract service definitions This Recommendation defines the following terms:  a)(( filter: an assertion about the presence or value of certain attributes of an entry in order to limit the scope of a search;'(  b)(( service controls: parameters conveyed as part of an abstractoperation which constrain various aspects of its performance;'( c)(( originator: the user that originated an operation.'( 4  Abbreviations This Recommendation makes use of the following abbreviations: AVA ( Attribute Value Assertion DIB ( Directory Information Base DIT ( Directory Information Tree DMD ( Directory Management Domain DSA ( Directory System Agent DUA ( Directory User Agent RDN ( Relative Distinguished Name 5  Conventions  This Recommendation makes use of the abstract service definition conventions defined in Recommendation X.407.  x0Ԍ SECTION 2 Abstract service 6  Overview of the directory service  6.1As described in Recommendation X.501 the services of the Directory are provided through access points to DUAs, each acting on behalf of a user. These concepts are depicted in Figure1/X.511. #FIGURE 1/X.511 *  Access to the Directory ă  6.2In principle, access points to the Directory may be of different types, providing different combinations of services. It is valuable to consider the Directory as an object, supporting a number of types of port. Each port defines a particular kind of interaction which the Directory can participate in with a DUA. Each access point corresponds to a particular combination of port types.  6.3Using the notation defined in Recommendation X.407 the Directory can be defined as follows: ( ,x-( @ ,x-  directory ( OBJECT (  PORTS { @  readPort [S], (  @  searchPort [S],  (  @  modifyPort [S]}  ::= ( idotdirectory  The Directory supplies operations via: Read Ports, which support reading information from a particular named entry in the DIB; Search Ports, which allow more "exploration" of the DIB; and Modify Ports, which enable the modification of entries in the DIB.  Note It is intended that in the future there may be other types of Directory port.'  6.4 Similarly, a DUA (from the viewpoint of the Directory) can be defined as follows:  dua ( OBJECT (  PORTS { @  readPort [C], (  @  searchPort [C], (  @  modifyPort [C]}  ::= ( idotdua ( @ ,x-( ,x-The DUA consumes the services provided by the Directory. 6.5The ports cited from 6.2 to 6.4 can be defined as follows:  readPort ( PORT (  CONSUMER INVOKES { (   Read, Compare, Abandon}  ::= ( idptsearch  searchPort ( PORT (  CONSUMER INVOKES { (   List, Search}  ::= ( idptsearch  modifyPort ( PORT ( CONSUMER INVOKES { (  AddEntry, RemoveEntry, (  ModifyEntry, ModifyRDN} ( ::=  idptmodify  6.6The operations from the readPort , searchPort and the modifyPort are defined in 9, 10, and 11 respectively.  6.7These ports are used only as a method of structuring the description of the Directory service. Conformance to the Directory operations is specified in RecommendationX.519. x0Ԍ 7  Information types 7.1Introduction  7.1.1This paragraph identifies, and in some cases defines, a number of information types which are subsequently used in the definition of Directory operations. The information types concerned are those which are common to more than one operation, are likely to be in the future, or which are sufficiently complex or selfcontained as to merit being defined separately from the operation which uses them.  7.1.2Several of the information types used in the definition of the Directory service are actually defined elsewhere. Paragraph7.2 identifies types and indicates the source of their definition. Each of the remaining (7.3 to 7.10) identifies and defines an information type. 7.2Information types defined elsewhere 7.2.1The following information types are defined in RecommendationX.501: a)( Attribute ; b)( AttributeType ; c)( AttributeValue ; d)( AttributeValueAssertion ; e)( DistinguishedName ; f)( Name ; g)( RelativeDistinguishedName . 7.2.2The following information type is defined in Recommendation X.520: a)( PresentationAddress . 7.2.3The following information types are defined in Recommendation X.509: a)( Certificate ; b)( SIGNED ; c)( CertificationPath. 7.2.4The following information type is defined in RecommendationX.219: a)( InvokeID . 7.2.5The following information types are defined in Recommendation X.518: a)( OperationProgress ; b)( ContinuationReference . 7.3Common arguments  7.3.1The CommonArguments information may be present to qualify the invocation of each operation that the Directory can perform. ( ,x-( @ h,x- CommonArguments ::= @  SET { ( [30]  ServiceControls DEFAULT { }, ( [29]  SecurityParameters DEFAULT { }, ( requestor [28] DistinguishedName (  @ h# OPTIONAL, ( [27]  OperationProgress DEFAULT notStarted, ( aliasedRDNs [26] INTEGER OPTIONAL, ( extensions [25] SET OF EXTENSION OPTIONAL}  Extension  ::= SET { ( identifier   [0] INTEGER, ( critical   [1] BOOLEAN DEFAULT FALSE, ( item  @  [2] ANY DEFINED BY identifier}  ( @ h,x-( ,x-7.3.2The various components have the meanings as defined in 7.3.2.1 to 7.3.2.4.  7.3.2.1The ServiceControls component is specified in 7.5. Its absence is deemed equivalent to there being an empty set of controls.  7.3.2.2The SecurityParameters component is specified in 7.9. Its absence is deemed equivalent to there being an empty set of security parameters.  7.3.2.3The requestor DistinguishedName identifies the originator of a particular abstract operation. It holds the name of 0 the user as identified at the time of binding to the Directory. It may be required when the request is to be signed (see 7.10), and shall hold the name of the user who initiated the request.  7.3.2.4The OperationProgress defines the role that the DSA is to play in the distributed evaluation of the request. It is more fully defined in RecommendationX.518.  7.3.2.5The aliasedRDNs component indicates to the DSA that the object component of the operation was created by the dereferencing of an alias on an earlier operation attempt. The integer value indicates the number of RDNs in the object that came from dereferencing the alias. (The value would have been set in the referral response of the previous operation.)  7.3.2.6The extensions component provides a mechanism to express standardized extensions to the form of the argument of a Directory abstractoperation.  Note The form of the result of such an extended abstractoperation is identical to that of the nonextended version. (Nonetheless, the result of a particular extended abstractoperation may differ from its nonextended counterpart). The subcomponents are as defined in 7.3.2.6.1 to 7.3.2.6.3.  7.3.2.6.1 The identifier serves to identify a particular extension. Values of this component shall be assigned only by future versions of this series of Recommendations.  7.3.2.6.2 The critical subcomponent allows the originator of the extended abstractoperation to indicate that the performance of only the extended form of the abstractoperation is acceptable (i.e. that the nonextended form is not acceptable). In this case the extension is a critical extension. If the Directory, or some part of it, is unable to perform a critical extension it returns an indication of unavailableCriticalExtension (as a ServiceError or PartialOutcomeQualifier ). If the Directory is unable to perform an extension which is not critical, it ignores the presence of the extension.  7.3.2.6.3 The item subcomponent provides the information needed for the Directory to perform the extended form of the abstractoperation. 7.4Common results  7.4.1The CommonResults information should be present to qualify the result of each retrieval operation that the Directory can perform. ( ,x-( X,x- CommonResults   ::=   SET { ( [30] SecurityParameters "X% OPTIONAL, ( performer [29] DistinguishedName (    X% OPTIONAL, ( aliasDereferenced [28] !  BOOLEAN (     DEFAULT FALSE}  ( X,x-( ,x-7.4.2The various components have the meanings as defined in 7.4.2.1 to 7.4.2.3.  7.4.2.1The SecurityParameters component is specified in 7.9. Its absence is deemed equivalent to there being an empty set of security parameters.  7.4.2.2The performer DistinguishedName identifies the performer of a particular operation. It may be required when the result is to be signed (see 7.10), and shall hold the name of the DSA which signed the result.  7.4.2.3The aliasDereferenced Component is set to TRUE when the purported name of an object or base object which is the target of the operation included on alias which was dereferenced. 7.5Service controls  7.5.1A ServiceControls parameter contains the controls, if any, that are to direct or constrain the provision of the service. ( ,x-( ,x- ServiceControls   ::=   SET { ( options [0] BIT STRING { (  preferChaining(0) (  chainingProhibited (1), (  localScope (2), (  dontUseCopy (3), (  dontDereferenceAliases(4)} (  DEFAULT {},  priority [1] INTEGER { ( low (0), ( medium (1), ( high (2) } DEFAULT medium,  +  timeLimit  [2]   INTEGER OPTIONAL,  sizeLimit  [3]   INTEGER OPTIONAL,  scopeOfReferral [4] INTEGER { (    dmd(0), (    country(1)} (    OPTIONAL }  ( ,x-( ,x-7.5.2The various components have the meanings as defined in 7.5.2.1 to 7.5.2.5.  7.5.2.1The options component contains a number of indications, each of which, if set, asserts the condition suggested. Thus:  a)(( preferChaining indicates that the preference is that chaining, rather than referrals, be used to provide the service. The Directory is not obliged to follow this preference;'(  b)(( chainingProhibited indicates that chaining, and other methods of distributing the request around the Directory, are prohibited;'(  c)(( localScope indicates that the operation is to be limited to a local scope. The definition of this option is itself a local matter. For example, within a single DSA or a single DMD;'(  d)(( dontUseCopy indicates that copied information (as defined in Recommendation X.518) shall not be used to provide the service;'(  e)(( dontDereferenceAliases indicate that any alias used to identify the entry affected by an operation is not to be dereferenced;'(  Note This is necessary to allow reference to an alias entry itself rather than the aliased entry, e.g. in order to read the alias entry.  If this component is omitted, the following are assumed: no preference for chaining but chaining not prohibited, no limit on the scope of the operation, use of copy permitted, and aliases will be dereferenced (except for modify operations where aliases will never be dereferenced).  7.5.2.2The priority (low, medium or high) at which the service is to be provided. Note that this is not a guaranteed service in that Directory, as a whole, does not implement queuing. There is no relationship implied with the use of "priorities" in underlying layers.  7.5.2.3The timeLimit indicates the maximum elapsed time, in seconds, within which the service shall be provided. If the constraint cannot be met, an error is reported. If this component is omitted, no time limit is implied. In the case of time limit exceeded on a List or Search , the result is an arbitrary selection of the accumulated results.  Note This component does not imply the length of time spent processing the request during the elapsed time: any number of DSAs may be involved in processing the request during the elapsed time.  7.5.2.4The sizeLimit is only applicable to List and Search operations. It indicates the maximum number of objects to be returned. In the case of size limit exceeded, the results of List and Search may be an arbitrary selection of the accumulated results, equal in number to the size limit. Any further results shall be discarded.  7.5.2.5The scopeOfReferral indicates the scope to which a referral returned by a DSA should be relevant. Depending on whether the value dmd or country are selected, only referrals to other DSAs within the selected scope will be returned.  This applies to the referrals in both a ReferralError and the unexplored parameter of List and  Search results.  7.5.3Certain combinations of priority , timeLimit , and sizeLimit may result in conflicts. For example, a short time limit could conflict with low priority; a high size limit could conflict with a low time limit, etc. 7.6Entry information selection  7.6.1An EntryInformationSelection parameter indicates what information is being requested from an entry in a retrieval service.  EntryInformationSelection ::= SET { ( attributeTypes (  CHOICE { (   allAttributes [0] NULL, (   select [1]] SET OF AttributeType (   é empty set implies no attributes (   é are requested é} (  DEFAULT allAttributes NULL, ( InfoTypes [2] INTEGER { (  attributeTypesOnly (0), (  attributeTypesAndValues (1) } (  DEFAULT attributeTypesAndValues }  .Ԍ 7.6.2The various components have the meanings as defined in 7.6.2.1 and 7.6.2.2.  7.6.2.1The attributeTypes component specifies the set of attributes about which information is requested:  a)(( if the select option is chosen, then the attributes involved are listed. If the list is empty, then no attributes will be returned. Information about a selected attribute shall be returned if the attribute is present. An AttributeError with the noSuchAttribute problem shall only be returned if none of the attributes selected is present;'(  b)(( if the allAttributes option is selected, then information is requested about all attributes in the entry.'(  Attribute information is only returned if access rights are sufficient. A SecurityError (with an insufficientAccessRights problem) will only be returned in the case where access rights preclude the reading of all attribute values requested.  7.6.2.2The infoTypes component specifies whether both attribute type and attribute value information (the default) or attribute type information only is requested. If the attributeTypes component (7.6.2.1) is such as to request no attributes, then this component is not meaningful. 7.7Entry information 7.7.1An EntryInformation parameter conveys selected information from an entry. ( ,x-( ,x- EntryInformation   ::=   SEQUENCE { ( DistinguishedName, ( fromEntry BOOLEAN DEFAULT TRUE, ( SET OF CHOICE { (  AttributeType, (  Attribute} OPTIONAL } ( ,x-( ,x-7.7.2The DistinguishedName of the entry is always included.  7.7.3The fromEntry parameter indicates whether the information was obtained from the entry ( TRUE ) or a copy of the entry ( FALSE ).  7.7.4A set of AttributeType s or Attribute s are included, if relevant, each of which may be alone or accompanied by one or more attribute values. 7.8Filter  7.8.1A Filter parameter applies a test that is either satisfied or not by a particular entry. The filter is expressed in terms of assertions about the presence or value of certain attributes of the entry, and is satisfied if and only if it evaluates to TRUE . Note A Filter may be TRUE , FALSE , or undefined. ( ,x-(@ xh,x- Filter ( ::=  CHOICE { ( item @  [0]  FilterItem, ( and @  [1]  SET OF Filter, ( or @  [2]  SET OF Filter, ( not @  [3]  Filter }  FilterItem ::=  CHOICE { ( equality @  [0]  AttributeValueAssertion, ( substrings @  [1]  SEQUENCE { (  type @  AttributeType, (  strings SEQUENCE OF CHOICE { ( @  Initial  [0] !x! AttributeValue, ( @  any x! [1] $h# AttributeValue, ( @  final x! [2] $h# AttributeValue}}, ( greaterOrEqual @  [2]  AttributeValueAssertion, ( lessOrEqual @  [3] !x! AttributeValueAssertion, ( present @  [4]  AttributeType, ( approximateMatch @  [5]  AttributeValueAssertion }  (@ xh,x-( ,x-7.8.2A Filter is either a FilterItem (see 7.8.3), or an expression involving simpler Filter s composed together using the logical operators and , or , and not . The Filter is undefined if it is a FilterItem which is undefined, or if it involves one or more simpler Filter s, all of which are undefined. Otherwise, where the Filter is: a)(( an item , it is TRUE if and only if the corresponding FilterItem is TRUE ;'( b)( an and , it is TRUE unless any of the nested Filter s is FALSE ; /ԌX( Note Thus, if there are no nested Filter s the and evaluates to TRUE .'( c)(( an or , it is FALSE unless any of the nested Filter s is TRUE ;'( (( Note Thus, if there are no nested Filter s the or evaluates to FALSE .'( d)(( a not , it is TRUE if and only if the nested Filter is FALSE .'(  7.8.3A FilterItem is an assertion about the presence or value(s) of an attribute of a particular type in the entry under test. Each such assertion is TRUE , FALSE , or undefined.  7.8.3.1Every FilterItem includes an AttributeType which identifies the particular attribute concerned.  7.8.3.2Any assertion about the value of such an attribute is only defined if the AttributeType is known, and the purported AttributeValue (s) conforms to the attribute syntax defined for that attribute type. Note 1 Where these conditions are not met the FilterItem is undefined.  Note 2 Access control restrictions may require that the FilterItem be considered undefined.  7.8.3.3Assertions about the value of an attribute are evaluated using the matching rules associated with the attribute syntax defined for that attribute type. A matching rule not defined for a particular attribute syntax cannot be used to make assertions about that attribute. Note Where this condition is not met, the FilterItem is undefined.  7.8.3.4A FilterItem may be undefined (as described in 7.8.3.2 and 7.8.3.3 above). Otherwise, where the FilterItem asserts:  a)(( equality , it is TRUE if and only if there is a value of the attribute which is equal to that asserted;'(  b)(( substrings , it is TRUE if and only if there is a value of the attribute in which the specified substrings appear in the given order. The substrings shall be nonoverlapping, and may (but need not) be separated from the ends of the attribute value and from one another by zero or more string elements.'(  (( If initial is present, the substring shall match the initial substring of the attribute value; if final is present, the substring shall match the final substring of the attribute value; if any is present, the substring may match any substring in the attribute value;'(  c)(( greaterOrEqual , it is TRUE if and only if the relative ordering (as defined by the appropriate ordering algorithm) places the supplied value before or equal to any value of the attribute;'(  d)(( lessOrEqual , it is TRUE if and only if the relative ordering (as defined by the appropriate ordering algorithm) places the supplied value after or equal to any value of the attribute;'(  e)(( present , it is TRUE if and only if such an attribute is present in the entry;'(  f)(( approximateMatch , it is TRUE if and only if there is a value of the attribute which matches that which is asserted by some locallydefined approximate matching algorithm (e.g. spelling variations, phonetic match, etc.). There are no specific guidelines for approximate matching in this version of the Recommendation. If approximate matching is not supported, this FilterItem should be treated as a match for equality .'( 7.9Security Parameters  7.9.1The SecurityParameters govern the operation of various security features associated with a Directory operation.  Note These parameters are conveyed from sender to recipient. Where the parameters appear in the argument of an abstractoperation the requestor is the sender, and the performer is the recipient. In a result, the roles are reversed. ( ,x- 0 X(`,x- SecurityParameters   ::= 0  X% SET {  certificationpath 0  X% [0]  CertificationPath 0  OPTIONAL,  name  0  [1]  DistinguishedName   0  X% OPTIONAL,  time   [2] 0  UTCTime OPTIONAL,  random  0  [3]  BIT STRING OPTIONAL,  target  0  [4]  ProtectionRequest OPTIONAL   0  X%%(++11`4 }  ProtectionRequest   ::= 0  INTEGER {   0   X% none(0),   0  X% signed (1)}  0 X(`,x-( ,x-  7.9.2The various components have the meanings as defined in 7.9.2.1 to 7.9.2.5.  7.9.2.1The CertificationPath component consists of the sender's certificate, and, optionally, a sequence of certificate pairs. The certificate is used to associate the sender's public key and distinguished name, and may be used to verify the signature x0  on the argument or result. This parameter shall be present if the argument or result is signed. The sequence of certification pairs consists of certification authority cross certificates. It is used to enable the sender's certificate to be validated. It is not required if the recipient shares the same certification authority as the sender. If the recipient requires a valid set of certificate pairs, and this parameter is not present, whether the recipient rejects the signature on the argument or result, or attempts to generate the certification path, is a local matter.  7.9.2.2The name is the distinguished name of the first intended recipient of the argument or result. For example, if a DUA generates a signed argument, the name is the distinguished name of the DSA to which the operation is submitted.  7.9.2.3The time is the intended expiry time for the validity of the signature, when signed arguments are used. It is used in conjunction with the random number to enable the detection of replay attacks.  7.9.2.4The random component is a number which should be different for each unexpired token. It is used in conjunction with the time parameter to enable the detection of replay attacks when the argument or result has been signed.  7.9.2.5The target ProtectionRequest may appear only in the request for an operation to be carried out, and indicates the requestor's preference regarding the degree of protection to be provided to the result. Two levels are provided: none (no protection requested), and signed (the Directory is requested to sign the result, the default). The degree of protection actually provided to the result is indicated by the form of result and may be equal to or lower than that requested, based on the limitations of the Directory. 7.10OPTIONALLYSIGNED 7.10.1  An OPTIONALLYSIGNED information type is one whose values may, at the option of the generator, be accompanied by their digital signature. This capability is specified by means of the following macro: ( ,x-( 0 ,x- OPTIONALLYSIGNED MACRO  ::=  BEGIN  TYPE NOTATION  0  ::=  type (Type)  VALUE NOTATION  0  ::=  value (VALUE (  CHOICE { Type, SIGNED Type})  END ( 0 ,x-( ,x-7.10.2  The SIGNED macro, which describes the form of the signed form of the information, is specified in Recommendation X.509. 8  Bind and unbind operations  The DirectoryBind and DirectoryUnbind operations, defined in 8.1 and 8.2 respectively, are used by the DUA at the beginning and end of a particular period of accessing the Directory. 8.1Directory bind  8.1.1A DirectoryBind operation is used at the beginning of a period of accessing the Directory. ( ,x- 0 (,x- DirectoryBind   ::= 0  ABSTRACTBIND  TO { readPort, searchPort, modifyPort }  BIND  ARGUMENT  0  DirectoryBindArgument  RESULT  0  DirectoryBindResult  BINDERROR 0  DirectoryBindError  DirectoryBindArgument 0  ::=  SET {  credentials   [0] 0  Credentials OPTIONAL,  versions   [1] 0  Versions DEFAULT   0  ( v1988}  Credentials  ::=   CHOICE {  simple  0  [0]  SimpleCredentials,  strong  0  [1]  StrongCredentials,  externalProcedure [2] EXTERNAL }  SimpleCredentials   ::= 0  SEQUENCE {  name   [0] 0  DistinguishedName,  validity  0  [1]  SET {   time1   [0] 0  UTCTime OPTIONAL,   Time2   [1] 0  UTCTime OPTIONAL,   random1 0  [2]  BIT STRING OPTIONAL,   random2 0  [3]  BIT STRING OPTIONAL } OPTIONAL,   é in most instances the argument for   é time and random are relevant in   é dialogues employing protected password  0 Ԍ  é mechanisms and derive their meaning   é as per bilateral agreements  password  [2]  0  OCTET STRING OPTIONAL }  é the value could be an unprotected  é password or Protected1 or Protected2  é as specified in Recommendation X.509 .  StrongCredentials   ::= 0  SET {  certificationpath[0] CertificationPath   0  (((+ OPTIONAL,  bindtoken   [1] 0  Token }  Token    ::= 0  SIGNED SEQUENCE {  algorithm   [0] 0  AlgorithmIdentifier,  name   [1] 0  DistinguishedName,  time   [2] 0  UTCTime,  random  0  [3]  BIT STRING }  Versions   ::= 0  BIT STRING {v1988(0)}  DirectoryBindResult   ::= 0  DirectoryBindArgument  DirectoryBindError  0  ::=  ( SET {  versions   [0] 0  Versions DEFAULT v1988,  CHOICE {   serviceError 0  [1]  ServiceProblem   securityError 0  [2]  SecurityProblem  }}   0 (,x-( ,x-8.1.2The various arguments have the meanings as defined in 8.1.2.1 to 8.1.2.2.  8.1.2.1The Credentials of the DirectoryBindArgument allow the Directory to establish the identity of the user. They may be either simple , strong (as described in Recommendation X.509) or externally defined ( externalProcedure ).  8.1.2.1.1  SimpleCredentials consist of a name (always the distinguished name of an object) and (optionally) a password. This provides a limited degree of security. If the password is protected as described in 5 of RecommendationX.509, then SimpleCredentials includes name, password and (optionally) time and/or random numbers which are used to detect replay. In some instances a protected password may be checked by an object which knows the password only after locally regenerating the protection to its own copy of the password and computing the result with the value in the bind argument (password). In other instances a direct compare may be possible.  8.1.2.1.2  StrongCredentials consist of a bind token and, optionally, a certificate and sequence of certificationauthority crosscertificate (as defined in RecommendationX.509). This enables the Directory to authenticate the identity of the request establishing the association, and vice versa. /@The arguments of the bind token are used as follows: algorithm is the identifier of the algorithm employed to sign the information; name is the name of the intended recipient. The time parameter contains the expiry time of the token. The random number is a number which should be different for each unexpired token, and may be used by the recipient to detect replay attacks.  8.1.2.1.3 If externalProcedure is used then the semantics of the authentication scheme being used is outside the scope of the Directory document.  8.1.2.2The Versions argument of the DirectoryBindArgument identifies the versions of the service which the DUA is prepared to participate in. For this version of the protocol the value shall be set to v1988 (0). 8.1.2.3Migration to future versions of the Directory should be facilitated by:  a)(( any elements of DirectoryBindArgument other than those defined in this Recommendation shall be accepted and ignored;'(  b)(( additional options for named bits of DirectoryBindArgument (e.g. Versions ) not defined shall be accepted and ignored.'(  8.1.3Should the bind request succeed, a result will be returned. The result parameters have the meanings as defined in 8.1.3.1 and 8.1.3.2.  8.1.3.1The Credentials of the DirectoryBindResult allow the user to establish the identity of the DSA. They allow information identifying the DSA (that is directly providing the Directory service) to be conveyed to the DUA. They shall be of the same form (i.e. CHOICE ) as those supplied by the user.  8.1.3.2The Versions parameter of the DirectoryBindResult indicates which of the versions of the service requested by the DUA is actually going to be provided by this DSA.  8.1.4Should the bind request fail, a bind error will be returned as defined in 8.1.4.1 and 8.1.4.2.  8.1.4.1The Versions parameter of the DirectoryBindError indicates which versions are supported by this DSA. ( ,x-( ,x-8.1.4.2A securityError or serviceError shall be supplied as follows:  é ( securityError   inappropriateAuthentication  x0 Ԍ(   invalidCredentials  é ( serviceError   unavailable. 8.2Directory unbind  8.2.1A DirectoryUnbind operation is used at the end of a period of accessing the Directory. ( ,x-( ,x- DirectoryUnbind   ::=   ABSTRACTUNBIND ( FROM {readPort, searchPort, modifyPort } ( ,x-( ,x-8.2.2The DirectoryUnbind has no arguments. 9  Directory read operations  There are two "readlike" operations: Read and Compare , defined in 9.1 and 9.2, respectively. The Abandon operation, defined in 9.3, is grouped with the Read operations for convenience. 9.1Read  9.1.1A Read operation is used to extract information from an explicitly identified entry. It may also be used to verify a distinguished name. The arguments of the operation may optionally be signed (see 7.10) by the requestor. If so requested, the Directory may sign the result. ( ,x- 0 ,x- Read  ::=  ABSTRACTOPERATION  ARGUMENT   0  ReadArgument  RESULT   ReadResult  ERRORS {   AttributeError, NameError,   ServiceError, Referral, Abandoned,   SecurityError }  ReadArgument ::=   OPTIONALLYSIGNED SET {  object  0  [0]  Name,   selection   [1] 0  Selection F13 EntryInformationSelection   0  DEFAULT {}  COMPONENTS OF CommonArguments }  ReadResult  ::=   OPTIONALLYSIGNED SET {  entry   [0] 0  EntryInformation,  COMPONENTS OF CommonResults }  0 ,x-( ,x-  9.1.2The various arguments have the meanings as defined in 9.1.2.1 to 9.1.2.3.  9.1.2.1The object argument identifies the object entry from which the information is requested. Should the Name involve one or more aliases, they are dereferenced (unless this is prohibited by the relevant service controls).  9.1.2.2The selection argument indicates what information from the entry is requested (see 7.6).  9.1.2.3The CommonArguments (see 7.3) include a specification of the service controls applying to the request. For the purposes of this operation the sizeLimit component is not relevant and is ignored if provided.  9.1.3Should the request succeed, the result will be returned. The result parameters have the meanings as defined in 9.1.3.1 and 7.4. 9.1.3.1The entry result parameter holds the requested information (see 7.7).  9.1.4Should the request fail, one of the listed errors will be reported. If none of the attributes explicitly listed in selection can be returned, then an AttributeError with problem noSuchAttribute will be reported. The circumstances under which other errors will be reported are defined in 12. 9.2Compare  9.2.1A Compare operation is used to compare a value (which is supplied as an argument of the request) with the value(s) of a particular attribute type in a particular object entry. The arguments of the operation may optionally be signed (see 7.10) by the requestor. If so requested, the Directory may sign the result. ( ,x- @ ,x- Compare  ::=  @  ABSTRACTOPERATION  ARGUMENT  @  CompareArgument  RESULT  @  CompareResult  ERRORS {   AttributeError, NameError,   ServiceError, Referral, Abandoned,   SecurityError }  CompareArgument   ::= @  OPTIONALLYSIGNED  SET {  object  @  [0]  Name,  0 Ԍ purported   [1] @  AttributeValueAssertion,  COMPONENTS OF CommonArguments }  CompareResult  @  ::=  OPTIONALLYSIGNED  SET {  DistinguishedName OPTIONAL,  matched  @  [0]  BOOLEAN,  from Entry   [1] @  BOOLEAN DEFAULT TRUE,  COMPONENTS OF CommonResults }   @ ,x-( ,x-9.2.2The various arguments have the meanings as defined in 9.2.2.1 to 9.2.2.3.  9.2.2.1The object argument is the name of the particular object entry concerned. Should the Name involve one or more aliases, they are dereferenced (unless prohibited by the relevant service control).  9.2.2.2The purported argument identifies the attribute type and the value to be compared with that in the entry.  9.2.2.3The CommonArguments (see 7.3) specify the service controls applying to the request. For the purposes of this operation the sizeLimit component is not relevant and is ignored, if provided.  9.2.3Should the request succeed (i.e. the comparison is actually carried out), the result will be returned. The result parameters have the meanings as described in 9.2.3.1, 9.2.3.2 and 7.4.  9.2.3.1The DistinguishedName is present if an alias was dereferenced and represents the distinguished name of the object itself.  9.2.3.2The matched result parameter, holds the result of the comparison. The parameter takes the value TRUE if the values were compared and matched, and FALSE if they did not.  9.2.3.3If fromEntry is TRUE the information was compared against the entry; if FALSE some of the information was compared against a copy.  9.2.4Should the request fail, one of the listed errors will be reported. The circumstances under which the particular errors will be reported are defined in 12. 9.3Abandon  9.3.1Operations that interrogate the Directory may be abandoned using the Abandon operation if the user is no longer interested in the result. ( ,x-p ,x- Abandon p ::=   ABSTRACTOPERATION  ARGUMENT     AbandonArgument  RESULT p  AbandonResult  ERRORS {AbandonFailed}  AbandonArgument ::=   SEQUENCE {  InvokeID [0] InvokeID}  AbandonResult ::= NULL p ,x-( ,x-  9.3.2There is a single argument, the InvokeID which identifies the operation that is to be abandoned. The value of the invokeID is the same invokeID which was used to invoke the operation which is to be abandoned.  9.3.3Should the request succeed, a result will be returned, although no information will be conveyed with it. The original operation will fail with an Abandoned error.  9.3.4Should the request fail, the AbandonFailed error will be reported. This error is described in 12.3.  9.3.5 Abandon is only applicable to interrogation operations, i.e., Read , Compare , List and Search .  9.3.6A DSA may abandon an operation locally. If the DSA has chained or multicasted the operation to other DSAs, it may in turn request them to abandon the operation. A DSA may choose not to abandon the operation and shall then return the AbandonFailed error. 10  Directory search operations  There are two "searchlike" operations: List and Search , defined in 10.1 and 10.2 respectively. 10.1List 10.1.1  A List operation is used to obtain a list of the immediate subordinates of an explicitly identified entry. Under some 0  circumstances, the list returned may be incomplete. The arguments of the operation may optionally be signed (see 7.10) by the requestor. If so requested, the Directory may sign the result. ( ,x-p ,x- List ::=   ABSTRACTOPERATION  ARGUMENT   ListArgument  RESULT p ListResult  ERRORS {  p  NameError  p ServiceError, Referral, Abandoned,  p SecurityError }  List Argument p ::=   OPTIONALLYSIGNED SET {  object p [0]   Name,  COMPONENTS OF CommonArguments }  ListResult  ::=   OPTIONALLYSIGNED  CHOICE {  listInfo SET {  DistinguishedName OPTIONAL,  subordinates [1]  SET OF SEQUENCE {   RelativeDistinguishedName,   aliasEntry [0]  BOOLEAN DEFAULT FALSE   fromEntry [1]  BOOLEAN DEFAULT TRUE},  partialOutcomeQualifier [2]  p  PartialOutcomeQualifier >@ OPTIONAL  COMPONENTS OF CommonResults },  uncorrelatedListInfo Ġ [0] SET OF  p  ListResult }  PartialOutcomeQualifier ::= SET {  limitProblem [0] LimitProblem  p OPTIONAL,  unexplored [1] SET OF  p ContinuationReference OPTIONAL,  unavailableCriticalExtensions [2] BOOLEAN DEFAULT FALSE }  LimitProblem ::= INTEGER {  timeLimitExceeded (0),  sizeLimitExceeded (1),  administrativeLimitExceeded (2) } p ,x-( ,x-10.1.2 The various arguments have the meanings as defined in 10.1.2.1 and 7.3.  10.1.2.1The object argument identifies the object entry (or possibly the root) whose immediate subordinates are to be listed. Should the Name involve one or more aliases, they are dereferenced (unless prohibited by the relevant service control). 10.1.3  The request succeeds if the object is located regardless of whether there is any subordinate information to return. The result parameters have the meanings as defined in 10.1.3.1 to 10.1.3.4 and 7.4.  10.1.3.1The DistinguishedName is present if an alias was dereferenced. It represents the distinguished name of the object itself.  10.1.3.2The subordinates parameter conveys the information on the immediate subordinate, if any, of the named entry. Should any of the subordinate entries be aliases, they will not be dereferenced. 10.1.3.2.1 ( The RelativeDistinguishedName is that of the subordinate.  10.1.3.2.2 ( The fromEntry parameter indicates whether the information was obtained from the entry ( TRUE ) or a copy of the entry ( FALSE ).  10.1.3.2.3 ( The aliasEntry parameter indicates whether the subordinate entry is an alias entry ( TRUE ) or not ( FALSE ).  10.1.3.3The PartialOutcomeQualifier consists of three subcomponents as defined in 10.1.3.3.1 to 10.1.3.3.3. This parameter shall be present whenever the result is incomplete.  10.1.3.3.1 ( The LimitProblem parameter indicates whether the time limit, the size limit, or an administrative limit has been exceeded. The results being returned are those which were available when the limit was reached.  10.1.3.3.2 ( The unexplored parameter shall be present if regions of the DIT were not explored. Its information allows the DUA to continue the processing of the List operation by contacting other access points if it so chooses. The parameter consists of a set (possibly empty) of ContinuationReference s, each consisting of the name of a base object from which the operation may be progressed, an appropriate value of OperationProgress , and a set of access points from which the request may be further progressed. The ContinuationReference s that are returned shall be within the scope of referral requested in the operation service control.  10.1.3.3.3 ( The unavailableCriticalExtensions parameter indicates, if present, that one or more critical extensions were unavailable in some part of the Directory. /Ԍ 10.1.3.4When the DUA has requested a protection request of signed , the uncorrelatedListInfo parameter may comprise a number of sets of result parameters originating from and signed by different components of the Directory. If no DSA in the chain can correlate all the results, the DUA must assemble the actual result from the various pieces. 10.1.4  Should the request fail, one of the listed errors will be reported. The circumstances under which the particular errors will be reported are defined in 12. 10.2Search 10.2.1  A Search operation is used to search a portion of the DIT for entries of interest and to return selected information from those entries. The arguments of the operation may optionally be signed (see 7.10) by the requestor. If so requested, the Directory may sign the result. ( ,x-p ,x- Search ::=  ABSTRACTOPERATION  ARGUMENT    SearchArgument  RESULT SearchResult  ERRORS {  p AttributeError, NameError,  p ServiceError, Referral, Abandoned,  p SecurityError }  SearchArgument ::= OPTIONALLYSIGNED  SET {  baseObject   [0] Name,  subset p   [1] INTEGER {  p baseObject (0),  p oneLevel(1),  p wholeSubtree(2)} DEFAULT baseObject,  filter    [2] Filter DEFAULT and {}.  searchAliases   [3] BOOLEAN DEFAULT TRUE,  selection   [4] EntryInformationSelection DEFAULT {}   COMPONENTS OF CommonArguments }  SearchResult ::=   OPTIONALLYSIGNED  CHOICE {  searchInfo SET {  DistinguishedName OPTIONAL,  entries [0]   SET OF EntryInformation,  partialOutcomeQualifier   [2]PartialOutcomeQualifier OPTIONAL,  COMPONENTS OF CommonResults },  uncorrelatedSearchInfo [0] SET OF  SearchResult } p ,x-( ,x-10.2.2  The various arguments have the meanings as defined in 10.2.2.1 to 10.2.2.3, 10.2.2.5, and 7.3.  10.2.2.1The baseObject argument identifies the object entry (or possibly the root) relative to which the search is to take place. 10.2.2.2The subset argument indicates whether the search is to be applied to: a)(( the baseObject only;'( b)(( the immediate subordinates of the base object only ( oneLevel );'( c) ( ( the base object and all its subordinates ( wholeSubtree ).'(  10.2.2.3The filter argument is used to eliminate entries from the search space which are not of interest. Information will only be returned on entries which satisfy the filter (see 7.8).  10.2.2.4Aliases shall be dereferenced while locating the base object, subject to the setting of the dontDereferenceAliasesServiceControl . Aliases among the subordinates of the base object shall be dereferenced during the search, subject to the setting of the searchAliases parameter. If the searchAliases parameter is TRUE , aliases shall be dereferenced, if the parameter is FALSE , aliases shall not be dereferenced. If the searchAliases parameter is TRUE , the search shall continue in the subtree of the aliased object.  10.2.2.5The selection argument indicates what information from the entries is requested (see 7.6). 10.2.3  The request succeeds if the base object is located, regardless of whether there are any subordinates to return.  Note As a corollary to this, the outcome of an (unfiltered) Search applied to a single entry may not be identical to a Read which seeks to interrogate the same set of attributes of the entry. This is because the latter will return an x0 AttributeError if none of the selected attributes exist in the entry.  The result parameters have the meanings as defined in 10.2.3.1 to 10.2.3.4 and 7.3.  10.2.3.1The DistinguishedName is present if an alias was dereferenced, and represents the distinguished name of the base object.  10.2.3.2The entries parameter conveys the requested information from each entry (zero or more) which satisfied the filter (see 7.5).  10.2.3.3The PartialOutcomeQualifier consists of two subcomponents as described for the List operation in 10.1.3.4.  10.2.3.4The uncorrelatedSearchInfo parameter is as described for uncorrelatedListInfo in 10.1.3.4. 10.2.4  Should the request fail, one of the listed errors will be reported. The circumstances under which the particular errors will be reported are defined in 12. 11  Directory modify operations  There are four operations to modify the Directory: AddEntry , RemoveEntry , ModifyEntry and  ModifyRDN defined in 11.1 to 11.4 respectively.  Note 1 Each of these abstractoperations identifies the target entry by means of its distinguished name.  Note 2 The success of AddEntry , RemoveEntry , and ModifyRDN operations will be dependent on the physical distribution of the DIB across the Directory. Failure will be reported with an UpdateError and problem affectsMultipleDSAs . See Recommendation X.518. 11.1Add entry 11.1.1  An AddEntry operation is used to add a leaf entry (either an object entry, or an alias entry) to the DIT. The arguments of the operation may optionally be signed (see 7.10) by the requestor. ( ,x-p 0 ,x- AddEntry p ::=   ABSTRACTOPERATION  ARGUMENT  0  AddEntryArgument  RESULT p  AddEntryResult  ERRORS {  p AttributeError, NameError,  p ServiceError, Referral, SecurityError,  p UpdateError }  AddEntryArgument   ::= 0  OPTIONALLYSIGNED  SET {  object p  [0] 0  DistinguishedName,  entry p  [1] 0  SET OF Attribute,  COMPONENTS OF CommonArguments }  AddEntryResult p ::=   NULL p 0 ,x-( ,x-11.1.2 The various arguments have the meanings as defined in 11.1.2.1 to 11.1.2.3.  11.1.2.1The object argument identifies the entry to be added. Its immediate superior, which must already exist for the operation to succeed, can be determined by removing the last RDN component (which belongs to the entry to be created).  11.1.2.2The entry argument contains the attribute information which, together with that from the RDN, constitutes the entry to be created. The Directory shall ensure that the entry conforms to the Directory schema. Where the entry being created is an alias, no check is made to ensure that the aliasedObjectName attribute points to a valid entry.  11.1.2.3The CommonArguments (see 7.3) include a specification of the service controls applying to the request. For the purposes of this operation the dontDereferenceAlias option and the sizeLimit component are not relevant and are ignored if provided. Aliases are never dereferenced by this operation. 11.1.3  Should the request succeed, a result will be returned, although no information will be conveyed with it. 11.1.4  Should the request fail, one of the listed errors will be reported. The circumstances under which the particular errors will be reported are defined in 12. 11.2Remove Entry 11.2.1  A RemoveEntry operation is used to remove a leaf entry (either an object entry or an alias entry) from the DIT. The arguments of the operation may optionally be signed (see 7.10) by the requestor. ( ,x- 0 ,x- RemoveEntry ::=   ABSTRACTOPERATION  ARGUMENT  0  RemoveEntryArgument  RESULT  0  RemoveEntryResult  ERRORS {   NameError,   ServiceError, Referral, SecurityError,   UpdateError}  0Ԍ RemoveEntryArgument ::= Ġ OPTIONALLYSIGNED SET {  object [0] DistinguishedName,  COMPONENTS Ġ OF Ġ CommonArguments }  RemoveEntryResult ::= NULL  0 ,x-( ,x-11.2.2 ( The various arguments have the meanings as defined in 11.2.2.1 and 11.2.2.2.  11.2.2.1The object argument identifies the entry to be deleted. Aliases in the name will not be dereferenced.  11.2.2.2The CommonArguments (see 7.3) include a specification of the service controls applying to the request. For the purposes of this operation the dontDereferenceAlias option and the sizeLimit component are not relevant and are ignored if provided. Aliases are never dereferenced by this operation. 11.2.3  Should the request succeed, a result will be returned, although no information will be conveyed with it. 11.2.4  Should the request fail, one of the listed errors will be reported. The circumstances under which the particular errors will be reported are defined in 12. 11.3Modify Entry 11.3.1  The ModifyEntry operation is used to perform a series of one or more of the following modifications to a single entry: a)( add a new attribute; b)( remove an attribute; c)( add attribute values; d)( remove attribute values; e)( replace attribute values; f)( modify an alias.  The arguments of the operation may optionally be signed (see 7.10) by the requestor. ( ,x-p 0 h,x- ModifyEntry ::= p ABSTRACTOPERATION  ARGUMENT  0  ModifyEntryArgument  RESULT p  ModifyEntryResult  ERRORS {  p AttributeError, NameError,  p ServiceError, Referral, SecurityError,  p UpdateError }  ModifyEntryArgument Ġ ::= 0  OPTIONALLYSIGNED SET {  object p  [0] 0  DistinguishedName,  changes p  [1] 0  SEQUENCE OF EntryModification,  COMPONENTS OF CommonArguments }  ModifyEntryResult ::= 0  NULL  EntryModification ::= 0  CHOICE {  addAttribute Ġ [0] 0  Attribute,  removeAttribute 0  [1] AttributeType,  addValues  0  [2] Attribute,  removeValues 0  [3]  h# Attribute } p 0 h,x-( ,x-11.3.2 The various arguments have the meanings as defined in 11.3.2.1 and 11.3.2.2.  11.3.2.1The object argument identifies the entry to which the modifications should be applied. Any aliases in the name will not be dereferenced.  11.3.2.2The changes argument defines a sequence of modifications, which are applied in the order specified. If any of the individual modifications fails, then an AttributeError is generated and the entry left in the state it was prior to the operation. That is, the operation is atomic. The end result of the sequence of modifications shall not violate the Directory schema. However, it is possible, and sometimes necessary, for the individual EntryModification changes to appear to do so. The following types of modification may occur:  a)(( addAttribute : This identifies a new attribute to be added to the entry, which is fully specified by the argument. Any attempt to add an already existing attribute results in an AttributeError ;'(  b)(( removeAttribute : The argument identifies (by its type) an attribute to be removed from the entry. Any attempt to remove a nonexisting attribute results in an AttributeError ;'(  ( Note This operation is not allowed if the attribute type is present in the RDN.  c)(( addValues : This identifies an attribute by the attribute type in the argument, and specifies one or more attribute values to be added to the attribute. An attempt to add an already existing value results in an error. An attempt to add a value to a nonexistent type results in an error;'( 0Ԍ d)(( removeValues : This identifies an attribute by the attribute type in the argument and specifies one or more attribute values to be removed from the attribute. If the values are not present in the attribute, this results in an AttributeError . If an attempt is made to modify the object class attribute, an update error is returned.'(  ( Note This operation is now allowed if one of the values is present in the RDN.  Values may be replaced by a combination of addValues and removeValues in a single ModifyEntry operation.  11.3.2.3The CommonArguments (see 7.3) include a specification of the service controls applying to the request. For the purposes of this operation the dontDereferenceAlias option and the sizeLimit component are not relevant and are ignored if provided. Aliases are never dereferenced by this operation. 11.3.3  Should the request succeed, a result will be returned although no information will be conveyed with it. 11.3.4  Should the request fail, one of the listed errors will be reported. The circumstances under which the particular errors will be reported are defined in 12. 11.4Modify RDN 11.4.1  The ModifyRDN operation is used to change the Relative Distinguished Name of a leaf entry (either an object entry or an alias entry) in the DIT. The arguments of the operation may optionally be signed (see 7.10) by the requestor. ( ,x-p 0 h,x- ModifyRDN ::= p  ABSTRACTOPERATION  ARGUMENT  0  ModifyRDNArgument  RESULT p  ModifyRDNResult  ERRORS {   NameError,   ServiceError, Referral, SecurityError,   UpdateError }  ModifyRDNArgument ::= 0  OPTIONALLYSIGNED SET {  object p  [0] 0  DistinguishedName,  newRDN  0  [1]  RelativeDistinguishedName,  deleteOldRDN 0  [2]  BOOLEAN DEFAULT FALSE,  COMPONENTS OF CommonArguments }  ModifyRDNResult   ::= 0  NULL p 0 h,x-( ,x-11.4.2 The various parameters have the meanings as defined in 11.4.2.1 to 11.4.2.5.  11.4.2.1The object argument identifies the entry whose Relative Distinguished Name is to be modified. Aliases in the name will not be dereferenced. The immediate superior entry shall not have any NonSpecific Subordinate References (see Recommendation X.518). 11.4.2.2The newRDN argument specifies the new RDN of the entry.  11.4.2.3If an attribute value in the new RDN does not already exist in the entry (either as part of the old RDN or as a nondistinguished value) it is added. If it cannot be added, an error is returned.  11.4.2.4If the deleteOldRDN flag is set, all attribute values in the old RDN which are not in the new RDN are deleted. If this flag is not set, the old values should remain in the entry (not as a part of the RDN). The flag shall be set where a single value attribute in the RDN has its value changed by the operation. If this operation removes the last attribute value of an attribute, that attribute shall be deleted.  11.4.2.5The Common Arguments (see 7.3) include a specification of the service controls applying to the request. For the purposes of this operation the dontDereferenceAlias option and the sizeLimit component are not relevant and are ignored if provided. Aliases are never dereferenced by this operation. 11.4.3  Should the request succeed, a result will be returned, although no information will be conveyed with it. 11.4.4  Should the request fail, one of the listed errors will be reported. The circumstances under which the particular errors will be returned are defined in 12. 11.4.5  As defined in this Recommendation this operation may only be used on a leaf entry.  12  Errors 12.1Error Precedence 12.1.1  The Directory does not continue to perform an operation beyond the point at which it determines that an error is to be reported.  Note 1 An implication of this rule is that the first error encountered can differ for repeated instances of the same query, as there is not a specific logical order in which to process a given query. For example, DSAs may be searched in different orders.  Note 2 The rules of error precedence specified here apply only to the abstract service provided by the Directory as a whole. Different rules apply when the internal structure of the Directory is taken into account. 12.1.2  Should the Directory simultaneously detect more than one error, the following list determines which error is reported. An error higher in the list has a higher logical precedence than one below it and is the error which is reported. a)( NameError  0Ԍb)( UpdateError c)( AttributeError d)( SecurityError e)( ServiceError . 12.1.3 The following errors do not present any precedence conflicts:  a)(( AbandonFailed , because it is specific to one operation, Abandon , which can encounter no other error;'(  b)(( Abandoned , which is not reported if an Abandon operation is received simultaneously with the detection of an error. In this case an AbandonFailed error, reporting the problem tooLate is reported along with the report of the actual error encountered;'(  c)(( Referral , which is not a "real" error, only an indication that the Directory has detected that the DUA must present its request to another access point.'( 12.2Abandoned 12.2.1  This outcome may be reported for any outstanding directory enquiry operation (i.e. Read , Search , Compare , List ) if the DUA invokes an Abandon operation with the appropriate InvokeID .  Abandoned ::=   ABSTRACTERROR not literally an "error" 12.2.2 There are no parameters associated with this error.  12.3Abandon Failed 12.3.1  The AbandonFailed error reports a problem encountered during an attempt to abandon an operation. ( ,x-( ,x- AbandonFailed Ġ ::=   ABSTRACTERROR ( PARAMETER SET { (   problem Ġ [0] AbandonProblem, (   operation Ġ [1] InvokeID}  AbandonProblem Ġ ::=   INTEGER (     noSuchOperation (1), (     tooLate (2), (     cannotAbandon (3) } ( ,x-( ,x-12.3.2  The various parameters have the meanings as defined in 12.3.2.1 and 12.3.2.2.  12.3.2.1The particular problem encountered is specified. Any of the following problems may be indicated:  a)(( noSuchOperation , when the Directory has no knowledge of the operation which is to be abandoned (this could be because no such invoke took place or because the Directory has forgotten about it);'( b)(( tooLate , when the Directory has already responded to the operation;'(  c)(( cannotAbandon , when an attempt has been made to abandon an operation for which this is prohibited (e.g. modify), or the abandon could not be performed.'(  12.3.2.2The identification of the particular operation (invocation) to be abandoned. 12.4Attribute Error 12.4.1 An AttributeError reports an attributerelated problem. ( ,x-(p ,x- AttributeError ::= ABSTRACTERROR (  PARAMETER SET { (  p object [0]  Name, (  p problems [1]  SET OF SEQUENCE {  (  p  problem  [0] AttributeProblem, (  p  type  [1] AttributeType, (  p  value  [2] AttributeValue (  p  - OPTIONAL }}  AttributeProblem ::= INTEGER { ( noSuchAttributeOrValue (1), ( InvalidAttributeSyntax (2), ( undefinedAttributeType (3), ( InappropriateMatching (4), ( constraintViolation (5) ( attributeOrValueAlreadyExists (6) } (p ,x-( ,x-12.4.2  The various parameters have the meanings as described in 12.4.2.1 and 12.4.2.2. 0Ԍ 12.4.2.1The object parameter identifies the entry to which the operation was being applied when the error occurred.  12.4.2.2One or more problems may be specified. Each problem identified below is accompanied by an indication of the attribute type , and if necessary to avoid ambiguity, the value , which caused the problem:  a)(( noSuchAttributeOrValue : The named entry lacks one of the attributes or attribute values specified as an argument of the operation;'(  b)(( invalidAttributeSyntax : A purported attribute value, specified as an argument of the operation, does not conform to the attribute syntax of the attribute type;'(  c)(( undefinedAttributeType : An undefined attribute type was provided as an argument to the operation. This error may occur only in relation to Add , Remove , Modify or ModifyRDN operations;'(  d)(( inappropriateMatching : An attempt was made, e.g. in a filter, to use a matching rule not defined for the attribute type concerned;'(  e)(( constraintViolation : An attribute or attribute value supplied in the argument of abstract operation does not conform to the constraints imposed by Recommendation X.501 or by the attribute definition (e.g. the value exceeds the maximum size allowed);'(  f)(( attributeOrValueAlreadyExists : An attempt was made to add an attribute which already existed in the entry, or a value which already existed in the attribute.'( 12.5Name Error 12.5.1  A NameError reports a problem related to the name provided as an argument to an operation. ( ,x-(p ,x- NameError ::= ABSTRACTERROR ( PARAMETER SET { (   problem [0] NameProblem, (   matched [1] Name}  NameProblem ::= INTEGER { ( noSuchObject (1), ( aliasProblem (2), ( invalidAttributeSyntax (3), ( aliasDereferencingProblem (4) } (p ,x-( ,x-12.5.2  The various parameters have the meanings as described in 12.5.2.1 and 12.5.2.2.  12.5.2.1The particular problem encountered. Any of the following problems may be indicated: a)(( noSuchObject : The name supplied does not match the name of any object;'( b)(( aliasProblem : An alias has been dereferenced which names no object;'(  c)(( invalidAttributeSyntax : An attribute type and its accompanying attribute value in AVA in the name are incompatible;'(  d)(( aliasDereferencingProblem : An alias was encountered in a situation where it was not allowed.'(  12.5.2.2The matched parameter contains the name of the lowest entry (object or alias) in the DIT that was matched and is a truncated form of the name provided or, if an alias has been dereferenced, of the resulting name.  Note If there is a problem with the attribute types and/or values in the name offered in a directory operation argument, this is reported via a NameError (with problem invalidAttributeSyntax ) rather than as an AttributeError or an UpdateError . 12.6Referral 12.6.1  A Referral redirects the serviceuser to one or more access points better equipped to carry out the requested operation. ( ,x-( ,x- Referral ::= ABSTRACTERROR not literally an "error" ( PARAMETER SET { (  candidate   [0] ContinuationReference } ( ,x-( ,x-12.6.2  The error has a single parameter which contains a ContinuationReference which can be used to progress the operation (see RecommendationX.518). 12.7Security Error 12.7.1  A SecurityError reports a problem in carrying out an operation for security reasons. ( ,x-( ,x- SecurityError ::=   ABSTRACTERROR ( PARAMETER SET { (  problem [0] SecurityProblem }  SecurityProblem ::= INTEGER { ( InappropriateAuthentication (1), ( InvalidCredentials (2),  x0Ԍ( InsufficientAccessRights (3), ( InvalidSignature (4), ( protectionRequired (5), ( noInformation (6) } ( ,x-( ,x-12.7.2  The error has a single parameter, which reports the particular problem encountered. The following problems may be indicated:  a)(( inappropriateAuthentication : The level of security associated with the requestor's credentials is inconsistent with the level of protection requested, e.g. simple credentials were supplied while strong credentials were required;'( b)(( invalidCredentials : The supplied credentials were invalid;'(  c)(( insufficientAccessRights : The requestor does not have the right to carry out the requested operation;'( d)(( invalidSignature : The signature of the request was found to be invalid;'(  e)(( protectionRequired : The Directory was unwilling to carry out the requested operation because the argument was not signed;'(  f)(( noInformation : The requested operation produced a security error for which no information is available.'( 12.8Service Error 12.8.1 A ServiceError reports a problem related to the provision of the service. ( ,x-(p ,x- ServiceError ::= ABSTRACTERROR (  PARAMETER SET { (  p problem [0] ServiceProblem },  ServiceProblem ::= INTEGER { (  p busy (1), (  p unavailable (2), (  p unwillingToPerform (3), (  p chainingRequired (4), (  p unableToProceed (5), (  p invalidReference (6), (  p timeLimitExceeded (7), (  p administrativeLimitExceeded (8), (  p loopDetected (9), (  p unavailableCriticalExtension (10), (  p outOfScope (11), (  p ditError (12) } (p ,x-( ,x-12.8.2  The error has a single parameter, which reports the particular problem encountered. The following problems may be indicated:  a)(( busy : The Directory, or some part of it, is presently too busy to perform the requested operation, but may be able to do so after a short while;'( b)(( unavailable : The Directory, or some part of it, is currently unavailable;'(  c)(( unwillingToPerform : The Directory, or some part of it, is not prepared to execute this request, e.g. because it would lead to excessive consumption of resources or violate the policy of an Administrative Authority involved;'(  d)(( chainingRequired : The Directory is unable to accomplish the request other than by chaining, however chaining was prohibited by means of the chainingProhibited service control option;'(  e)(( unableToProceed : The DSA returning this error did not have administrative authority for the appropriate naming context and as a consequence was not able to participate in name resolution;'(  f)(( invalidReference : The DSA was unable to perform the request as directed by the DUA (in  OperationProgress ). This may have arisen due to using an invalid referral;'(  g)(( timeLimitExceeded : The Directory has reached the limit of time set by the user in a service control. No partial results are available to return to the user;'( `-Ԍ h)(( administrativeLimitExceeded : The Directory has reached some limit set by an administrative authority, and no partial results are available to return to the user;'(  i)(( loopDetected : The Directory is unable to accomplish the request due to an internal loop;'(  j)(( unavailableCriticalExtension : The Directory was unable to execute the request because one or more critical extensions were not available;'(  ( ,x-XH@  x|@ ) Recommendation X.511 and ISO 95943, Information Processing Systems Open Systems Interconnection The Directory Abstract Service Definition, were developed in close collaboration and are technically aligned.