From dde7a8021a9689af63f40ad1a5e798752ba0ad10 Mon Sep 17 00:00:00 2001 From: Quanah Gibson-Mount Date: Tue, 11 Nov 2008 00:08:16 +0000 Subject: [PATCH] Remove per ando --- doc/drafts/draft-masarati-ldap-deref.xml | 350 ------------------ doc/drafts/draft-masarati-ldap-whatfailed.xml | 240 ------------ 2 files changed, 590 deletions(-) delete mode 100644 doc/drafts/draft-masarati-ldap-deref.xml delete mode 100644 doc/drafts/draft-masarati-ldap-whatfailed.xml diff --git a/doc/drafts/draft-masarati-ldap-deref.xml b/doc/drafts/draft-masarati-ldap-deref.xml deleted file mode 100644 index aab2f032f5..0000000000 --- a/doc/drafts/draft-masarati-ldap-deref.xml +++ /dev/null @@ -1,350 +0,0 @@ - - - - - - - -]> - - - - - - - - - - - - - - - LDAP Dereference Control - - - Politecnico di Milano - -
- - Dipartimento di Ingegneria Aerospaziale - via La Masa 34 - Milano - 20156 - IT - - +39 02 2399 8309 - +39 02 2399 8334 - ando@OpenLDAP.org - http://www.aero.polimi.it/masarati/ -
- - - - Symas Corporation - -
- - 18740 Oxnard St., Suite 313A - Tarzana - California - 91356 - USA - - +1 818 757-7087 - hyc@symas.com - http://www.symas.com/ -
- - - - - -This document describes the Dereference Control for LDAP. -This control is intended to provide a concise means to collect -extra information related to cross-links present in entries -returned as part of search responses. - - - - - -
- -Cross-links between entries are often used to describe relationships -between entries. -To exploit the uniqueness of entries naming, these links are usually -represented by the distinguished name (DN) of the linked entries. - - - -In many cases, DUAs need to collect information about linked entries. -This requires to explicitly dereference each linked entry in order to -collect the desired attributes, resulting in the need to perform a -specific sequence of search operations, using the links as search base, -with a SearchRequest.scope of baseObject . - - - -This document describes a LDAP Control -that allows a DUA to request the DSA to return specific attributes -of linked entries along with the link, under the assumption that -this operation can be performed by the DSA in a more efficient manner -than the DUA would itself by performing the complete sequence -of required search operations. - - - -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 . - -
- -
-
- -This control allows specifying a dereference attribute and a set -of attributes to be dereferenced, as illustrated -in . -The dereference attribute's syntax MUST be 1.3.6.1.4.1.1466.115.121.1.12 -(DN) . -Each value of the dereference attribute in a SearchResultEntry SHOULD -result in dereferencing the corresponding entry, collecting the values -of the attributes to be dereferenced, and returning them as part -of the control value in the SearchResultEntry response, in the format -detailed in . - - - -The control value may contain dereference attribute values without any -dereferenced attribute values, as detailed in -. -The control semantics does not specify whether this is a consequence -of a dangling link or of the application of access restrictions -on the values of the attributes to be dereferenced. - - - -Attribute description hierarchy SHALL NOT -be exploited when collecting the values of the attributes -to be dereferenced. -On the contrary, all of the attribute descriptions in an attribute -hierarchy SHOULD be treated as distinct and unrelated descriptions. - - - -This control is only appropriate for the search operation -. - - - -The semantics of the criticality field are specified in -. -In detail, the criticality of the control determines whether the control -will or will not be used, and if it will not be used, whether the operation -will continue without returning the control in the response, or fail, -returning unavailableCriticalExtension. -If the control is appropriate for an operation and, for any reason, -it cannot be applied in its entirety to a single SearchResultEntry response, -it MUST NOT be applied to that specific SearchResultEntry response, -without affecting its application to any subsequent SearchResultEntry -response. - - - -Servers implementing this technical specification SHOULD publish -the object identifier deref-oid (IANA assigned; -see ) as a value -of the 'supportedControl' attribute -in their root DSE. - - - -This control is totally unrelated to alias dereferencing -. - -
- -
-
- -The control type is deref-oid (IANA assigned; -see ). -The specification of the Dereference Control request is: - - - controlValue ::= SEQUENCE OF derefSpec DerefSpec - - DerefSpec ::= SEQUENCE { - derefAttr attributeDescription, ; with DN syntax - attributes AttributeList } - - AttributeList ::= SEQUENCE OF attr AttributeDescription - - -Each derefSpec.derefAttr MUST be unique within controlValue. - -
-
- -
-
- -The control type is deref-oid (IANA assigned; -see ). -The specification of the Dereference Control response is: - - - controlValue ::= SEQUENCE OF derefRes DerefRes - - DerefRes ::= SEQUENCE { - derefAttr AttributeDescription, - derefVal LDAPDN, - attrVals [0] PartialAttributeList OPTIONAL } - - PartialAttributeList ::= SEQUENCE OF - partialAttribute PartialAttribute - -
-
- -PartialAttribute is defined in ; -the definition is reported here for clarity: - - - PartialAttribute ::= SEQUENCE { - type AttributeDescription, - vals SET OF value AttributeValue } - - -If partialAttribute.vals is empty, the corresponding partialAttribute -is omitted. -If all partialAttribute.vals in attrVals are empty, that derefRes.attrVals -is omitted. - -
-
-
- -
-
- -Given these entries: - - - dn: cn=Howard Chu,ou=people,dc=example,dc=org - objectClass: inetOrgPerson - cn: Howard Chu - sn: Chu - uid: hyc - - dn: cn=Pierangelo Masarati,ou=people,dc=example,dc=org - objectClass: inetOrgPerson - cn: Pierangelo Masarati - sn: Masarati - uid: ando - - dn: cn=Test Group,ou=groups,dc=example,dc=org - objectClass: groupOfNames - cn: Test Group - member: cn=Howard Chu,ou=people,dc=example,dc=org - member: cn=Pierangelo Masarati,ou=people,dc=example,dc=org - -
-
- -A search could be performed with a Dereference request control value -specified as - - - { member, uid } - -
-
- -and the "cn=Test Group" entry would be returned with the response control -value - - - { { member, cn=Howard Chu,ou=people,dc=example,dc=org, - { { uid, [hyc] } } }, - { member, cn=Pierangelo Masarati,ou=people,dc=example,dc=org, - { { uid, [ando] } } } } - -
-
- -
- -This LDAP extension is currently implemented in OpenLDAP software -using the temporary OID 1.3.6.1.4.1.4203.666.5.16 under OpenLDAP's -experimental OID arc. - -
- -
- -The control result MUST NOT disclose information the client's identity -could not have accessed by performing the related search operations. -The presence of a derefRes.derefVal in the response control, with -no derefRes.attrVals, does not imply neither the existence of nor any -access privilege to the corresponding entry. -It is merely a consequence of the read access the client's identity has -on the corresponding value of the derefRes.derefAttr that would be returned -as part of the attributes of a SearchResultEntry response -. - - -Security considerations described in documents listed in - apply. - -
- -
-
-
- -It is requested that IANA register upon Standards Action an LDAP -Object Identifier for use in this technical specification. - - - Subject: Request for LDAP OID Registration - Person & email address to contact for further information: - Pierangelo Masarati <ando@OpenLDAP.org> - Specification: (I-D) - Author/Change Controller: IESG - Comments: - Identifies the LDAP Dereference Control request - and response - -
-
-
- -
- -TBD - -
- - - - - &rfc2119; - &rfc4510; - &rfc4511; - &rfc4512; - &rfc4517; - - - - - diff --git a/doc/drafts/draft-masarati-ldap-whatfailed.xml b/doc/drafts/draft-masarati-ldap-whatfailed.xml deleted file mode 100644 index 1d8ce5e470..0000000000 --- a/doc/drafts/draft-masarati-ldap-whatfailed.xml +++ /dev/null @@ -1,240 +0,0 @@ - - - - - - - - -]> - - - - - - - - - - - - - - - LDAP "What Failed?" Control - - - Politecnico di Milano - -
- - Dipartimento di Ingegneria Aerospaziale - via La Masa 34 - Milano - 20156 - IT - - +39 02 2399 8309 - +39 02 2399 8334 - ando@OpenLDAP.org - http://www.aero.polimi.it/masarati/ -
- - - - - -This document describes the LDAP "What Failed?" control. -This control allows DUAs to request, in response to a failed operation -request, the object identifier of those extensions that caused -the operation to fail. - - - - - -
- -The LDAP Protocol is extensible. -Extensions include controls, extended requests and extensions related -to other aspects of the protocol, for example those described in -, and more. - - - -Operations may fail for different reasons. -The resultCode may help in determining the reason of a failure. -The (optional) diagnosticsMessage fields of a LDAPResponse -could also be of help. -However, according to , -implementations MUST NOT rely on the returned values, -which are simply intended to be presented as are to human users. - - - -In case of failure related to the inability to process a control -marked as critical in a request, the specific resultCode -unavailableCriticalExtension is returned. -In case of failure related to an unrecognized extendedReq, the generic -resultCode protocolError is returned. -Failures related to handling other extensions may result -in other generic resultCode values. - - - -As a consequence, DUAs may be unable to exactly determine -what extension, if any, caused a failure. -The "What Failed?" control represents a means for the DSA to inform -DUAs about what specific extensions, if any, caused an error notified -by the DSA. - - - -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 . - -
- -
-
- -The presence of the "What Failed?" LDAP control in a LDAP request -indicates that the DUA, in case of error, wishes to receive detailed -information about what extension, if any, caused the error. - - - -The criticality of the control in the request SHOULD be FALSE. -According to the semantics of the criticality field as indicated -in , this ensures that in case the control -is not recognized by the DSA, it does not cause itself an error. - - - -The presence of this control in a request does not guarantee that the DSA -will return detailed information about what extensions caused an error. -Considering the requirement on the criticality of the control, -the DSA MAY simply choose to ignore the control. -The DSA MAY hide information about failure in handling an extension -to prevent disclosure of other information. -The DSA MAY choose to notify an error as soon as it is detected, -instead of proceed checking its ability to handle any other extension -present in a request. - - - -Implementations may choose to check the validity of extensions, -including controls, as soon as they are parsed. -As a consequence, a critical control might result in an error -before thw "What Failed?" control request is parsed. -Implementations SHOULD check anyway the presence of this control, -unless they detect that the remaining part of the request -is malformed. -Clients SHOULD NOT rely on any specific ordering of controls handling -when requesting the "What Failed?" control. - - - -Servers implementing this technical specification SHOULD publish -the object identifier whatFailed-oid (IANA assigned; -see ) as a value -of the 'supportedControl' attribute -in their root DSE. - -
- -
- -The controlType is whatFailed-oid (IANA assigned; -see ); -the controlValue MUST be absent; -the criticality SHOULD be FALSE. - -
- -
-
- -The controlType is whatFailed-oid (IANA assigned; -see ); -the controlValue is: - - - controlValue ::= SET OF oid LDAPOID - - -If the set of extension OID is empty, the control is omitted -from the response. -The criticality MUST be FALSE. - -
-
-
- -
- -The "What Failed?" LDAP Control is implemented in OpenLDAP software -using the temporary OID 1.3.6.1.4.1.4203.666.5.17 under OpenLDAP's -experimental OID arc. - -
- -
- -Implementations MUST take measures to prevent the disclosure -of sensible information whenever this may result from disclosing -what extension caused an error. -This can consist in excluding the OID of specific extensions from -the controlValue in the response, or in entirely omitting the control -in the response. - -
- -
-
-
- -It is requested that IANA register upon Standards Action an LDAP -Object Identifier for use in this technical specification. - - - Subject: Request for LDAP OID Registration - Person & email address to contact for further information: - Pierangelo Masarati <ando@OpenLDAP.org> - Specification: (I-D) - Author/Change Controller: IESG - Comments: - Identifies the LDAP "What Failed?" Control request - and response - -
-
-
- -
-
- - - - - &rfc2119; - &rfc4510; - &rfc4511; - &rfc4512; - - - &rfc4526; - &rfc4529; - - - - -- 2.39.5