+++ /dev/null
-<?xml version="1.0" encoding="UTF-8"?>
-
-<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
- <!ENTITY rfc2119 PUBLIC ''
- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
- <!ENTITY rfc4510 PUBLIC ''
- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4510.xml'>
- <!ENTITY rfc4511 PUBLIC ''
- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4511.xml'>
- <!ENTITY rfc4512 PUBLIC ''
- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4512.xml'>
- <!ENTITY rfc4517 PUBLIC ''
- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4517.xml'>
-]>
-
-<!-- $OpenLDAP$ -->
-
-<rfc category="std" ipr="full3978" docName="draft-masarati-ldap-deref.txt">
-
-<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
-
-<?rfc toc="yes" ?>
-<?rfc symrefs="yes" ?>
-<?rfc sortrefs="yes"?>
-<?rfc iprnotified="no" ?>
-<?rfc strict="yes" ?>
-
- <front>
- <title abbrev='LDAP Deref'>LDAP Dereference Control</title>
- <author initials='P.' surname="Masarati" fullname='Pierangelo Masarati'>
- <organization abbrev='Politecnico di Milano'>
- Politecnico di Milano
- </organization>
- <address>
- <postal>
- <street>Dipartimento di Ingegneria Aerospaziale</street>
- <street>via La Masa 34</street>
- <city>Milano</city>
- <code>20156</code>
- <country>IT</country>
- </postal>
- <phone>+39 02 2399 8309</phone>
- <facsimile>+39 02 2399 8334</facsimile>
- <email>ando@OpenLDAP.org</email>
- <uri>http://www.aero.polimi.it/masarati/</uri>
- </address>
- </author>
- <author initials="H.Y." surname="Chu" fullname="Howard Y. Chu">
- <organization abbrev="Symas Corp.">
- Symas Corporation
- </organization>
- <address>
- <postal>
- <street>18740 Oxnard St., Suite 313A</street>
- <city>Tarzana</city>
- <region>California</region>
- <code>91356</code>
- <country>USA</country>
- </postal>
- <phone>+1 818 757-7087</phone>
- <email>hyc@symas.com</email>
- <uri>http://www.symas.com/</uri>
- </address>
- </author>
- <!--date/-->
- <date month='October' year='2008' />
- <abstract>
- <t>
-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.
- </t>
- </abstract>
- </front>
-
- <middle>
- <section title="Background and Intended Use">
- <t>
-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.
- </t>
-
- <t>
-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 <xref target="RFC4511" />.
- </t>
-
- <t>
-This document describes a LDAP Control <xref target="RFC4511" />
-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.
- </t>
-
- <t>
-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 <xref target="RFC2119" />.
- </t>
- </section>
-
- <section title="The LDAP Dereference Control">
- <section title="Control Semantics">
- <t>
-This control allows specifying a dereference attribute and a set
-of attributes to be dereferenced, as illustrated
-in <xref target="control_request" />.
-The dereference attribute's syntax MUST be 1.3.6.1.4.1.1466.115.121.1.12
-(DN) <xref target="RFC4517" />.
-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 <xref target="control_response" />.
- </t>
-
- <t>
-The control value may contain dereference attribute values without any
-dereferenced attribute values, as detailed in
-<xref target="control_response" />.
-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.
- </t>
-
- <t>
-Attribute description hierarchy <xref target="RFC4512" /> 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.
- </t>
-
- <t>
-This control is only appropriate for the search operation
-<xref target="RFC4511" />.
- </t>
-
- <t>
-The semantics of the criticality field are specified in
-<xref target="RFC4511" />.
-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.
- </t>
-
- <t>
-Servers implementing this technical specification SHOULD publish
-the object identifier deref-oid (IANA assigned;
-see <xref target="iana_considerations" />) as a value
-of the 'supportedControl' attribute <xref target="RFC4512" />
-in their root DSE.
- </t>
-
- <t>
-This control is totally unrelated to alias dereferencing
-<xref target="RFC4511" />.
- </t>
- </section>
-
- <section anchor="control_request" title="Control Request">
- <figure>
- <preamble>
-The control type is deref-oid (IANA assigned;
-see <xref target="iana_considerations" />).
-The specification of the Dereference Control request is:
- </preamble>
- <artwork>
- controlValue ::= SEQUENCE OF derefSpec DerefSpec
-
- DerefSpec ::= SEQUENCE {
- derefAttr attributeDescription, ; with DN syntax
- attributes AttributeList }
-
- AttributeList ::= SEQUENCE OF attr AttributeDescription
- </artwork>
- <postamble>
-Each derefSpec.derefAttr MUST be unique within controlValue.
- </postamble>
- </figure>
- </section>
-
- <section anchor="control_response" title="Control Response">
- <figure>
- <preamble>
-The control type is deref-oid (IANA assigned;
-see <xref target="iana_considerations" />).
-The specification of the Dereference Control response is:
- </preamble>
- <artwork>
- controlValue ::= SEQUENCE OF derefRes DerefRes
-
- DerefRes ::= SEQUENCE {
- derefAttr AttributeDescription,
- derefVal LDAPDN,
- attrVals [0] PartialAttributeList OPTIONAL }
-
- PartialAttributeList ::= SEQUENCE OF
- partialAttribute PartialAttribute
- </artwork>
- </figure>
- <figure>
- <preamble>
-PartialAttribute is defined in <xref target="RFC4511" />;
-the definition is reported here for clarity:
- </preamble>
- <artwork>
- PartialAttribute ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF value AttributeValue }
- </artwork>
- <postamble>
-If partialAttribute.vals is empty, the corresponding partialAttribute
-is omitted.
-If all partialAttribute.vals in attrVals are empty, that derefRes.attrVals
-is omitted.
- </postamble>
- </figure>
- </section>
- </section>
-
- <section title="Examples">
- <figure>
- <preamble>
-Given these entries:
- </preamble>
- <artwork>
- 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
- </artwork>
- </figure>
- <figure>
- <preamble>
-A search could be performed with a Dereference request control value
-specified as
- </preamble>
- <artwork>
- { member, uid }
- </artwork>
- </figure>
- <figure>
- <preamble>
-and the "cn=Test Group" entry would be returned with the response control
-value
- </preamble>
- <artwork>
- { { member, cn=Howard Chu,ou=people,dc=example,dc=org,
- { { uid, [hyc] } } },
- { member, cn=Pierangelo Masarati,ou=people,dc=example,dc=org,
- { { uid, [ando] } } } }
- </artwork>
- </figure>
- </section>
-
- <section title="Implementation Notes">
- <t>
-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.
- </t>
- </section>
-
- <section title="Security Considerations">
- <t>
-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
-<xref target="RFC4511" />.
- </t>
- <t>
-Security considerations described in documents listed in
-<xref target="RFC4510" /> apply.
- </t>
- </section>
-
- <section anchor="iana_considerations" title="IANA Considerations">
- <section title="Object Identifier Registration">
- <figure>
- <preamble>
-It is requested that IANA register upon Standards Action an LDAP
-Object Identifier for use in this technical specification.
- </preamble>
- <artwork>
- 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
- </artwork>
- </figure>
- </section>
- </section>
-
- <section title="Acknowledgments">
- <t>
-TBD
- </t>
- </section>
- </middle>
-
- <back>
- <references title='Normative References'>
- &rfc2119;
- &rfc4510;
- &rfc4511;
- &rfc4512;
- &rfc4517;
- </references>
-
- </back>
-
-</rfc>
+++ /dev/null
-<?xml version="1.0" encoding="UTF-8"?>
-
-<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
- <!ENTITY rfc2119 PUBLIC ''
- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
- <!ENTITY rfc4510 PUBLIC ''
- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4510.xml'>
- <!ENTITY rfc4511 PUBLIC ''
- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4511.xml'>
- <!ENTITY rfc4512 PUBLIC ''
- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4512.xml'>
- <!ENTITY rfc4526 PUBLIC ''
- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4526.xml'>
- <!ENTITY rfc4529 PUBLIC ''
- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4529.xml'>
-]>
-
-<!-- $OpenLDAP$ -->
-
-<rfc category="std" ipr="full3978" docName="draft-masarati-ldap-whatfailed.txt">
-
-<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
-
-<?rfc toc="yes" ?>
-<?rfc symrefs="yes" ?>
-<?rfc sortrefs="yes"?>
-<?rfc iprnotified="no" ?>
-<?rfc strict="yes" ?>
-
- <front>
- <title abbrev='LDAP WHATFAILED'>LDAP "What Failed?" Control</title>
- <author initials='P.' surname="Masarati" fullname='Pierangelo Masarati'>
- <organization abbrev='Politecnico di Milano'>
- Politecnico di Milano
- </organization>
- <address>
- <postal>
- <street>Dipartimento di Ingegneria Aerospaziale</street>
- <street>via La Masa 34</street>
- <city>Milano</city>
- <code>20156</code>
- <country>IT</country>
- </postal>
- <phone>+39 02 2399 8309</phone>
- <facsimile>+39 02 2399 8334</facsimile>
- <email>ando@OpenLDAP.org</email>
- <uri>http://www.aero.polimi.it/masarati/</uri>
- </address>
- </author>
- <!--date/-->
- <date month='October' year='2008' />
- <abstract>
- <t>
-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.
- </t>
- </abstract>
- </front>
-
- <middle>
- <section title="Background and Intended Use">
- <t>
-The LDAP Protocol <xref target="RFC4510" /> is extensible.
-Extensions include controls, extended requests and extensions related
-to other aspects of the protocol, for example those described in
-<xref target="RFC4526" />, <xref target="RFC4529" /> and more.
- </t>
-
- <t>
-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 <xref target="RFC4511" />,
-implementations MUST NOT rely on the returned values,
-which are simply intended to be presented as are to human users.
- </t>
-
- <t>
-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.
- </t>
-
- <t>
-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.
- </t>
-
- <t>
-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 <xref target="RFC2119" />.
- </t>
- </section>
-
- <section title='LDAP "What Failed?" Control'>
- <section title="Control Semantics">
- <t>
-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.
- </t>
-
- <t>
-The criticality of the control in the request SHOULD be FALSE.
-According to the semantics of the criticality field as indicated
-in <xref target="RFC4511" />, this ensures that in case the control
-is not recognized by the DSA, it does not cause itself an error.
- </t>
-
- <t>
-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.
- </t>
-
- <t>
-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.
- </t>
-
- <t>
-Servers implementing this technical specification SHOULD publish
-the object identifier whatFailed-oid (IANA assigned;
-see <xref target="iana_considerations" />) as a value
-of the 'supportedControl' attribute <xref target="RFC4512" />
-in their root DSE.
- </t>
- </section>
-
- <section title="Control Request">
- <t>
-The controlType is whatFailed-oid (IANA assigned;
-see <xref target="iana_considerations" />);
-the controlValue MUST be absent;
-the criticality SHOULD be FALSE.
- </t>
- </section>
-
- <section title="Control Response">
- <figure>
- <preamble>
-The controlType is whatFailed-oid (IANA assigned;
-see <xref target="iana_considerations" />);
-the controlValue is:
- </preamble>
- <artwork>
- controlValue ::= SET OF oid LDAPOID
- </artwork>
- <postamble>
-If the set of extension OID is empty, the control is omitted
-from the response.
-The criticality MUST be FALSE.
- </postamble>
- </figure>
- </section>
- </section>
-
- <section title="Implementation Notes">
- <t>
-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.
- </t>
- </section>
-
- <section title="Security Considerations">
- <t>
-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.
- </t>
- </section>
-
- <section anchor="iana_considerations" title="IANA Considerations">
- <section title="Object Identifier Registration">
- <figure>
- <preamble>
-It is requested that IANA register upon Standards Action an LDAP
-Object Identifier for use in this technical specification.
- </preamble>
- <artwork>
- 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
- </artwork>
- </figure>
- </section>
- </section>
-
- <section title="Acknowledgments">
- </section>
- </middle>
-
- <back>
- <references title='Normative References'>
- &rfc2119;
- &rfc4510;
- &rfc4511;
- &rfc4512;
- </references>
- <references title='Informative References'>
- &rfc4526;
- &rfc4529;
- </references>
- </back>
-
-</rfc>
projects / openldap / commitdiff