idnits 2.17.1 draft-lloyd-ldap-list-read-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 329 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of lines with control characters in the document. ** The abstract seems to contain references ([LDAP], [KEYWORDS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 178: '...them MUST process them as a standard L...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 62 has weird spacing: '...derable clien...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 September 1998) is 9351 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'LDAP' on line 209 looks like a reference -- Missing reference section? 'KEYWORDS' on line 206 looks like a reference -- Missing reference section? 'APPLICATION 17' on line 94 looks like a reference -- Missing reference section? 'APPLICATION 18' on line 111 looks like a reference -- Missing reference section? 'APPLICATION 19' on line 138 looks like a reference -- Missing reference section? 'APPLICATION 20' on line 155 looks like a reference -- Missing reference section? '1' on line 158 looks like a reference -- Missing reference section? '0' on line 162 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LDAPEXT Working Group Alan Lloyd 3 INTERNET-DRAFT PROPOSAL OpenDirectory 4 Intended Category: Standards Track 5 Expires: TBD 7 18 September 1998 9 List and Read Operations: LDAP-X.500 Alignment 10 12 1. Status of this Memo 14 This document is a proposal. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 To view the entire list of current Internet-Drafts, please check 28 the "1id-abstracts.txt" listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 30 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 31 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 32 (US West Coast). 34 LDAP List and Read Operations 36 2. Abstract 38 LDAP was originally developed as a lightweight protocol but through its 39 development it has added many features to a point where there is very 40 little difference in terms of simplicity or code size to that of DAP. 41 However, DAP included features which provided efficient navigation 42 through a multi server distributed directory systems (List), efficient 43 retreival (Read)and the ability to provide service controls to select 44 operation requestpriority, permit/deny chained operations and the 45 ability to select master/replica data in the operation response. 47 LDAP is now widely used as the access for X.500 distributed directory 48 systems, however LDAP in its original form omitted the items (List, Read 49 and Service Controls) as defined above. 50 The List/Read requirements were serviced by LDAP through the use of 51 "pre-selected" Search operations. The Service Controls as per X.511 52 for distributed operation control have in most part been omitted from 53 LDAP. (These are the subject of another proposal.) 55 Experience in the field is showing that not having a List (and to a 56 lesser degree, Read) operations in LDAP accessing to distributed 57 directory system causes very inefficient multi server 58 navigation compared to that of an LDAP Search being used. A Search 59 operation is the most complicated of directory services, yet in the LDAP 60 case it is being used for lesser and more efficient functions. 61 For instance, in the LDAP only multi - server environments, not having 62 a List operation causes considerable client re processing and protocol 63 exchanges due to dealing with system referrals. This leads to extended 64 user/client response times. For those who have already implemented a 65 LDAP Search operation a Read and List should be of little consequence. 67 This document defines two additional operations for LDAP namely List 68 and Read that extend the LDAPv3 [LDAP] operations to provide a simple 69 navigation/browsing and information retrieval mechanism by which a 70 LDAP client can be more effective in dealing with a distributed 71 directory system. 73 In addition, the operations proposed provide major step in the 74 alignment of LDAP and DAP and their use of X.500. This will permit 75 functional consistency to be achieved in directory enabled applications 76 that use LDAP for access to X.500 systems. 78 In order to distinguish this functionality from LDAP V3 capable systems, 79 an upgrade to LDAP V4 is also proposed. 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 83 to be interpreted as described in RFC 2119 [KEYWORDS]. 85 3. General Approach 87 The approach taken to implement the features required is define the 88 List and Read as per X.511 (DAP). 90 4. Directory Read Operation 91 A read operation is used to extract information from an explicitly 92 identified entry. It may also be used to verify a distinguished name. 94 ReadRequest ::= [APPLICATION 17] SEQUENCE { 95 entry LDAPDN, 96 derefAliases ENUMERATED { 97 neverDerefAliases (0),--default 98 derefAlways (3) }, 99 typesOnly BOOLEAN, 100 attributes AttributeDescriptionList } 102 The base level definitions of the Read Request and Result parameters 103 are defined in [LDAP]. 105 4.1 Read Result 107 The results of the Read attempted by the server upon receipt of a 108 Read Request are returned in Read Response, which is an LDAP 109 message containing either Entry data or an Error. 111 ReadResult ::= [APPLICATION 18] SEQUENCE { 112 LDAPResult, 113 attributes PartialAttributeList } 115 PartialAttributeList ::= SEQUENCE OF SEQUENCE { 116 type AttributeDescription, 117 vals SET OF AttributeValue } 119 -- implementors should note that the PartialAttributeList may 120 -- have zero elements (if none of the attributes of that entry 121 -- were requested, or could be returned), and that the vals set 122 -- may also have zero elements (if types only was requested, or 123 -- all values were excluded from the result.) 125 Upon receipt of a Read Request, a server will perform the necessary 126 selection of the DN requested. 128 5. Directory List operation 129 A list operation is used to efficiently obtain a list of the relative 130 names of the immediate subordinates of an explicitly identified entry. 131 Under some circumstances,(such as size/time limitations) the list 132 returned may be incomplete. 134 5.1 List Request 136 The List Request is defined as follows: 138 ListRequest ::= [APPLICATION 19] SEQUENCE { 139 baseObject LDAPDN, 140 derefAliases ENUMERATED { 141 neverDerefAliases (0),--default 142 derefAlways (3) }, 143 sizeLimit INTEGER (0 .. maxInt), 144 timeLimit INTEGER (0 .. maxInt)} 146 The base level definitions of the List Request and Result parameters 147 are defined in [LDAP]. 149 5.1 List Result 151 The results of the List attempted by the server upon receipt of a 152 List Request are returned in List Response, which is an LDAP 153 message containing either RelativeLDAPDN(s) or an Error. 155 ListResult ::= [APPLICATION 20] SEQUENCE { 156 LDAPResult, 157 result ::= CHOICE { 158 listInfo [1] SET OF SEQUENCE { 159 rdn RelativeLDAPDN, 160 aliasEntry [0]BOOLEAN DEFAULT FALSE, 161 fromEntry [1]BOOLEAN DEFAULT TRUE } 162 uncorrelatedListInfo[0] SET OF ListResult }, 164 -- implementors should note that the RelativeLDAPDNList may 165 -- have zero elements (if no subordinates exist). And that the 166 -- the matchedDN / LDAPDN component of the LDAPresult is set 167 -- to the baseObject. 169 The use of uncorrelatedListInfo permits the List response to deal with 170 responses that are received from distributed servers/DSAs that were 171 involved with the List operation. Generally this parameter is only used 172 where signed operations are performed between some servers involved with 173 the List operation. 175 6. Compliance 177 Upon receiving either of these operations, a server that supports 178 them MUST process them as a standard LDAPv3 operation. 180 Compliance to the support of the above operations will be specified 181 in the respective Server or Client profiles or X.500/DAP/LDAP ISPs. 183 6. Security Considerations 185 General security issues apply as per LDAP and X.500. 187 7. Associated Proposals 189 This proposal accompanies a proposal to align the service control 190 aspects of LDAP V3 and X.511. 191 draft-lloyd-ldap-svcs-00.txt 193 8. Acknowledgements 195 This document is an update to RFC 2251, by Mark. Wahl, ,Tim 196 Howes, and Steve Kille. Design ideas included in this document are 197 based on those provided in the X.500 ISO/ITU specifications. The 198 contributions of individuals in these working groups is gratefully 199 acknowledged. 201 9. Copyright 202 TBS 204 10. Bibliography 206 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Require- 207 ment Levels", RFC 2119, March 1997. 209 [LDAP] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 210 Protocol (v3)", RFC 2251, December 1997. 212 [X.208] CCITT Recommendation X.208: Specification of Abstract 213 Syntax Notation One (ASN.1), 1988. 215 [X.501] ITU-T Recommendation X.501: Information 216 Technology - Open Systems Interconnection - The 217 Directory: Models, 1993. 219 [X.509] ITU-T Recommendation X.509 (1997 E): Information 220 Technology - Open Systems Interconnection - The 221 Directory: Authentication Framework, June 1997. 223 [X.511] ITU-T Recommendation X.511: Information 224 Technology - Open Systems Interconnection - The 225 Directory: Abstract Service Definition(DAP), 1993/7. 227 [X.518] ITU-T Recommendation X.511: Information 228 Technology - Open Systems Interconnection - The 229 Directory: Procedures for Distributed Operations(DSP),1993 231 [X.520] ITU-T Recommendation X.520: Information 232 Technology - Open Systems Interconnection - The 233 Directory: Selected Attribute Types, 1993. 235 [X.521] ITU-T Recommendation X.520: Information 236 Technology - Open Systems Interconnection - The 237 Directory: Selected Object Classes, 1993. 239 [X.525] ITU-T Recommendation X.511: Information 240 Technology - Open Systems Interconnection - The 241 Directory: Replication (DISP), 1993. 243 9. Author's Addresses 245 Alan Lloyd 246 OpenDirectory Pty Ltd. 247 266 Maroondah Highway 248 Mooroolbark 249 Melbourne Vic 3138 250 Australia 251 +61 3 9727 8900 252 mobile + 61 416 536 749 253 alan.lloyd@opendirectory.com.au