From 653b7e3e83bcc6ae7ae06f7fc0ebe58b859abc78 Mon Sep 17 00:00:00 2001
From: Quanah Gibson-Mount <quanah@openldap.org>
Date: Mon, 10 Nov 2008 20:33:42 +0000
Subject: [PATCH] More on deref

---
 doc/drafts/draft-masarati-ldap-deref-xx.txt | 728 ++++++++++++++++++++
 doc/drafts/draft-masarati-ldap-deref.xml    | 350 ++++++++++
 2 files changed, 1078 insertions(+)
 create mode 100644 doc/drafts/draft-masarati-ldap-deref-xx.txt
 create mode 100644 doc/drafts/draft-masarati-ldap-deref.xml

diff --git a/doc/drafts/draft-masarati-ldap-deref-xx.txt b/doc/drafts/draft-masarati-ldap-deref-xx.txt
new file mode 100644
index 0000000000..c5c9259367
--- /dev/null
+++ b/doc/drafts/draft-masarati-ldap-deref-xx.txt
@@ -0,0 +1,728 @@
+
+
+
+Network Working Group                                        P. Masarati
+Internet-Draft                                     Politecnico di Milano
+Intended status: Standards Track                                  H. Chu
+Expires: April 4, 2009                                       Symas Corp.
+                                                            October 2008
+
+
+                        LDAP Dereference Control
+                     draft-masarati-ldap-deref.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on April 4, 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu            Expires April 4, 2009                 [Page 1]
+
+Internet-Draft                 LDAP Deref                   October 2008
+
+
+Abstract
+
+   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.
+
+
+Table of Contents
+
+   1.  Background and Intended Use  . . . . . . . . . . . . . . . . .  3
+   2.  The LDAP Dereference Control . . . . . . . . . . . . . . . . .  4
+     2.1.  Control Semantics  . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Control Request  . . . . . . . . . . . . . . . . . . . . .  5
+     2.3.  Control Response . . . . . . . . . . . . . . . . . . . . .  5
+   3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Implementation Notes . . . . . . . . . . . . . . . . . . . . .  7
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+     6.1.  Object Identifier Registration . . . . . . . . . . . . . .  9
+   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
+   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
+   Intellectual Property and Copyright Statements . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu            Expires April 4, 2009                 [Page 2]
+
+Internet-Draft                 LDAP Deref                   October 2008
+
+
+1.  Background and Intended Use
+
+   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 [RFC4511].
+
+   This document describes a LDAP Control [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.
+
+   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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu            Expires April 4, 2009                 [Page 3]
+
+Internet-Draft                 LDAP Deref                   October 2008
+
+
+2.  The LDAP Dereference Control
+
+2.1.  Control Semantics
+
+   This control allows specifying a dereference attribute and a set of
+   attributes to be dereferenced, as illustrated in Section 2.2.  The
+   dereference attribute's syntax MUST be 1.3.6.1.4.1.1466.115.121.1.12
+   (DN) [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 Section 2.3.
+
+   The control value may contain dereference attribute values without
+   any dereferenced attribute values, as detailed in Section 2.3.  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 [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.
+
+   This control is only appropriate for the search operation [RFC4511].
+
+   The semantics of the criticality field are specified in [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.
+
+   Servers implementing this technical specification SHOULD publish the
+   object identifier deref-oid (IANA assigned; see Section 6) as a value
+   of the 'supportedControl' attribute [RFC4512] in their root DSE.
+
+   This control is totally unrelated to alias dereferencing [RFC4511].
+
+
+
+
+
+
+
+
+
+Masarati & Chu            Expires April 4, 2009                 [Page 4]
+
+Internet-Draft                 LDAP Deref                   October 2008
+
+
+2.2.  Control Request
+
+   The control type is deref-oid (IANA assigned; see Section 6).  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.
+
+2.3.  Control Response
+
+   The control type is deref-oid (IANA assigned; see Section 6).  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 [RFC4511]; 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.
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu            Expires April 4, 2009                 [Page 5]
+
+Internet-Draft                 LDAP Deref                   October 2008
+
+
+3.  Examples
+
+   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] } } } }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu            Expires April 4, 2009                 [Page 6]
+
+Internet-Draft                 LDAP Deref                   October 2008
+
+
+4.  Implementation Notes
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu            Expires April 4, 2009                 [Page 7]
+
+Internet-Draft                 LDAP Deref                   October 2008
+
+
+5.  Security Considerations
+
+   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
+   [RFC4511].
+
+   Security considerations described in documents listed in [RFC4510]
+   apply.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu            Expires April 4, 2009                 [Page 8]
+
+Internet-Draft                 LDAP Deref                   October 2008
+
+
+6.  IANA Considerations
+
+6.1.  Object Identifier Registration
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu            Expires April 4, 2009                 [Page 9]
+
+Internet-Draft                 LDAP Deref                   October 2008
+
+
+7.  Acknowledgments
+
+   TBD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu            Expires April 4, 2009                [Page 10]
+
+Internet-Draft                 LDAP Deref                   October 2008
+
+
+8.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4510]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510,
+              June 2006.
+
+   [RFC4511]  Sermersheim, J., "Lightweight Directory Access Protocol
+              (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Directory Information Models", RFC 4512,
+              June 2006.
+
+   [RFC4517]  Legg, S., "Lightweight Directory Access Protocol (LDAP):
+              Syntaxes and Matching Rules", RFC 4517, June 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu            Expires April 4, 2009                [Page 11]
+
+Internet-Draft                 LDAP Deref                   October 2008
+
+
+Authors' Addresses
+
+   Pierangelo Masarati
+   Politecnico di Milano
+   Dipartimento di Ingegneria Aerospaziale
+   via La Masa 34
+   Milano  20156
+   IT
+
+   Phone: +39 02 2399 8309
+   Fax:   +39 02 2399 8334
+   Email: ando@OpenLDAP.org
+   URI:   http://www.aero.polimi.it/masarati/
+
+
+   Howard Y. Chu
+   Symas Corporation
+   18740 Oxnard St., Suite 313A
+   Tarzana, California  91356
+   USA
+
+   Phone: +1 818 757-7087
+   Email: hyc@symas.com
+   URI:   http://www.symas.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu            Expires April 4, 2009                [Page 12]
+
+Internet-Draft                 LDAP Deref                   October 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu            Expires April 4, 2009                [Page 13]
+
diff --git a/doc/drafts/draft-masarati-ldap-deref.xml b/doc/drafts/draft-masarati-ldap-deref.xml
new file mode 100644
index 0000000000..aab2f032f5
--- /dev/null
+++ b/doc/drafts/draft-masarati-ldap-deref.xml
@@ -0,0 +1,350 @@
+<?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 &amp; email address to contact for further information:
+          Pierangelo Masarati &lt;ando@OpenLDAP.org&gt;
+      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>
-- 
2.39.5