From list@netscape.com Sat Jul 1 16:49:31 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22228 for ; Sat, 1 Jul 2000 16:49:31 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e61Kdpg06691; Sat, 1 Jul 2000 13:39:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e61Klsk05688; Sat, 1 Jul 2000 13:47:54 -0700 (PDT) Resent-Date: Sat, 1 Jul 2000 13:47:54 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: internet-drafts@ietf.org Date: Sat, 1 Jul 2000 21:45:33 +0100 MIME-Version: 1.0 Content-type: Multipart/Mixed; boundary=Message-Boundary-11230 Subject: Revised Matched Values Draft Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <395E667D.20321.CB299BF@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"ONeBbC.A.jYB.5jlX5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --Message-Boundary-11230 Content-type: text/plain; charset=US-ASCII Content-description: Mail message body Content-Transfer-Encoding: 7BIT Could you please publish the attached Internet Draft Regards David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** --Message-Boundary-11230 Content-type: text/plain; charset=US-ASCII Content-description: Text from file 'MatchedValues-02.txt' Content-Transfer-Encoding: 7BIT Internet-Draft David Chadwick LDAPExt WG University of Salford Intended Category: Standards Track Sean Mullan Sun Microsystems Expires: 1 January 2001 1 July 2000 Returning Matched Values with LDAPv3 STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all the provisions of Section 10 of RFC2026. 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 expires on 1 January 2001. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the LDAPExt working group discussion list: ietf-ldapext@netscape.com or directly to the authors. ABSTRACT This document describes a control for the Lightweight Directory Access Protocol v3 that is used to return a subset of attribute values from an entry, specifically, only those values that match a "values return" filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. 1. Introduction When reading an attribute from an entry using LDAP v2 [1] or LDAPv3 [2], it is normally only possible to read either the attribute type, or the attribute type and all its values. It is not possible to selectively read just a few of the attribute values. If an attribute holds many values, for example, the userCertificate attribute, or the subschema publishing operational attributes objectClasses and attributeTypes [3], then it may be desirable for the user to be able to selectively retrieve a subset of the values, specifically, those attribute values that match some user defined selection criteria. Without the control specified in this [ID/standard] a client must read all of the attribute's values and filter out the unwanted values, necessitating the client to implement the matching rules. It also requires the client to potentially read and process many irrelevant values, which can be inefficient if the values are large or complex, or there are many values stored per attribute. This Internet Draft specifies an LDAPv3 control to enable a user to return only those values that matched (i.e. returned TRUE to) one or more elements of a newly defined "values return" filter. This control can be especially useful when used in conjunction with extensible matching rules that match on one or more components of complex binary attribute values. 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 RFC 2119 [5]. 2. The valuesReturnFilter Control The valuesReturnFilter control MAY be critical or non-critical as determined by the user. It is only applicable to the Search operation, and SHALL be ignored by the server if it is present on any other LDAP operation (even if marked critical on such operations). The object identifier for this control is 1.2.826.0.1.3344810.2.3 The controlValue is ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem SimpleFilterItem ::= CHOICE { equalityMatch [3] AttributeValueAssertion, substrings [4] SubstringFilter, greaterOrEqual [5] AttributeValueAssertion, lessOrEqual [6] AttributeValueAssertion, present [7] AttributeDescription, approxMatch [8] AttributeValueAssertion, extensibleMatch [9] SimpleMatchingAssertion } SimpleMatchingAssertion ::= SEQUENCE { matchingRule [1] MatchingRuleId OPTIONAL, type [2] AttributeDescription OPTIONAL, matchValue [3] AssertionValue} All the above data types have their standard meanings as defined in [2]. If the server supports this control, the server MUST make use of the control as follows: (1) The Search Filter is first executed in order to determine which entries satisfy the Search criteria. The control has no impact on this step. (2) If the typesOnly parameter of the Search Request is TRUE, the control has no effect and the Search Request SHOULD be processed as if the control had not been specified. (3) If the attributes parameter of the Search Request consists of a list containing only the attribute with OID "1.1" (specifying that no attributes are to be returned), the control has no effect and the Search Request SHOULD be processed as if the control had not been specified. (4) For each attribute listed in the attributes parameter of the Search Request, the server MUST apply the control as follows: i) Every attribute value that evaluates TRUE against one or more elements of the ValuesReturnFilter is placed in the SearchResultEntry. ii) Every attribute value that evaluates FALSE or undefined against all elements of the ValuesReturnFilter is not placed in the SearchResultEntry. An attribute that has no values selected is returned with an empty set of vals. Editor's Note. There is possibly a more efficient but slightly more complex way of achieving the value filtering. An alternative is to remove the 'present' SimpleFilterItem (which obviously evaluates true for every attribute value of the 'present' attribute description), and to say that any attribute whose type is not mentioned in the ValuesReturnFilter is not filtered and has all its attribute values returned. Comments please. 3. Relationship to X.500 The control is a superset of the matchedValuesOnly boolean of the X.500 DAP [4] Search argument, as amended in the latest version [6]. Close examination of the matchedValuesOnly boolean by the LDAPExt group revealed ambiguities and complexities in the MVO boolean that could not easily be resolved. For example, are only those attribute values that contributed to the overall truth of the filter governed by the MVO boolean, or all values of attributes in the filter governed by the MVO boolean, even if the filter item containing the attribute evaluated to false. For this reason the LDAP group decided to replace the MVO boolean with a simple filter that removes any uncertainty as to whether an attribute value has been selected or not. 4. Examples (1) The first example simply shows how the control can be used to selectively read a subset of attribute values. The entry below represents a groupOfNames object class containing several members from different organizations. cn: Cross Organizational Standards Body member: cn=joe,o=acme member: cn=alice,o=acme member: cn=bob,o=foo member: cn=sue,o=bar An LDAP search operation is specified with a baseObject set to the DN of the entry, a baseObject scope, a filter set to "member=*o=acme", and the list of attributes to be returned set to "member". In addition, a ValuesReturnFilter control is set to "member=*o=acme". The search results returned by the server would consist of the following entry: cn: Cross Organizational Standards Body member: cn=joe, o=acme member: cn=alice, o=acme (2) The second example shows how the control can be set to match on attributes that are (mail) and are not (telephoneNumber) part of the search filter. It also shows how a user can filter some attribute values (mail) and not others (telephoneNumber). The entries below represent inetOrgPerson [7] object classes located below some distinguished name in the directory. cn: Sean Mullan mail: sean.mullan@sun.com mail: mullan@east.sun.com telephoneNumber: +1 781 442 0926 telephoneNumber: 555-9999 cn: David Chadwick mail: d.w.chadwick@salford.ac.uk An LDAP search operation is specified with a baseObject set to the DN of the entry, a subtree scope, a filter set to "(|(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk))", and the list of attributes to be returned set to "mail telephoneNumber". In addition, a ValuesReturnFilter control is set to "mail=sean.mullan@sun.com, mail=d.w.chadwick@salford.ac.uk, telephoneNumber=*" The search results returned by the server would consist of the following entries: cn: Sean Mullan mail: sean.mullan@sun.com telephoneNumber: +1 781 442 0926 telephoneNumber: 555-9999 cn: David Chadwick mail: d.w.chadwick@salford.ac.uk Note that the control has no effect on the values returned for the "telephoneNumber" attribute (all of the values are returned), since the control specified that all values should be returned. (3) The third example shows how one might retrieve a single attribute type schema definition for the "gunk" attribute with OID 1.2.3.4.5 Assume the subschema subentry is held somewhere below the root entry with RDN "subschema subentry", and this holds an attributeTypes operational attribute holding the descriptions of the 35 attributes known to this server (each description is held as a single attribute value of the attributeTypes attribute). cn: subschema subentry objectClass: subschema attributeTypes: ( 2.5.4.3 NAME 'cn' SUP name ) attributeTypes: ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE ) attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) attributeTypes: ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER- MODIFICATION USAGE directoryOperation ) attributeTypes: ( 2.5.21.6 NAME 'objectClasses' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation ) attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} ) attributeTypes: ( 2.5.21.5 NAME 'attributeTypes' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation ) plus another 28 - you get the idea. The user creates an LDAP search operation with a baseObject set to root, a subtree scope, a filter set to "objectClass=subschema", the list of attributes to be returned set to "attributeTypes", and the ValuesReturnFilter set to "attributeTypes=1.2.3.4.5" The search result returned by the server would consist of the following entry: cn: subschema subentry attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} ) (4) The final example shows how the control can be set to match on attributes that are not part of the search filter. For example, searching for all entries that have an email address in the sun.com domain, and returning the telephone number for any attribute values that start with "555". The entries below represent inetOrgPerson [7] object classes located below some distinguished name in the directory. cn: Sean Mullan mail: sean.mullan@sun.com mail: mullan@east.sun.com telephoneNumber: +1 781 442 0926 telephoneNumber: 555-9999 cn: David Chadwick mail: d.w.chadwick@salford.ac.uk An LDAP search operation is specified with a baseObject set to the DN of the entry, a subtree scope, a filter set to "mail=*sun.com", and the list of attributes to be returned set to "telephoneNumber". In addition, a ValuesReturnFilter control is set to "telephoneNumber=555*" The search results returned by the server would consist of the following entry: cn: Sean Mullan telephoneNumber: 555-9999 5. Security Considerations This Internet Draft does not discuss security issues at all. Note that attribute values MUST only be returned if the access controls applied by the LDAP server allow them to be returned, and in this respect the effect of the ValuesReturnFilter control is of no consequence. Note that the ValuesReturnFilter control may have a positive effect on the deployment of public key infrastructures. Certain PKI operations, like searching for specific certificates, become more practical (when combined with X.509 certificate matching rules at the server) and more scalable, since the control avoids the downloading of potentially large numbers of irrelevant certificates which would have to be processed and filtered locally (which in some cases is very difficult to perform). 6. Acknowledgements The authors would like to thank members of the LDAPExt list for their constructive comments on earlier versions of this draft, and in particular to Harald Alvestrand who first suggested having an attribute return filter and Bruce Greenblatt who first proposed a syntax for this control. 7. Copyright Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 8. References [1] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access Protocol", RFC 1777, March 1995. [2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", Dec. 1997, RFC 2251 [3] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, Dec 1997 [4] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993. [5] S.Bradner. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [6] ISO/IEC 9594 / ITU-T Rec X.511 (2000) The Directory: Abstract Service Definition. [7] M. Smith. "Definition of the inetOrgPerson LDAP Object Class", Internet Draft , April 1999. 9. Authors Addresses David Chadwick IS Institute University of Salford Salford M5 4WT England Email: d.w.chadwick@salford.ac.uk Sean Mullan Sun Microsystems East Point Business Park Dublin 3 Ireland Tel: +353 1 853 0655 Email: sean.mullan@sun.com Internet-Draft Returning Matched Values with LDAPv3 1 July 2000 1 --Message-Boundary-11230-- From list@netscape.com Sun Jul 2 01:49:06 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01972 for ; Sun, 2 Jul 2000 01:49:06 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e625gxe28807; Sat, 1 Jul 2000 22:42:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e625lVs13657; Sat, 1 Jul 2000 22:47:31 -0700 (PDT) Resent-Date: Sat, 1 Jul 2000 22:47:31 -0700 (PDT) Message-Id: <4.3.2.7.0.20000701213030.00afe420@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 01 Jul 2000 22:47:14 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: Revised Matched Values Draft Cc: ietf-ldapext@netscape.com In-Reply-To: <395E667D.20321.CB299BF@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"iQrXtC.A.EVD.ydtX5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com [portions document trimmed] >Returning Matched Values with LDAPv3 > > >ABSTRACT > >This document describes a control for the Lightweight Directory >Access Protocol v3 that is used to return a subset of attribute >values from an entry, specifically, only those values that match a >"values return" filter. Without support for this control, a client >must retrieve all of an attribute's values and search for specific >values locally. > > >1. Introduction > >When reading an attribute from an entry using LDAP v2 [1] or LDAPv3 >[2], I suggest not mentioning LDAP v2... >it is normally only possible to read either the attribute type, >or the attribute type and all its values. It is not possible to >selectively read just a few of the attribute values. If an attribute >holds many values, for example, the userCertificate attribute, or the >subschema publishing operational attributes objectClasses and >attributeTypes [3], then it may be desirable for the user to be able >to selectively retrieve a subset of the values, specifically, those >attribute values that match some user defined selection criteria. >Without the control specified in this [ID/standard] a client must s/[ID/standard]/document/ >read all of the attribute's values and filter out the unwanted >values, necessitating the client to implement the matching rules. It >also requires the client to potentially read and process many >irrelevant values, which can be inefficient if the values are large >or complex, or there are many values stored per attribute. > >This Internet Draft specifies an LDAPv3 control to enable a user to s/Internet Draft/document/ > >return only those values that matched (i.e. returned TRUE to) one or >more elements of a newly defined "values return" filter. This control >can be especially useful when used in conjunction with extensible >matching rules that match on one or more components of complex binary >attribute values. > >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 RFC 2119 [5]. > > >2. The valuesReturnFilter Control > >The valuesReturnFilter control MAY be critical or non-critical as >determined by the user. It is only applicable to the Search >operation, and SHALL be ignored by the server if it is present on any >other LDAP operation (even if marked critical on such operations). I suggest that if this control is provided to non-search operations and marked critical that an unavailableCriticalExtension (unsupportedCriticalExtension) error should be returned. This is consistent with RFC 2251, 4.1.12. If the control is not appropriate for the operation and criticality field is TRUE, the server MUST NOT perform the operation, and MUST instead return the resultCode unsupportedCriticalExtension. >The object identifier for this control is 1.2.826.0.1.3344810.2.3 > > >The controlValue is > > ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem > > SimpleFilterItem ::= CHOICE { > equalityMatch [3] AttributeValueAssertion, > substrings [4] SubstringFilter, > greaterOrEqual [5] AttributeValueAssertion, > lessOrEqual [6] AttributeValueAssertion, > present [7] AttributeDescription, > approxMatch [8] AttributeValueAssertion, > extensibleMatch [9] SimpleMatchingAssertion } > > SimpleMatchingAssertion ::= SEQUENCE { > matchingRule [1] MatchingRuleId OPTIONAL, > type [2] AttributeDescription OPTIONAL, > matchValue [3] AssertionValue} > >All the above data types have their standard meanings as defined in >[2]. > >If the server supports this control, the server MUST make use of the >control as follows: > >(1) The Search Filter is first executed in order to determine >which entries satisfy the Search criteria. The control has no >impact on this step. > >(2) If the typesOnly parameter of the Search Request is TRUE, >the control has no effect and the Search Request SHOULD be >processed as if the control had not been specified. > >(3) If the attributes parameter of the Search Request consists >of a list containing only the attribute with OID "1.1" >(specifying that no attributes are to be returned), the control >has no effect and the Search Request SHOULD be processed as if >the control had not been specified. > >(4) For each attribute listed in the attributes parameter of the >Search Request, the server MUST apply the control as follows: > >i) Every attribute value that evaluates TRUE against one or >more elements of the ValuesReturnFilter is placed in the >SearchResultEntry. >ii) Every attribute value that evaluates FALSE or undefined >against all elements of the ValuesReturnFilter is not >placed in the SearchResultEntry. An attribute that has no >values selected is returned with an empty set of vals. > >Editor's Note. There is possibly a more efficient but slightly more >complex way of achieving the value filtering. An alternative is to >remove the 'present' SimpleFilterItem (which obviously evaluates true >for every attribute value of the 'present' attribute description), >and to say that any attribute whose type is not mentioned in the >ValuesReturnFilter is not filtered and has all its attribute values >returned. Comments please. I prefer the specified approach as it appears easier to implement especially for servers which separate filter evaluation from attribute list processing. That is, in U-Mich derived servers, filter evaluation is done by database backends and attribute list processing is done by the frontend. Implementing this control with the above design might prove to be more than slightly complex and the efficient gain may actually be quite slight. >3. Relationship to X.500 > >The control is a superset of the matchedValuesOnly boolean of the >X.500 DAP [4] Search argument, as amended in the latest version [6]. >Close examination of the matchedValuesOnly boolean by the LDAPExt >group revealed ambiguities and complexities in the MVO boolean that >could not easily be resolved. For example, are only those attribute >values that contributed to the overall truth of the filter governed >by the MVO boolean, or all values of attributes in the filter >governed by the MVO boolean, even if the filter item containing the >attribute evaluated to false. For this reason the LDAP group decided >to replace the MVO boolean with a simple filter that removes any >uncertainty as to whether an attribute value has been selected or >not. > > >4. Examples > >(1) The first example simply shows how the control can be used to >selectively read a subset of attribute values. > >The entry below represents a groupOfNames object class containing >several members from different organizations. Please specify a DN, object classes, and ensure entry is valid per Standard Track schema in all examples. You might specify that entries are provided in LDIF (RFC2849). >cn: Cross Organizational Standards Body >member: cn=joe,o=acme >member: cn=alice,o=acme >member: cn=bob,o=foo >member: cn=sue,o=bar > >An LDAP search operation is specified with a baseObject set to the >DN of the entry, a baseObject scope, a filter set to >"member=*o=acme", and the list of attributes to be returned set to >"member". In addition, a ValuesReturnFilter control is set to >"member=*o=acme". Note that filter (which is missing parentheses) is should evaluation to Undefined as member attribute type does specify a substrings matching rule. >The search results returned by the server would consist of the >following entry: > >cn: Cross Organizational Standards Body >member: cn=joe, o=acme >member: cn=alice, o=acme > > >(2) The second example shows how the control can be set to match on >attributes that are (mail) and are not (telephoneNumber) part of the >search filter. It also shows how a user can filter some attribute >values (mail) and not others (telephoneNumber). Note sure why you have parentheses around these attribute types. >The entries below represent inetOrgPerson [7] object classes located >below some distinguished name in the directory. I would suggest using organizationalPerson (w/ appropriate attributes) instead of inetOrgPerson as inetOrgPerson is Informational (though I don't be this use would cause a standard track maturity issue). >cn: Sean Mullan >mail: sean.mullan@sun.com >mail: mullan@east.sun.com >telephoneNumber: +1 781 442 0926 >telephoneNumber: 555-9999 > >cn: David Chadwick >mail: d.w.chadwick@salford.ac.uk > >An LDAP search operation is specified with a baseObject set to the >DN of the entry, a subtree scope, a filter set to >"(|(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk))", and >the list of attributes to be returned set to "mail telephoneNumber". >In addition, a ValuesReturnFilter control is set to >"mail=sean.mullan@sun.com, mail=d.w.chadwick@salford.ac.uk, >telephoneNumber=*" Please use parentheses. In fact, you may want to define a string format for ValuesReturnFilter. I suggest something like: (:(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk)(telephoneNumber=*)) or if that looks too much like a search filter: {(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk)(telephoneNumber=*)} >The search results returned by the server would consist of the >following entries: > >cn: Sean Mullan >mail: sean.mullan@sun.com >telephoneNumber: +1 781 442 0926 >telephoneNumber: 555-9999 > >cn: David Chadwick >mail: d.w.chadwick@salford.ac.uk > >Note that the control has no effect on the values returned for the >"telephoneNumber" attribute (all of the values are returned), since >the control specified that all values should be returned. > >(3) The third example shows how one might retrieve a single attribute >type schema definition for the "gunk" attribute with OID 1.2.3.4.5 > >Assume the subschema subentry is held somewhere below the root entry >with RDN "subschema subentry", and this holds an attributeTypes >operational attribute holding the descriptions of the 35 attributes >known to this server (each description is held as a single attribute >value of the attributeTypes attribute). > >cn: subschema subentry >objectClass: subschema >attributeTypes: ( 2.5.4.3 NAME 'cn' SUP name ) >attributeTypes: ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE ) >attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY >objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) >attributeTypes: ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY >generalizedTimeMatch ORDERING generalizedTimeOrderingMatch >SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER- >MODIFICATION USAGE directoryOperation ) >attributeTypes: ( 2.5.21.6 NAME 'objectClasses' EQUALITY >objectIdentifierFirstComponentMatch SYNTAX >1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation ) >attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch >SUBSTR caseIgnoreSubstringsMatch SYNTAX >1.3.6.1.4.1.1466.115.121.1.44{64} ) >attributeTypes: ( 2.5.21.5 NAME 'attributeTypes' EQUALITY >objectIdentifierFirstComponentMatch SYNTAX >1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation ) > >plus another 28 - you get the idea. > > >The user creates an LDAP search operation with a baseObject set to >root, a subtree scope, a filter set to "objectClass=subschema", the >list of attributes to be returned set to "attributeTypes", and the >ValuesReturnFilter set to "attributeTypes=1.2.3.4.5" Per RFC 2251, subschema subentries should be retrieved using a search with a base of the subschema subentry's DN, scope base, and filter (objectclass=subschema). Please use this procedure in your example. >The search result returned by the server would consist of the >following entry: > >cn: subschema subentry >attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch >SUBSTR caseIgnoreSubstringsMatch SYNTAX >1.3.6.1.4.1.1466.115.121.1.44{64} ) > >(4) The final example shows how the control can be set to match on >attributes that are not part of the search filter. For example, >searching for all entries that have an email address in the >sun.com domain, and returning the telephone number for any attribute >values that start with "555". > >The entries below represent inetOrgPerson [7] object classes located >below some distinguished name in the directory. > >cn: Sean Mullan >mail: sean.mullan@sun.com >mail: mullan@east.sun.com >telephoneNumber: +1 781 442 0926 >telephoneNumber: 555-9999 > >cn: David Chadwick >mail: d.w.chadwick@salford.ac.uk > >An LDAP search operation is specified with a baseObject set to the >DN of the entry, a subtree scope, a filter set to "mail=*sun.com", >and the list of attributes to be returned set to "telephoneNumber". >In addition, a ValuesReturnFilter control is set to >"telephoneNumber=555*" > >The search results returned by the server would consist of the >following entry: > >cn: Sean Mullan >telephoneNumber: 555-9999 > > >5. Security Considerations > >This Internet Draft does not discuss security issues at all. s/Internet Draft/document/ I suggest you strike this statement as this section discussion security issues (though mute). I suggest you revise the comments below into primary considerations. >Note that attribute values MUST only be returned if the access >controls applied by the LDAP server allow them to be returned, and in >this respect the effect of the ValuesReturnFilter control is of no >consequence. How do "search" versus "read" access to be applied. That is, where "search" access is required to evaluation search filters and "read" access is required to return return attributes, is this mechanism considered part of "searching" or part of "reading"? Though the mechanism uses filters, I'm thinking it's part of "reading" as the mechanism is only applied entries which match the search filter and scope. Would treating the mechanism as part of "reading" be consistent with X.500/LDAP/vendor access controls? >Note that the ValuesReturnFilter control may have a positive effect >on the deployment of public key infrastructures. Certain PKI >operations, like searching for specific certificates, become more >practical (when combined with X.509 certificate matching rules at the >server) and more scalable, since the control avoids the downloading >of potentially large numbers of irrelevant certificates which would >have to be processed and filtered locally (which in some cases is >very difficult to perform). > > >6. Acknowledgements > >The authors would like to thank members of the LDAPExt list for their >constructive comments on earlier versions of this draft, and in s/draft/document/ >particular to Harald Alvestrand who first suggested having an >attribute return filter and Bruce Greenblatt who first proposed a >syntax for this control. > >7. Copyright > >Copyright (C) The Internet Society (date). All Rights Reserved. Date should be specified. >8. References > >[7] M. Smith. "Definition of the inetOrgPerson LDAP Object Class", >Internet Draft , April 1999. Published as RFC 2798. From list@netscape.com Sun Jul 2 02:06:54 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08819 for ; Sun, 2 Jul 2000 02:06:53 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6260ve29668; Sat, 1 Jul 2000 23:00:57 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6265UE17441; Sat, 1 Jul 2000 23:05:30 -0700 (PDT) Resent-Date: Sat, 1 Jul 2000 23:05:30 -0700 (PDT) Message-Id: <4.3.2.7.0.20000701225708.00ae3a60@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 01 Jul 2000 23:05:21 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: Revised Matched Values Draft Cc: ietf-ldapext@netscape.com In-Reply-To: <395E667D.20321.CB299BF@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"aTeQDB.A.KQE.outX5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Another comment: >If the server supports this control, the server MUST make use of the >control as follows: > >(1) The Search Filter is first executed in order to determine >which entries satisfy the Search criteria. The control has no >impact on this step. > >(2) If the typesOnly parameter of the Search Request is TRUE, >the control has no effect and the Search Request SHOULD be >processed as if the control had not been specified. > >(3) If the attributes parameter of the Search Request consists >of a list containing only the attribute with OID "1.1" >(specifying that no attributes are to be returned), the control >has no effect and the Search Request SHOULD be processed as if >the control had not been specified. This step seems unnecessary. >(4) For each attribute listed in the attributes parameter of the >Search Request, the server MUST apply the control as follows: > >i) Every attribute value that evaluates TRUE against one or >more elements of the ValuesReturnFilter is placed in the >SearchResultEntry. >ii) Every attribute value that evaluates FALSE or undefined >against all elements of the ValuesReturnFilter is not >placed in the SearchResultEntry. An attribute that has no >values selected is returned with an empty set of vals. How is the control applied if no attribute list is provided or "*" is in the list. I would assume, in both cases, that all user attributes contain in entry would be evaluated (per step 4) as if they were explicitly listed. From list@netscape.com Sun Jul 2 19:44:52 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11219 for ; Sun, 2 Jul 2000 19:44:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e62Ncoe04925; Sun, 2 Jul 2000 16:38:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e62NhOE26840; Sun, 2 Jul 2000 16:43:24 -0700 (PDT) Resent-Date: Sun, 2 Jul 2000 16:43:24 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" , Subject: RE: OID of caseExactIA5SubstringsMatch Date: Mon, 3 Jul 2000 09:45:58 +1000 Message-ID: <000201bfe47f$ac715030$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: <4.3.2.7.0.20000630175934.00af47c0@infidel.boolean.net> Resent-Message-ID: <"KMRNPD.A.DjG.bO9X5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Kurt, I'm not aware of a standard definition for caseExactIA5SubstringsMatch and we don't use a private definition. I believe the latest edition of X.500 (I haven't got a copy handy to double check) extends/corrects the definition of caseExactMatch, etc, to apply to string types other than DirectoryString (including IA5String) so we treat caseExactIA5Match as an alternative name/OID for caseExactMatch and use caseExactSubstringsMatch for substring matching of IA5Strings. Similar applies for caseIgnoreMatch. Regards, Steven > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Saturday, 1 July 2000 11:09 > To: ietf-ldapext@netscape.com > Subject: OID of caseExactIA5SubstringsMatch > > > What OID are others using for this rule? > Does there exist a formal specification for this rule? > > Thanks, Kurt > > > From list@netscape.com Sun Jul 2 21:18:47 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11760 for ; Sun, 2 Jul 2000 21:18:46 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e631Cle08392; Sun, 2 Jul 2000 18:12:47 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e631HKk13629; Sun, 2 Jul 2000 18:17:20 -0700 (PDT) Resent-Date: Sun, 2 Jul 2000 18:17:20 -0700 (PDT) Reply-To: From: "Steven Legg" To: , Subject: String Encodings - was RE: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3" Date: Mon, 3 Jul 2000 11:19:47 +1000 Message-ID: <000401bfe48c$c764ce50$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: <395B9787.30084.1B9DC3C@localhost> Resent-Message-ID: <"mjLDXD.A.oUD.em-X5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit David, > -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] > Sent: Friday, 30 June 2000 3:38 > To: Jeff.Hodges@stanford.edu; ietf-ldapext@netscape.com > Cc: RLBob Morgan > Subject: Re: Applicability Stmt (AS) rescinding "IESG Note" > and defining > "LDAPv3" [snip] > RFC2587 does not describe in detail the matching rules that > should be supported by LDAP servers, nor does it describe > how attribute value assertions for each matching rule > should be encoded in filter items (in fact these AVA > encodings are not currently described anywhere). It's a shame the LDAP string encodings for attribute values weren't defined by some algorithmic relationship to the ASN.1 type of the syntax, much like the way ASN.1 value notation is related to the type. It wouldn't then be necessary to define a string encoding for each new attribute value syntax or assertion value syntax imported from X.500, X.509, etc. The required string encoding would fall out naturally from the relevant ASN.1 type. It's never too late to start though. Regards, Steven From list@netscape.com Mon Jul 3 02:53:56 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27430 for ; Mon, 3 Jul 2000 02:53:55 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e636i7g17889; Sun, 2 Jul 2000 23:44:11 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e636qDo08554; Sun, 2 Jul 2000 23:52:13 -0700 (PDT) Resent-Date: Sun, 2 Jul 2000 23:52:13 -0700 (PDT) X-Envelope-Sender-Is: helmut.volpers@icn.siemens.de (at relayer david.siemens.de) Message-ID: From: "Volpers, Helmut" To: "'Kurt D. Zeilenga'" , ietf-ldapext@netscape.com Subject: RE: OID of caseExactIA5SubstringsMatch Date: Mon, 3 Jul 2000 08:52:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"aea92B.A.TFC.bgDY5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hi Kurt, I haven't seen a standard OID yet. We for example use a private (Siemens) OID for additional matching rules. (1.3.12.2.1107.1.3.13.102) Helmut > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Samstag, 1. Juli 2000 03:09 > To: ietf-ldapext@netscape.com > Subject: OID of caseExactIA5SubstringsMatch > > > What OID are others using for this rule? > Does there exist a formal specification for this rule? > > Thanks, Kurt > > From list@netscape.com Mon Jul 3 12:27:12 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04400 for ; Mon, 3 Jul 2000 12:27:11 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e63GHbg17737; Mon, 3 Jul 2000 09:17:37 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e63GPhg10925; Mon, 3 Jul 2000 09:25:43 -0700 (PDT) Resent-Date: Mon, 3 Jul 2000 09:25:43 -0700 (PDT) Message-Id: <4.3.2.7.0.20000703085803.00af9a60@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Jul 2000 09:25:32 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: LDAP subentry alignment with X.500 subentry Cc: Ed_Reed@Novell.com, ietf-ldup@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"EvFoE.A.CqC.G6LY5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I believe 'LDAPsubentry' should be replaced with with 'subentry' and defined such that it closely modelled after X.500. 1) subentries should have a subtree specifier such that they are more useful for specification of ACI subentries. 2) subentries should be visible based upon presence of a subentries control, not a filter components. For example: (|(&(objectclass=LDAPsubentry)(!(cn=*))(objectclass=*)) Should the subentry be visible or not? There are reasonable arguments for both yes and no. I primarily make these suggestions because I believe these changes would make subentries within LDAP more usable, in particular, when used in support of the access control model. Kurt From list@netscape.com Mon Jul 3 16:42:00 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07557 for ; Mon, 3 Jul 2000 16:41:59 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e63KWLg29416; Mon, 3 Jul 2000 13:32:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e63KeRk15246; Mon, 3 Jul 2000 13:40:28 -0700 (PDT) Resent-Date: Mon, 3 Jul 2000 13:40:28 -0700 (PDT) Message-Id: <4.3.2.7.0.20000703093028.00b0fce0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Jul 2000 09:36:47 -0700 To: "Volpers, Helmut" From: "Kurt D. Zeilenga" Subject: RE: OID of caseExactIA5SubstringsMatch Cc: ietf-ldapext@netscape.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"0cfY3B.A.vtD.6oPY5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 08:52 AM 7/3/00 +0200, Volpers, Helmut wrote: >I haven't seen a standard OID yet. We for example use >a private (Siemens) OID for additional matching rules. >(1.3.12.2.1107.1.3.13.102) Do you maintain a publicly accessible registry/listing of OIDs under your private enterprise arc which I could reference? I see no reason for me to assign OIDs (from our private enterprise arch) to this (and other 'missing') matching rule(s) if there are already ones assigned. Kurt From list@netscape.com Tue Jul 4 23:26:19 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04413 for ; Tue, 4 Jul 2000 23:26:19 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e653Dkg16893; Tue, 4 Jul 2000 20:13:47 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e653LuE08420; Tue, 4 Jul 2000 20:21:56 -0700 (PDT) Resent-Date: Tue, 4 Jul 2000 20:21:56 -0700 (PDT) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: Date: Tue, 4 Jul 2000 15:39:13 -0700 To: "Jeffrey I. Schiller" , Ned Freed , Chris Newman , Steve Kille , Mark Wahl , magnus@dynas.se From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: draft-ietf-ldapext-x509-sasl removed from IESG queue Cc: ietf-ldapext@netscape.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Resent-Message-ID: <"SWUKF.A.MDC.SnqY5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Because of lack of consensus around this document, I will now remove this document from the table of the IESG, and wait for a new request to publish a document about SASL mechanisms using X.509. The person which asks for that to any AD (regardless of Area) should provide documentation that all involved parties are happy (in the case of _this_ document the LDAP, SASL and X.509 people). Patrik From list@netscape.com Wed Jul 5 14:46:42 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14029 for ; Wed, 5 Jul 2000 14:46:41 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e65IdYe09442; Wed, 5 Jul 2000 11:39:34 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e65IiAE01400; Wed, 5 Jul 2000 11:44:10 -0700 (PDT) Resent-Date: Wed, 5 Jul 2000 11:44:10 -0700 (PDT) Date: Wed, 5 Jul 2000 11:43:52 -0700 (PDT) Message-Id: <200007051843.e65Ihpx14845@ywing.netscape.com> From: venwa@yahoo.com To: ietf-ldapext@netscape.com Subject: Make Money Now X-Reply-To: venwa@themail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"833t-D.A._U.2H4Y5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Make Money Now EARN $$$$$$ PER YEAR SENDING E-MAIL!!!! BECOME AN E-MAIL PROCESSOR !!!!!!!!! ********************************************* TO BE REMOVED FROM FURTHER FOLLOWUPS PLEASE FOLLOW THE INSTRUCTIONS BELOW.... ********************************************* Dear friend, You can earn $50,000 or more in the next 90 days sending e-mail, seem impossible? IF YOU NEED MONEY RIGHT NOW Read on for details (no, there is no 'catch')... A fantastic way to QUICKLY generate"seed" money for other projects and businesses you may be involved in! Don't let it's simplicity fool you! Good luck with the program. "AS SEEN ON NATIONAL T.V." Thank you for your time and Interest. This is the letter you've been reading about in the news lately. Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see, if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are, absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show has been truly remarkable. So many people are participating that those involved are doing, much better than ever before. Since everyone makes more as more people try it out, its been very exciting to be a part of lately. You will understand once you experience it. "HERE IT IS BELOW" *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a look at. It can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! I acknowledge this message is quite lengthy - don't let this deter you from reading about this great opportunity - if you will only take the time to read this you will learn in detail how to make money with very little time and investment and also read about people who have been successful in following the outlined steps. Good luck THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not require you to come into contact with people, do any hard work, and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you've been waiting for, THIS IS IT! Simply follow the instructions, and your dreams will come true. This MULTI-level e-mail order marketing program works perfectly...100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through MULTI-level methods by the mid to late 1990's. This is a MULTI- Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45 people become millionaires everyday through MULTI-Level Marketing. You may have heard this story before, but over the summer Donald Trump made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response "That's why I'm sitting up here and you are all sitting out there. With network marketing you have two sources of income. Direct commissions from sales you make yourself and commissions from sales made by people you introduce to the business. Residual income is the secret of the wealthy. It means investing time or money once and getting paid again and again and again. In network marketing, it also means getting paid for the work of others. A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich", inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have already made over 4 MILLION DOLLARS! I have retired from the program after sending out over 16,000 programs. Now I have several offices that make this and several other programs here and over seas. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000...and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent, IT IS UP TO YOU NOW! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLARS INSTRUCTIONS: This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all MULTI-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new MULTI-level business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST MULTI-Level Mail Order Marketing anywhere: This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if you don't order them). * For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! * When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, take this advertisement and remove the name and address under REPORT #4. This person has made it through the cycle and is no doubt counting their $50,000! c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you copy every name and address ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an Internet connection and e- mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. Using a good list the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! By the way, your cost to participate in this is practically nothing. You obviously already have an Internet connection and e-mail is FREE!!! METHOD #2 - PLACING FREE ADS ON THE INTERNET 1. Advertising on the 'Net is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below. 1st level--your 10 members with $5.....................................$50 2nd level--10 members from those 10 ($5 x 100)...............$500 3rd level--10 members from those 100 ($5 x 1,000)........$5,000 4th level--10 members from those 1,000 ($5 x 10,000).$50,000 THIS TOTALS $55,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants! THINK ABOUT IT! For every $5.00 you receive, all you must do is e- mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out, with YOUR name and address on it, will be prompt because they can't advertise until they receive the report! AVAILABLE REPORTS *** Order Each REPORT by NUMBER *** Notes: - ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT CHECKS NOT ACCEPTED - ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL - Make sure the cash is concealed by wrapping it in at least two sheets of paper On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: *****REMEMBER YOU MUST MAIL $5.00 FOR EACH REPORT***** --------------------------------------------- ORDER REPORT #1 (50,000+ Biz-opp e-mail addresses) FROM: (put this name in report 2, and your name here) Venita Webb 1719 S. Westwood Mesa, AZ 85210 _______________________________________________ ORDER REPORT #2 (Mail box money machine) FROM: (put this name in report 3) Chad Blick 39 Linmor Dr Irwin, pa. 15642 _______________________________________________ ORDER REPORT #3 (make your fortune in mail order) FROM: (put this name in report 4) Scott Carrabis 3800 Max Place Apt 101 Boynton beach Fla. 33436 _______________________________________________ ORDER REPORT #4 (Bulk E-mail services) FROM: (REMOVE THIS NAME) Mary bestvina 1730 s. federal hwy #104 Delay beach, Fla. 33483 _______________________________________________ About 50,000 new people get online every month! ******* TIPS FOR SUCCESS ******* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately * Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT #2. If you don't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO PRODUCE! 2. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO SHIP! 3. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST YOU ANYTHING TO ADVERTISE! 4. YOU ARE UTILIZING THE POWER OF THE INTERNET AND THE POWER OF MULTI-LEVEL MARKETING TO DISTRIBUTE YOUR PRODUCT ALL OVER THE WORLD! 5.. YOUR ONLY EXPENSES OTHER THAN YOUR INITIAL $20 INVESTMENT IS YOUR TIME! 6. VIRTUALLY ALL OF THE INCOME YOU GENERATE FROM THIS PROGRAM IS PURE PROFIT! 7. THIS PROGRAM WILL CHANGE YOUR LIFE FOREVER. ****** T E S T I M O N I A L S ******* The main reason for this letter is to convince you that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $36,470.00 in the first 14 weeks, with money still coming in. Sincerely yours Charles Morris, Esq. Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my medium-size post office box crammed with orders! For awhile, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this deal is that it doesn't matter where people live. There simply isn't a better investment with a faster return. Paige Willis, Des Moines, IOWA I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program, ....11 months passed then it came...I didn't delete this one!...I made more than $41,000 on the first try!! Violet Wilson, Johnstown, PA This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for you is if you do it. For your sake, and for your family's sake don't pass up this golden opportunity. Good luck and happy spending! Kerry Ford, Centerport, NY The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. My name is Johnathon Rourke. Two years ago, the corporation I worked at for the past twelve years down- sized and my position was eliminated. After unproductive job interviews, I decided to open m own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program.I didn't send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 10,000 e-mails. It cost me about $15 for my time on- line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, the only expense is my time. I am telling you like it is, I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it cost me. In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!! Remember, it won't work if you don't try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work, you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are if financial trouble like I was, or you want to start your own business, consider this a sign. I DID! Sincerely, Johnathon Rourke ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! NOW IS THE TIME FOR YOUR TURN DECISIVE ACTION YIELDS POWERFUL RESULTS PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc.., contact your local office of the Small Business Administration (a Federal agency) 1-(800)827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings and results are highly dependent on your activities and advertising. This letter constitutes no guarantees stated nor implied. In the event that it is determined that this letter constitutes a guarantee of any kind, that guarantee is now void. Any testimonials or amounts of earnings listed in this letter may be factual or fictitious. If you have any question of the legality of this letter contact the Office of Associate Director for Marketing Practices Federal Trade Commission Bureau of Consumer Protection in Washington DC. From list@netscape.com Wed Jul 5 14:46:46 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14041 for ; Wed, 5 Jul 2000 14:46:45 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e65Ieee10029; Wed, 5 Jul 2000 11:40:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e65IjHA02619; Wed, 5 Jul 2000 11:45:17 -0700 (PDT) Resent-Date: Wed, 5 Jul 2000 11:45:17 -0700 (PDT) Message-Id: <4.3.2.7.0.20000705110122.00ae4100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Jul 2000 11:02:22 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: String Encodings - was RE: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3" Cc: , In-Reply-To: <000401bfe48c$c764ce50$b05508cb@osmium.adacel.com.au> References: <395B9787.30084.1B9DC3C@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"pHlnT.A.ko.8I4Y5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:19 AM 7/3/00 +1000, Steven Legg wrote: >It's a shame the LDAP string encodings for attribute values weren't defined >by some algorithmic relationship to the ASN.1 type of the syntax, much >like the way ASN.1 value notation is related to the type. It wouldn't >then be necessary to define a string encoding for each new attribute >value syntax or assertion value syntax imported from X.500, X.509, etc. >The required string encoding would fall out naturally from the relevant >ASN.1 type. > >It's never too late to start though. You could request ;binary transfer for all attributes... :-) From list@netscape.com Wed Jul 5 15:45:46 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15503 for ; Wed, 5 Jul 2000 15:45:45 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e65JdZe19953; Wed, 5 Jul 2000 12:39:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e65Jdjw28191; Wed, 5 Jul 2000 12:39:45 -0700 (PDT) Resent-Date: Wed, 5 Jul 2000 12:39:45 -0700 (PDT) Message-Id: <4.3.1.0.20000705124102.00ad2360@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 05 Jul 2000 12:42:04 -0700 To: "Kurt D. Zeilenga" , From: Bruce Greenblatt Subject: Re: String Encodings - was RE: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3" Cc: , In-Reply-To: <4.3.2.7.0.20000705110122.00ae4100@infidel.boolean.net> References: <000401bfe48c$c764ce50$b05508cb@osmium.adacel.com.au> <395B9787.30084.1B9DC3C@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"48wlwD.A.O4G._74Y5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:02 AM 07/05/2000 -0700, Kurt D. Zeilenga wrote: >At 11:19 AM 7/3/00 +1000, Steven Legg wrote: > >It's a shame the LDAP string encodings for attribute values weren't defined > >by some algorithmic relationship to the ASN.1 type of the syntax, much > >like the way ASN.1 value notation is related to the type. It wouldn't > >then be necessary to define a string encoding for each new attribute > >value syntax or assertion value syntax imported from X.500, X.509, etc. > >The required string encoding would fall out naturally from the relevant > >ASN.1 type. > > > >It's never too late to start though. > >You could request ;binary transfer for all attributes... :-) Or one could stop defining these new attribute syntaxes, and make do with strings... Bruce From list@netscape.com Thu Jul 6 09:32:37 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16079 for ; Thu, 6 Jul 2000 09:32:36 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e66DQ9e20848; Thu, 6 Jul 2000 06:26:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e66DUlE19528; Thu, 6 Jul 2000 06:30:47 -0700 (PDT) Resent-Date: Thu, 6 Jul 2000 06:30:47 -0700 (PDT) Message-ID: <047b01bfe7c8$ae69ada0$3029b0cb@w3l8s9> To: From: "Your Way To Global Success" Subject: MAKE CASH DAILY Date: Thu, 6 Jul 2000 21:01:20 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0478_01BFE78E.020AD5A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Resent-Message-ID: <"3zcf7D.A.kwE.FoIZ5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multi-part message in MIME format. ------=_NextPart_000_0478_01BFE78E.020AD5A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MAKE YOUR COMPUTER YOUR PERSONAL ATM MACHINE! =20 You only need a few minutes to do this. Start Now!=20 NOW, you can make $50 an hour through your computer. Newbies, = Professionals, anybody who has the desire can do this. It's so simple. = You can even start earning right now. YES RIGHT NOW! It will only take = you 40 minutes to set-up. START NOW! Just simply reply to this e-mail with Send More Info as the text and = we'll show you how simple it is. Thank you very much. BONG =20 * * * * * * * * * * * * * * * * * * * * * * * * = * * * * =20 If you wish to be remove from our list, just reply to this e-mail with = Remove as the text and we will removed you immediately. We honor remove = requests religiously. ------=_NextPart_000_0478_01BFE78E.020AD5A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
MAKE YOUR COMPUTER YOUR PERSONAL ATM=20 MACHINE!
 
You only need a few minutes to do this. = Start Now!=20
 
NOW, you can make $50 an hour through your=20 computer. Newbies, Professionals, anybody = who has=20 the desire can do this. It's so simple. You can even start earning = right now. YES RIGHT NOW! It will only take you 40 minutes = to set-up.=20 START NOW!
 
Just simply reply to this e-mail with = Send More=20 Info as the text and we'll show you how simple it = is.
 
Thank you very much.
 
BONG
 
*  *  *  *  = * =20 *  *  *  *  *  *  *  *  *  = * =20 *  *  *  *  *  *  *  *  *  = * =20 *  *  * 
If you wish to be remove from our list, = just reply=20 to this e-mail with Remove as the text and we = will=20 removed you immediately. We honor remove requests=20 religiously.
------=_NextPart_000_0478_01BFE78E.020AD5A0-- From list@netscape.com Thu Jul 6 11:12:12 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18166 for ; Thu, 6 Jul 2000 11:12:12 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e66F66e29558; Thu, 6 Jul 2000 08:06:06 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e66FAhM20177; Thu, 6 Jul 2000 08:10:43 -0700 (PDT) Resent-Date: Thu, 6 Jul 2000 08:10:43 -0700 (PDT) Message-Id: <4.3.2.7.0.20000706074219.00b0da30@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Jul 2000 07:42:58 -0700 To: Bruce Greenblatt From: "Kurt D. Zeilenga" Subject: Re: String Encodings - was RE: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3" Cc: , , In-Reply-To: <4.3.1.0.20000705124102.00ad2360@pop.walltech.com> References: <4.3.2.7.0.20000705110122.00ae4100@infidel.boolean.net> <000401bfe48c$c764ce50$b05508cb@osmium.adacel.com.au> <395B9787.30084.1B9DC3C@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"HGZTbB.A.86E.yFKZ5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 12:42 PM 7/5/00 -0700, Bruce Greenblatt wrote: >At 11:02 AM 07/05/2000 -0700, Kurt D. Zeilenga wrote: >>At 11:19 AM 7/3/00 +1000, Steven Legg wrote: >>>It's a shame the LDAP string encodings for attribute values weren't defined >>>by some algorithmic relationship to the ASN.1 type of the syntax, much >>>like the way ASN.1 value notation is related to the type. It wouldn't >>>then be necessary to define a string encoding for each new attribute >>>value syntax or assertion value syntax imported from X.500, X.509, etc. >>>The required string encoding would fall out naturally from the relevant >>>ASN.1 type. >>> >>>It's never too late to start though. >> >>You could request ;binary transfer for all attributes... :-) > >Or one could stop defining these new attribute syntaxes, and make do with strings... And treat attributes as blobs, sure, why not? From list@netscape.com Thu Jul 6 11:38:15 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18867 for ; Thu, 6 Jul 2000 11:38:14 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e66FWBe02857; Thu, 6 Jul 2000 08:32:11 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e66Famo29449; Thu, 6 Jul 2000 08:36:48 -0700 (PDT) Resent-Date: Thu, 6 Jul 2000 08:36:48 -0700 (PDT) Message-Id: <3.0.5.32.20000706083011.00926a70@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 06 Jul 2000 08:30:11 -0700 To: "Kurt D. Zeilenga" From: Bruce Greenblatt Subject: Re: String Encodings - was RE: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3" Cc: , , In-Reply-To: <4.3.2.7.0.20000706074219.00b0da30@infidel.boolean.net> References: <4.3.1.0.20000705124102.00ad2360@pop.walltech.com> <4.3.2.7.0.20000705110122.00ae4100@infidel.boolean.net> <000401bfe48c$c764ce50$b05508cb@osmium.adacel.com.au> <395B9787.30084.1B9DC3C@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"CUAZlC.A.RLH.PeKZ5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 07:42 AM 7/6/2000 -0700, Kurt D. Zeilenga wrote: >At 12:42 PM 7/5/00 -0700, Bruce Greenblatt wrote: >>At 11:02 AM 07/05/2000 -0700, Kurt D. Zeilenga wrote: >>>At 11:19 AM 7/3/00 +1000, Steven Legg wrote: >>>>It's a shame the LDAP string encodings for attribute values weren't defined >>>>by some algorithmic relationship to the ASN.1 type of the syntax, much >>>>like the way ASN.1 value notation is related to the type. It wouldn't >>>>then be necessary to define a string encoding for each new attribute >>>>value syntax or assertion value syntax imported from X.500, X.509, etc. >>>>The required string encoding would fall out naturally from the relevant >>>>ASN.1 type. >>>> >>>>It's never too late to start though. >>> >>>You could request ;binary transfer for all attributes... :-) >> >>Or one could stop defining these new attribute syntaxes, and make do with strings... > >And treat attributes as blobs, sure, why not? > Kurt, That's not what I meant at all. Sorry for the confusion. Instead of defining a new syntax, make use of the existing syntaxes. Here's a simple example for the telephone number attribute. I could define a new syntax like: TelephoneNumber ::= SEQUENCE { countryCode [0] DirectoryString, areaCode [1] DirectoryString, localNumber [2] DirectoryString } for use in attribute types that need telephone numbers, or I could just directly use the DirectoryString syntax for these, and indicate that they obey the following BNF: telephoneNumber = countryCode whsp "$" whsp areaCode whsp "$" whsp localNumber ... IMHO, this is a better approach. I see no benefit in defining that exact structure of the data at the Presentation Layer. As far as I've seen, even when new syntaxes are defined, additional code must be written to interpret and validate the attribute value anyway. So, to me, it isn't clear exactly what purpose they serve. So, use the existing ASN.1 syntaxes, and define the BNF as is done in clause 6 of RFC 2256... This has the added benefit of making the protocol easier to visually interpret by those of us that have to look directly at it... Bruce > ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com Sign up for our LDAP Technical Overview Seminar at: http://www.acteva.com/go/dtasi From list@netscape.com Thu Jul 6 14:26:53 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22685 for ; Thu, 6 Jul 2000 14:26:53 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e66IJSe29127; Thu, 6 Jul 2000 11:19:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e66IO6U23771; Thu, 6 Jul 2000 11:24:06 -0700 (PDT) Resent-Date: Thu, 6 Jul 2000 11:24:06 -0700 (PDT) Message-Id: <200007061823.e66INj728029@xwing.netscape.com> From: Subject: Targeted Lists at the lowest prices! Date: Thu, 6 Jul 2000 09:47:15 Resent-Message-ID: <"y_w3dD.A.hyF.D7MZ5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com *******New List 7-5-00!!********* The key to success in marketing online is reaching the people who are really interested in your ad! You need targeted e-mails of business opportunity seekers who are ACTIVELY marketing online and trying to expand their business TODAY! These are going to be the lowest prices for deliverable, fresh, opportunity seekers you are going to find anywhere! We strive to clean our lists on a DAILY basis! http://www.homepagez.com/update612 10,000 opportunity seekers e-mails for only $15 **New List 7-5-00** 25,000 opportunity seekers e-mails for only $20 50,000 opportunity seekers e-mails for only $35 100,000 opportunity seekers e-mails for only $50 160,000 opportunity seekers e-mails for only $70 - Promotions! **FREE with EVERY order, demo of ListMan e-mail manager software to manage your e-mails list and Credit Helper E-book with Links to Guaranteed Visa's and MC's! **Order 50,000 or more e-mails and receive Express Mail Server to send your e-mails FREE! -Send your e-mails safely bypassing your ISP's mail server! -This is not a demo but a permanent license for the software! **Order 100,000 or more e-mails and receive, CheckMAN software to accept checks online, by phone, or fax, and InfoDisk with 1000+ Money Making Reports. An $80 value yours FREE! _______________________________________________________________ I received your e-mail as someone interested in Internet Business Opportunities. If I received your e-mail in error, or you are no longer interested, please reply with "remove" in the subject. _________________________________________________________________ From list@netscape.com Thu Jul 6 19:00:58 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27089 for ; Thu, 6 Jul 2000 19:00:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e66Mp0g13615; Thu, 6 Jul 2000 15:51:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e66MxDg20756; Thu, 6 Jul 2000 15:59:13 -0700 (PDT) Resent-Date: Thu, 6 Jul 2000 15:59:13 -0700 (PDT) From: greatbiz40@usa.net Message-Id: <200007062038.NAA14609@biotech.korea.ac.kr> To: Homebiz00589@aol.com Date: Thu, 06 Jul 00 17:52:05 EST Subject: Make Money While You Sleep! Resent-Message-ID: <"xgyddC.A._DF.A9QZ5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hi, I thought I'd drop this one time quick note to let you know about an EXCELLENT e-Commerce Business which has enjoyed rapid and consistent growth in the last 3 years. It may fit very well into your business portfolio. This is the EASIEST and the BEST online business today, virtually a SELF-RUN ONLINE BUSINESS. It's TWICE voted as the #1 online business. *Christian, of Marion, OH. writes: "I'm having 10 times the success with this business as I did with my other MLMs that I tried. I have a personal closure rate of about 80%. And I attribute that totally to the system that you have created. It truly is the best company out there. Since joining in August of this year, I have been approached by 3 distributors of other companies, including 1 co-founder, but after explaining what I do in my business and how I work the opportunity, I guess they've given up knowing that their program is much harder to achieve success in." If your current program demands that you sell products and sponsor others you will fail 90% of the time! Put yourself in the power position; win 90% of the time offering a program that everyone wants to be involved with! Simply click below to visit the award-winning website: http://12.21.33.26/babs40 It will ONLY take a minute to find out. You will be glad that you did! I received your e-mail as someone interested in Internet Business Opportunities. If I received your e-mail in error, or you are no longer interested, click here to be removed Be sure REMOVE is in the Subject Title and you will not be contacted again: mailto:goodjob40@n2mail.com?subject=Remove Thank you! From list@netscape.com Fri Jul 7 02:25:30 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15806 for ; Fri, 7 Jul 2000 02:25:30 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e676IYe13467; Thu, 6 Jul 2000 23:18:34 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e676NCA10136; Thu, 6 Jul 2000 23:23:12 -0700 (PDT) Resent-Date: Thu, 6 Jul 2000 23:23:12 -0700 (PDT) Message-Id: <200007070623.XAA17170@breakaway.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: Re: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3" To: IETF ldapext WG In-reply-to: Your message of Thu, 29 Jun 2000 16:06:31 -0700 Reply-to: IETF ldapext WG From: Jeff.Hodges@stanford.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Jul 2000 23:23:09 -0700 Sender: hodges@breakaway.Stanford.EDU Resent-Message-ID: <"0JNSGB.A.DeC.PdXZ5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 12:31 PM 6/29/00 -0700 on Thu, 29 Jun 2000, Kurt Zeilenga wrote: > >I feel: > > a) an applicability statement is needed > > b) RFC2251-56,2829-30 need revision (some more than others) > > > >These, in my opinion, are separate issues. I certainly agree. Kurt then said on Thu, 29 Jun 2000 16:06:31: > On second thought, I guess I would have to object to > the progression of the AS if it included any changes > to the technical specification. > > If one were to rescind the IESG notice, I would think > it appropriate to strength the Security Considerations > of the specifications. Something like: > Update functionality SHOULD be restricted to securely > authenticated clients. > > As such, I cannot support progressing the AS in its > current form as it would either result in inadequate > specification of Security Considerations or would > modify the technical specification. RFC2829's explicit purpose is to provide exactly the enhancement to LDAPv3-as-a-whole's "Security Considerations" that you're calling for. From 2829's introduction.. It [LDAPv3] offers means of searching, fetching and manipulating directory content, and ways to access a rich set of security functions. In order to function for the best of the Internet, it is vital that these security functions be interoperable; therefore there has to be a minimum subset of security functions that is common to all implementations that claim LDAPv3 conformance. 2829 goes on to specify, in detail, conformance requirements for security for LDAPv3 clients and servers. Note that 2829 is not Informational -- it is a standards-track doc and is at Proposed Std maturity level right along with 2251..2256 & 2830. All that the proposed LDAPv3 Applicability Statement (draft-hodges-ldapv3-as-00.txt) is saying is.. "the specific requirements of the IESG Note on 2251..2256 are now met, thus the Note is rescinded, plus these docs -- 2251..2256, 2829, 2830 -- comprise LDAPv3". It seems to us that the present-day artifact that is LDAPv3 is still somewhat fuzzily defined in the absence of an AS saying these simple, specific things. We've gone through a lot of work over the past several years to get 2829 & 2830 to their present state -- much of the purpose behind that work was to be able to take the step of crisply delineating, sans IESG reservations, LDAPv3 as-presently-constituted. This does not mean that there is not lots of work remaining. And it does not mean at all that LDAPv3 as-specified by "2251..2256, 2829, 2830, + the AS" should progress to Draft or beyond without further work. What it does mean is that we'll be providing an unambiguous definition, including security considerations, of what we mean ~today~ when we -- or any of the many implementors & vendors out there -- say "LDAPv3". JeffH From list@netscape.com Fri Jul 7 07:22:27 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20913 for ; Fri, 7 Jul 2000 07:22:26 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e67BG5e02232; Fri, 7 Jul 2000 04:16:06 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e67BKi614023; Fri, 7 Jul 2000 04:20:44 -0700 (PDT) Resent-Date: Fri, 7 Jul 2000 04:20:44 -0700 (PDT) Message-Id: <200007071120.HAA20847@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-matchedval-01.txt Date: Fri, 07 Jul 2000 07:20:39 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"6UVTnD.A.taD.K0bZ5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : Returning Matched Values with LDAPv3 Author(s) : D. Chadwick, S. Mullan Filename : draft-ietf-ldapext-matchedval-01.txt Pages : Date : 06-Jul-00 This document describes a control for the Lightweight Directory Access Protocol v3 that is used to return a subset of attribute values from an entry, specifically, only those values that match a 'values return' filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-matchedval-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapext-matchedval-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapext-matchedval-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000706152223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-matchedval-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-matchedval-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000706152223.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Fri Jul 7 11:11:49 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29111 for ; Fri, 7 Jul 2000 11:11:49 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e67F4Ne17421; Fri, 7 Jul 2000 08:04:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e67F92k09363; Fri, 7 Jul 2000 08:09:02 -0700 (PDT) Resent-Date: Fri, 7 Jul 2000 08:09:02 -0700 (PDT) Message-ID: <3965F2EC.EFE5B84C@netscape.com> Date: Fri, 07 Jul 2000 08:10:36 -0700 From: mcs@netscape.com (Mark C Smith) X-Mailer: Mozilla 4.73 [en]C-AOLNSCP (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com, ietf-ldup@imc.org, Ed Reed Subject: Re: LDAP subentry alignment with X.500 subentry References: <4.3.2.7.0.20000703085803.00af9a60@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"GSxxu.A.-RC.MKfZ5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > I believe 'LDAPsubentry' should be replaced with with 'subentry' and > defined such that it closely modelled after X.500. > > 1) subentries should have a subtree specifier such that they are more > useful for specification of ACI subentries. The X.500 subtree specifier is rich and therefore fairly complex to implement. That doesn't mean we shouldn't adopt it, but it does mean we should consider the impact. > 2) subentries should be visible based upon presence of a subentries control, > not a filter components. For example: > (|(&(objectclass=LDAPsubentry)(!(cn=*))(objectclass=*)) > > Should the subentry be visible or not? There are reasonable arguments > for both yes and no. But controls are of course more costly for clients and servers to implement. What problem are you trying to solve? As currently defined, clients that have knowledge of LDAPsubentries can retrieve them and those that do not won't. That meets my needs. > I primarily make these suggestions because I believe these changes would > make subentries within LDAP more usable, in particular, when used in > support of the access control model. Interesting. Before we throw out the simple LDAPsubentry that Ed has defined, I think someone should list the additional requirements that are needed for the access control effort to successfully use subentries. -- Mark Smith iPlanet From list@netscape.com Fri Jul 7 12:18:23 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01779 for ; Fri, 7 Jul 2000 12:18:22 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e67G8ag29716; Fri, 7 Jul 2000 09:08:37 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e67GDdc14823; Fri, 7 Jul 2000 09:13:39 -0700 (PDT) Resent-Date: Fri, 7 Jul 2000 09:13:39 -0700 (PDT) Message-Id: <4.3.2.7.0.20000707083711.00b1aa00@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Jul 2000 09:01:37 -0700 To: mcs@netscape.com (Mark C Smith) From: "Kurt D. Zeilenga" Subject: Re: LDAP subentry alignment with X.500 subentry Cc: ietf-ldapext@netscape.com, ietf-ldup@imc.org, Ed Reed In-Reply-To: <3965F2EC.EFE5B84C@netscape.com> References: <4.3.2.7.0.20000703085803.00af9a60@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"dhMgQB.A.gkD.qGgZ5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 08:10 AM 7/7/00 -0700, Mark C Smith wrote: >"Kurt D. Zeilenga" wrote: >> >> I believe 'LDAPsubentry' should be replaced with with 'subentry' and >> defined such that it closely modelled after X.500. >> >> 1) subentries should have a subtree specifier such that they are more >> useful for specification of ACI subentries. > >The X.500 subtree specifier is rich and therefore fairly complex to >implement. That doesn't mean we shouldn't adopt it, but it does mean we >should consider the impact. We should consider the impact of implementing something different. LDAP is an access protocol to an X.500 directory. Each divergence from the X.500 information/service models makes increasing difficult to implement servers which supports both LDAP and DAP and gateways between LDAP and DAP. >> 2) subentries should be visible based upon presence of a subentries control, >> not a filter components. For example: >> (|(&(objectclass=LDAPsubentry)(!(cn=*))(objectclass=*)) >> >> Should the subentry be visible or not? There are reasonable arguments >> for both yes and no. > >But controls are of course more costly for clients and servers to >implement. I disagree. A control is actually quite simple to implement and rather cheap (as demonstrated by ManageDsaIT). Interpeting filter side effects in complex and often leads to inconsistent implementations due to ambiguity in the specification of these side effects (as demonstrated by matched-00). The advantage of a control is it provides an unambiguous mechanism to enable the behavior. > What problem are you trying to solve? In terms of the filter comment: ambiguity of specification, consistency of implementation. In terms of subentry v. entry comment: unnecessary incompatible divergence from X.500. >As currently defined, >clients that have knowledge of LDAPsubentries can retrieve them and >those that do not won't. Does the filter above have the side effect of making subentries visible or not? >> I primarily make these suggestions because I believe these changes would >> make subentries within LDAP more usable, in particular, when used in >> support of the access control model. > >Interesting. Before we throw out the simple LDAPsubentry that Ed has >defined, I think someone should list the additional requirements that >are needed for the access control effort to successfully use subentries. To turn the tables a bit, before we through out X.500 subentry, I think someone should list LDUP (or other) requirements which the X.500 subentry mechanism is inadequate. From list@netscape.com Fri Jul 7 13:56:57 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07473 for ; Fri, 7 Jul 2000 13:56:57 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e67Hktg14188; Fri, 7 Jul 2000 10:46:55 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e67Ht9k28862; Fri, 7 Jul 2000 10:55:09 -0700 (PDT) Resent-Date: Fri, 7 Jul 2000 10:55:09 -0700 (PDT) Sender: Robert.Byrne@france.Sun.COM Message-ID: <3966195F.E13E6B30@france.sun.com> Date: Fri, 07 Jul 2000 19:54:39 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mark C Smith CC: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com, ietf-ldup@imc.org, Ed Reed Subject: Re: LDAP subentry alignment with X.500 subentry References: <4.3.2.7.0.20000703085803.00af9a60@infidel.boolean.net> <3965F2EC.EFE5B84C@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"74PkDD.A.pCH.8lhZ5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Mark, I would say that the complexity of the X.500 style specifier would be a barrier to it's adoption for the LDAP access control model. So I would say some simplified subtree specifier would be preferable (base, onelevel, subtree ?). Even ignoring the subtree specifier there are cons associated with putting acis into subentries compared to just storing them as attributes--for example you need to control access to the subentries which, becuase subentries do not behave like ordinary entries, requires at least one additional aci attribute (something like entryACI or subEntryACI). Rob. Mark C Smith wrote: > > > I primarily make these suggestions because I believe these changes would > > make subentries within LDAP more usable, in particular, when used in > > support of the access control model. > > Interesting. Before we throw out the simple LDAPsubentry that Ed has > defined, I think someone should list the additional requirements that > are needed for the access control effort to successfully use subentries. > > -- > Mark Smith > iPlanet From list@netscape.com Fri Jul 7 14:44:22 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09542 for ; Fri, 7 Jul 2000 14:44:21 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e67IWOg21764; Fri, 7 Jul 2000 11:32:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e67IecM23065; Fri, 7 Jul 2000 11:40:38 -0700 (PDT) Resent-Date: Fri, 7 Jul 2000 11:40:38 -0700 (PDT) Message-ID: <918C79AB552BD211A2BD00805F15CE8503753B0E@x-crt-es-ms1.cp10.es.xerox.com> From: "Manros, Carl-Uno B" To: srvloc@srvloc.org, ietf-ldapext@netscape.com Cc: Carl-Uno Manros , Ned Freed Subject: FW: ADM - IPP Working Group Last Call for: "Internet Printing Pr otocol (IPP): LDAP Schema for Printer Services" Date: Fri, 7 Jul 2000 11:40:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e67IeZ123011 Resent-Message-ID: <"tCvAo.A.1nF.kQiZ5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit To the Members of the Service Location Protocol and the LDAP Extension Working Groups. Please note that I have just circulated the following IPP WG Last Call for our document on LDAP Schema for Printer Services. As this is a transplant from the SLP version, I am informing both groups. If you have comments on this document, please address them to the IPP WG at ipp@pwg.org before the IPP WG Last Call deadline on July 21, 2000. Let me also take the opportunity to thank the members of your groups who have contributed to this document. Regards, Carl-Uno Manros Chair of IETF IPP WG Principal Engineer - Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com > -----Original Message----- > From: Manros, Carl-Uno B > Sent: Friday, July 07, 2000 11:30 AM > To: IETF-IPP > Cc: Ned Freed; Patrik Fältström > Subject: ADM - IPP Working Group Last Call for: "Internet Printing > Protocol (IPP): LDAP Schema for Printer Services" > > > All, > > This is a working group Last Call for the "Internet Printing Protocol > (IPP): LDAP Schema for Printer Services" The latest version of this > document has been forwarded to the Internet Draft directory as > > > The Last Call notice follows: > > This is a formal request for final comments within the IETF IPP > working group for one document. The document is "Internet Printing > Protocol > (IPP): LDAP Schema for Printer Services" which is being proposed > for forwarding on to the IESG for publication as an RFC to complement the > previous suite of IPP/1.1 documents. This is a working group product, > which > has been thoroughly discussed since mid 1999. > > The document has undergone considerable review and revisions during the > past > year in collaboration with experts from the SLP and LDAP community and I > believe that we now have working group consensus on its adequacy. > > The purpose of a working group Last Call is in the style of "speak now or > forever hold your peace" in case there are fundamental objections which > have > not gotten previous or adequate discussion, or minor errors which need > correction. > > Last Calls are for a minimum of 2 weeks. We will start the Last Call > period > today Friday 7 June, 2000 and the period for working group comments will > close on Friday, 21 June (US Pacific time reference), 2000. > > The relevant document is: > > Title : Internet Printing Protocol (IPP): LDAP Schema for > Printer Services > Author(s) : P. Fleming, K. Jones, H. Lewis, I. McDonald > Filename : draft-ietf-ipp-ldap-printer-schema-02.txt > Pages : 26 > Date : 06-Jul-00 > > This document is a product of the Internet Printing Protocol Working > Group, chartered by the IETF. Comments should be sent to the > ipp@pwg.org mailing list and the principal editor > flemingp@us.ibm.com. > This document defines a common printer schema for use with LDAP > directories (a directory service supporting the Lightweight Directory > Access Protocol (LDAP)). Using this common printer schema enables > client applications to use LDAP to search for printers using > application or user specified search criteria. Searches are defined > based on the entry's type and attributes independent of the LDAP > directory being used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipp-ldap-printer-schema-02. > txt > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipp-ldap-printer-schema-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipp-ldap-printer-schema-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > Sincerely, > > Carl-Uno Manros > Chair of IETF IPP WG > > Carl-Uno Manros > Principal Engineer - Xerox Architecture Center - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com > From list@netscape.com Fri Jul 7 16:42:22 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12743 for ; Fri, 7 Jul 2000 16:42:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e67KWag07577; Fri, 7 Jul 2000 13:32:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e67Keo611818; Fri, 7 Jul 2000 13:40:50 -0700 (PDT) Resent-Date: Fri, 7 Jul 2000 13:40:50 -0700 (PDT) Message-Id: <4.3.2.7.0.20000707081813.00b06480@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Jul 2000 13:21:23 -0700 To: Jeff.Hodges@stanford.edu From: "Kurt D. Zeilenga" Subject: Re: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3" Cc: IETF ldapext WG In-Reply-To: <200007070623.XAA17170@breakaway.Stanford.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"WCYwnD.A.H3C.MBkZ5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:23 PM 7/6/00 -0700, Jeff.Hodges@stanford.edu wrote: >> If one were to rescind the IESG notice, I would think >> it appropriate to strength the Security Considerations >> of the specifications. Something like: >> Update functionality SHOULD be restricted to securely >> authenticated clients. Note that RFC2829 nor RFC2830 adds a requirement similar to the above statement. They only "encourage" servers to prevent update by anonymous users. This, IMO, is insufficient. Recall that the IESG notice states: "Update access requires secure authentication" This could (though not my preferred solution) be addressed in the Applicability Statement by adding: "Implementations of LDAPv3 SHOULD restrict update functionality described in RFC2251 to clients which have authenticated using a secure mechanism as described in RFC 2829." >RFC2829's explicit purpose is to provide exactly the enhancement to >LDAPv3-as-a-whole's "Security Considerations" that you're calling for. Where does it provide an explicit requirement statement which restricts, with SHOULD or MUST, update functionality to securely authenticated clients. This is what I am calling for. >It seems to us that the present-day artifact that is LDAPv3 is still somewhat >fuzzily defined in the absence of an AS saying these simple, specific things. I agree that LDAPv3 is still "somewhat fuzzy" and that an applicability statement is needed. >What it does mean is that we'll be providing an unambiguous definition, >including security considerations, of what we mean ~today~ when we >-- or any of the many implementors & vendors out there -- say "LDAPv3". I find that the AS creates an unambiguous definition, in particular, in regards to security considerations. I would much rather publish an AS which states that LDAPv3 'requires' implementation of the listed RFCs WITHOUT rescinding the notice or otherwise updating the specifications. I believe rescinding of the notice is best left to later revision of the technical specifications. From list@netscape.com Sat Jul 8 05:35:17 2000 Received: from netscape.com ([205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04393 for ; Sat, 8 Jul 2000 05:35:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e689PXg04560; Sat, 8 Jul 2000 02:25:33 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e689Xms15598; Sat, 8 Jul 2000 02:33:48 -0700 (PDT) Resent-Date: Sat, 8 Jul 2000 02:33:48 -0700 (PDT) Date: Sat, 8 Jul 2000 02:33:33 -0700 (PDT) Message-Id: <200007080933.e689XWx02987@ywing.netscape.com> From: me.TNOA@ywing.netscape.com To: you.FQHN@netscape.com Subject: Parent of 15 year old finds $71,000 in closet... X-Reply-To: 123abc@freeze.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"VjWhBC.A.NzD.6VvZ5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit **************************************************************** ***************************** To be removed from this list, please reply to this email with the word "REMOVE" and the EMAIL ADDRESS it was sent to in the subject box. See legal disclaimer at the end of this text. Thank you. **************************************************************** ***************************** It Works, Its Legal, Its Easy, so Why Not? Parents of 15-year-old find $71,000 cash hidden in his closet. Does this headline look familiar? Of course it does. You most likely have just seen this story recently featured on a major nightly news program (USA). His mother was cleaning and putting laundry away when she came across a large brown paper bag that was suspiciously buried beneath some clothes and a skateboard in the back of her 15-year-old son's closet. Nothing could have prepared her for the shock she got when she opened the bag and found it was full of cash. Five dollar bills, twenties, fifties and hundreds - all neatly rubber-banded in labeled piles. "My first thought was that he had robbed a bank", says the 41-year-old woman, "There was over $71,000 dollars in that bag - that's more than my husband earns in a year". The woman immediately called her husband at the car-dealership where he worked to tell him what she'd discovered. He came home right away and they drove together to the boy's school and picked him up. Little did they suspect that where the money came from was more shocking than actually finding it in the closet. As it turns out, the boy had been sending out via E-mail on the Internet a type of 'chain-letter' to E-mail addresses that he obtained off of the Internet. Everyday after school for the past 2 months, he had been doing this right on his computer in his bedroom. "I just got the E-mail one day and I figured what the heck, I put my name on it like the instructions said and I started sending it out", says the clever 15-year-old. The E-mail letter listed 3 addresses and contained instructions to send one $5 dollar bill to the person at the top of the list, then delete that address and move the other 2 addresses up, and finally to add your name to the bottom of the list. The letter goes on to state that you would receive several thousand dollars in five dollar bills within 2 weeks if you sent out the letter with your name at the bottom of the 3-address list "I get junk E-mail all the time, and I really didn't think it was gonna work", the boy continues. Within the first few days of sending out the E-mail, the Post Office Box that his parents had gotten him for his video-game magazine subscriptions began to fill up with not magazines, but envelopes containing $5 dollar bills. "About a week later I rode [my bike] down to the post office and my box had 1 magazine and about 300 envelopes stuffed in it. There was also a yellow slip that said I had to go up to the [post office] counter- I thought I was in trouble or something (laughs)". He goes on, "I went up to the counter and they had a whole box of more mail for me. I had to ride back home and empty out my backpack 'cause I couldn't carry it all". Over the next few weeks, the boy continued sending out the E-mail. "The money just kept coming in and I just kept sorting it and stashing it in the closet, I barely had time for my homework". He had also been riding his bike to several of the area's banks and exchanging the $5 bills for twenties, fifties and hundreds. "I didn't want the banks to get suspicious so I kept riding to different banks with like five thousand at a time in my backpack. I would usually tell the lady at the bank counter that my dad had sent me in [to exchange the money] and he was outside waiting for me. One time the lady gave me a really strange look and told me that she wouldn't be able to do it for me and my dad would have to come in and do it, but I just rode to the next bank down the street (laughs). " Surprisingly, the boy didn't have any reason to be afraid. The reporting news team examined and investigated the so-called 'chain-letter' the boy was sending out and found that it wasn't a chain-letter at all. In fact, it was completely legal according to US Postal and Lottery Laws, Title 18, Section 1302 and 1341, or Title 18, Section 3005 in the US code, also in the code of federal regulations, Volume 16, Sections 255 and 436, which state a product or service must be exchanged for money received. Every five dollar bill that he received contained a little note that read, "Please add me to your mailing list". This simple note made the letter legal because he was exchanging a service (adding the purchaser's name to his mailing list) for a five dollar fee. Here is the letter that the 15-year-old was sending out by E-mail, you can do the exact same thing he was doing, simply by following the instructions in this letter. * * * * * Here are instructions on how to make $10,000 US cash in the next 2 weeks: There are 3 addresses listed below. Send the person at the top of the list a $5 bill wrapped in 2 pieces of paper (to securely hide it), along with a note that says: "Please add me to your mailing list". Then delete that name, move the other 2 up and put your name at the bottom. Now start sending this ENTIRE e-mail back out to people. When 20 people receive it, those 20 people will move your name up to the middle position and they will each send out 20. That totals 400 people that will receive this letter with your name in the middle. Then, those 400 people will move your name up to the top and they will each send out 20 E-mails. That totals 8,000 people that will receive this E-mail with your name at the top and they will each send you a $5 bill. 8,000 people each sending you a $5 bill = $40,000 cash. That's if everyone responds to this E-mail, but not everyone will, so you can expect more realistically to receive about $10,000 in cash ($5 bills) in your mailbox. This will work for anyone, anywhere in the world in any country, but send only a US CASH $5 bill. The more E-mails you send out, the more cash you will receive. If each person sends out 100 E-mails, there will be 1,000,000 people that receive this letter when your name reaches the top. If only 1% of those people respond, you will still get $50,000 cash. * * * * * Here is the list: 1 Leonard E. Hawkins 1503 Cooley RD. Winter Have, FL 33880 2 - T. Nolley 10823 Club Cir. Indianapolis, IN 46229 3 - B. R. 1889 Merrill Rd Paradise, CA 95969 * * * * * THERE'S NOTHING MORE TO DO. When your name reaches the top in a few days, you will start receiving $5 bills from other people just like yourself, who are willing to invest a $5 bill to receive $10,000 cash. If you don't try it - you will never know. **************************************************************** ************ This message is sent in compliance of the new email bill HR 1910. Under Bill HR 1910 passed by the 106th U.S. Congress on May 24, 1999, this message cannot be Considered Spam as long as we include the way to be removed. Per Section HR 1910. Please type "Remove" in the subject line and reply to this email. All removal requests are handled personally and immediately once received. **************************************************************** ************ From list@netscape.com Sat Jul 8 13:29:42 2000 Received: from netscape.com ([205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07631 for ; Sat, 8 Jul 2000 13:29:42 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e68HNUe20658; Sat, 8 Jul 2000 10:23:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e68HSAA03840; Sat, 8 Jul 2000 10:28:10 -0700 (PDT) Resent-Date: Sat, 8 Jul 2000 10:28:10 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: internet-drafts@ietf.org Date: Sat, 8 Jul 2000 18:26:54 +0100 MIME-Version: 1.0 Content-type: Multipart/Mixed; boundary=Message-Boundary-16738 Subject: PKIX ID on LDAPv3 Schema Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com, ietf-pkix@imc.org Message-ID: <3967726E.23329.1498525@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"Jp7XCB.A.i7.oS2Z5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --Message-Boundary-16738 Content-type: text/plain; charset=US-ASCII Content-description: Mail message body Content-Transfer-Encoding: 7BIT Dear ID editor could you please publish the enclosed as an Internet Draft. It is work being done under the remit of the PKIX group, but I am copying it to the LDAPExt group as it is of interest to them as well Thankyou David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** --Message-Boundary-16738 Content-type: text/plain; charset=US-ASCII Content-description: Text from file 'PKIXSchema-00.txt' Content-Transfer-Encoding: 7BIT Internet-Draft D.W.Chadwick PKIX WG University of Salford Intended Category: Standards Track Expires: 8 January 2001 8 July 2000 Internet X.509 Public Key Infrastructure Additional LDAP Schema for PKIs and PMIs STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all the provisions of Section 10 of RFC2026 [1]. 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 expires on 6 January 2001. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the PKIX working group discussion list: or directly to the author. ABSTRACT This document describes LDAP schema features in addition to RFC 2587 that are needed to support a Privilege Management Infrastructure and a Public Key Infrastructure. 1. Introduction RFC2587 [8] describes some of the subschema applicable to LDAPv2 servers [2], specifically the public key certificate related attribute types and object classes that MUST or MAY be supported. This [document/ID/standard] does not revoke any of the contents of RFC2587, but supplements them. RFC2587 is equally applicable to LDAPv3 [4] servers as to LDAPv2 servers and MUST be supported by LDAPv3 servers. Neither RFC2587 nor the user schema for LDAPv3 (RFC2256 [3]) nor the attribute syntax definitions for LDAPv3 (RFC2252 [7]) describe in detail the matching rules that should be supported by LDAP servers, nor do they describe how attribute value assertions for each matching rule should be encoded in filter items. Finally none of these documents mention attributeCertificates or any schema to support privilege management, since these concepts superseded the publishing of the RFCs. 2. Subschema Publishing LDAPv3 allows the subschema supported by a server to be published in a subschema subentry. Clients following this profile which support the Search operation containing an extensible matching rule SHOULD use the subschemaSubentry attribute in the root DSE to find the subschemaSubentry, and SHOULD use the matchingRule and matchingRuleUse operational attributes in the subschema subentry in order to determine whether the server supports the various matching rules described below. Servers which support extensible matching SHOULD publish the matching rules they support in the matchingRule and matchingRuleUse operational attributes. 3. Public Key Certificate Matching Rules X.509 [9] supports both equality and flexible certificate matching rules by the server, via the certificateExactMatch and certificateMatch MATCHING-RULEs respectively. (For example, a client may flexibly search for certificates with a particular validity time, key usage, policy or other field.) LDAPv3 servers MUST support the certificateExactMatch matching rule. Clients MAY support certificateExactMatch values for equalityMatch filters. LDAPv3 servers SHOULD support the certificateMatch matching rule. If the server does support flexible matching (either via certificateMatch or some other matching rule), then the extensibleMatch filter of the Search request MUST be supported. Clients MAY support the extensibleMatch filter and one or more of the optional elements of certificateMatch. Neither of the above matching rules are mentioned in the LDAPv3 standards [3 or 7], and only the equality matching rule is mentioned in [8], but nowhere is it defined for LDAP servers. It is expected that future revisions of the LDAPv3 documents will include these definitions, which are described below. 3.1 Certificate Exact Match Certificate exact match is defined in 11.3.1 of [9]. The string description of the certificateExactMatch matching rule is: ( 2.5.13.34 NAME 'certificateExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.x ) Note. x is still to be allocated The LDAP syntax definition is: ( 1.3.6.1.4.1.1466.115.121.1.x DESC 'Certificate Serial Number and Issuer' ) Values in this syntax are encoded as an integer, a dollar ($) separator and a string encoding of the distinguished name of the issuing CA. 3.2 Certificate Match Certificate match is defined in 11.3.2 of [9]. The string description of the certificateMatch matching rule is: ( 2.5.13.35 NAME 'certificateMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.y ) Note. y is still to be allocated The syntax definition is: ( 1.3.6.1.4.1.1466.115.121.1.y DESC 'Certificate Assertion' ) The ASN.1 for certificateAssertion is defined in 11.3.2 of [9], as are the semantics of each of its component types. The LDAP string encoding of this is: - an optional integer representing the certificate serial number, - followed by a dollar separator ($), - followed by an optional string encoding of the distinguished name of the issuing CA, - followed by a dollar separator, - followed by an optional string encoding of the subject key identifier octet string using hex character encoding, - followed by a dollar separator, - followed by an optional string encoding of the authority key identifier octet string using hex character encoding, (Editor's note. This is a subset of the X.509 allowed values for authority key identifier. Is this the best choice to make?) - followed by a dollar separator, - followed by an optional string representation of the generalised time of the certificate validity (in the format yyyymmddhhmmssZ as specified in RFC 2252), - followed by a dollar separator, - followed by an optional string representation of the generalised time for the private key validity, - followed by a dollar separator - followed by an optional string encoding of the object identifier of the subject public key algorithm, - followed by a dollar separator, - followed by an optional string encoding of the key usage bit string according to RFC 2252 e.g. '0101111101'B. The first (left most) bit represents key usage digital signature (bit 0). Note that if less bits are present than defined in the keyUsage field it is assumed that those right most bits that are not present have the value 0, - followed by a dollar separator, - followed by an optional string encoding of the subjectAltName type using the following keywords "rfc822", "dns", "x400", "ldapdn", "edi", "uri", "ip", "oid", or the string encoding of the object identifier the other name form type being sought if it is none of the above, - followed by a dollar separator, - followed by an optional string encoding of one or more object identifiers of certificate policies each separated by "+" character if there is more than one, - followed by a dollar separator, - followed by an optional string encoding of the distinguished name of the entity to which a certification path cannot be made - followed by a dollar separator, - followed by an optional string encoding of the distinguished name of the subject, - followed by a dollar separator, - followed by an optional string encoding of the name constraints as follows: the string "permitted" followed by a "+" followed by the type of name using one of the keywords "rfc822", "dns", "x400", "ldapdn", "edi", "uri", "ip", "oid", or the string encoding of the object identifier the name type, followed by a "+" followed by a string encoding of the name, followed by "excluded", a "+", the type of name, a "+" and the string encoding of the name of the excluded subtree, Editor's note 1. With proper BNF for this we can miss out either the permitted or excluded components Editor's note 2. This is a subset of the allowed values of name contstraints (minimum and maximum are missing). Do we want to add these? - and finally ending with a dollar separator. Where any optional field is missing this is indicated by the presence of two contiguous dollar separators (or if the certificate serial number is missing a certificate assertion that starts with a dollar separator). Editors Notes. 1. We need to decide whether searching for cross certificates should be supported by this LDAPv3 profile or not. If we decide that this should be supported, then we will need to define the matching rules to be supported and the string encodings for the assertion syntaxes (in fact this is not too difficult since they are similar to certificate matching rules and AVAs). 2. We need to decide if userSMIMECertificates should also be supported as part of this profile or not. 4. Public Key Certificate Revocation List Matching Rules X.509[9] defines both equality and flexible matching rules for CRLs, via the certificateListExactMatch and certificateListMatch MATCHING- RULEs respectively. LDAPv3 servers MUST support the certificateListExactMatch matching rule. Clients MAY support certificateListExactMatch values for equalityMatch filters. LDAPv3 servers MAY support the certificateListMatch matching rule. If the server does support flexible matching (either via certificateListMatch or some other matching rule), then the extensibleMatch filter of the Search request MUST be supported. Clients MAY support the extensibleMatch filter and one or more of the optional elements of certificateListMatch. 4.1 Certificate List Exact Match Certificate List exact match is defined in 11.3.5 of [9]. The string description of the certificateListExactMatch matching rule is: ( 2.5.13.38 NAME 'certificateListExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.z ) Note. z is still to be allocated The syntax definition is: ( 1.3.6.1.4.1.1466.115.121.1.z DESC 'Issuer name, time and distribution point name' ) Values in this syntax are encoded as a string encoding of a distinguished name, a dollar ($) separator, a string representation of generalised time, a dollar separator and an optional string encoding of the distinguished name of the distribution point. (Editor's Note. The latter DN encoding for a distribution point name is a subset of the allowed variants, which can be a generalName or an RDN. Should this simplification be allowed?) 4.2 Certificate List Match Certificate List match is defined in 11.3.6 of [9]. The string description of the certificateListMatch matching rule is: ( 2.5.13.39 NAME 'certificateListMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.w ) Note. w is still to be allocated The syntax definition is: ( 1.3.6.1.4.1.1466.115.121.1.w DESC 'Certificate List Assertion' ) The ASN.1 for certificateListAssertion is defined in 11.3.6 of [9]. Values in this syntax are encoded as: - an optional string encoding of the distinguished name of the issuer, - followed by a dollar ($) separator, - followed by an optional string encoding of an integer representing the minimum CRL number, - followed by a dollar separator, - followed by an optional string encoding of an integer representing the maximum CRL number, - followed by a dollar separator, - followed by an optional string encoding of the reason flags bit string according to RFC 2252 e.g. '010111110'B. The first (left most) bit represents unused reason flag (bit 0). Note that if less bits are present than defined in the reason flags field it is assumed that those right most bits that are not present have the value 0, - followed by a dollar separator, - followed by an optional string representation of the generalised time for the CRL validity, - followed by an optional string encoding of the authority key identifier octet string using hex character encoding, (Editor's note. This is a subset of the X.509 allowed values for authority key identifier. Is this the best choice to make?) - and ending with a dollar separator. 5. Privilege Management Schema LDAP servers MAY store any type of attribute with the AttributeCertificate syntax, and LDAP clients MAY request them to be returned by adding them to the Search Request AttributeDescriptionList (either explicitly or implicity via requesting all attributes). LDAP servers that do support the storage of attributes with the AttributeCertificate syntax MUST support searching for entries containing specific attribute certificates, via the attributeCertificateExactMatch matching rule. LDAPv3Servers MAY support flexible matching for any attributes with the AttributeCertificate syntax via the attributeCertificateMatch matching rule or any of the matching rules defined for the certificate extensions. LDAPv3 servers SHOULD publish the matching rules that they do support in the matchingRule and matchingRuleUse operational attributes of the subschema subentry. LDAPv3 clients MAY support the extensibleMatch filter of the Search operation, along one or more of the optional elements of attributeCertificateMatch or any of the certificate extension matching rules. For the convenience of the reader, some of the subchema definitions to support attribute certificates are produced below, but it is anticipated that these will be moved to a subsequent revision of the LDAPv3 standard. 5.1 PMI Attributes The attributeCertificateAttribute holds the privileges of a user. attributeCertificateAttribute ATTRIBUTE ::= { WITH SYNTAX AttributeCertificate EQUALITY MATCHING RULE attributeCertificateExactMatch ID joint-iso-ccitt(2) ds(5) attributeType(4) attributeCertificate(58) } The aAcertificate holds the privileges of an attribute authority aACertificate ATTRIBUTE ::= { WITH SYNTAX AttributeCertificate EQUALITY MATCHING RULE attributeCertificateExactMatch ID joint-iso-ccitt(2) ds(5) attributeType(4) aACertificate(61} The attributeDescriptorCertificate is self signed by a source of authority and holds a description of the privilege and its delegation rules. attributeDescriptorCertificate ATTRIBUTE ::= { WITH SYNTAX AttributeCertificate EQUALITY MATCHING RULE attributeCertificateExactMatch ID joint-iso-ccitt(2) ds(5) attributeType(4) attributeDescriptorCertificate (62) } The attributeCertificateRevocationList holds a list of attribute certificates that have been revoked. attributeCertificateRevocationList ATTRIBUTE ::= { WITH SYNTAX CertificateList EQUALITY MATCHING RULE certificateListExactMatch ID joint-iso-ccitt(2) ds(5) attributeType(4) aCRL(59) } The attributeAuthorityList holds a list of AA certificates that have been revoked. attributeAuthorityRevocationList ATTRIBUTE ::= { WITH SYNTAX CertificateList EQUALITY MATCHING RULE certificateListExactMatch ID joint-iso-ccitt(2) ds(5) attributeType(4) aARL(63) } 5.2 PMI Object Classes pmiUser OBJECT-CLASS ::= { -- a privilege holder SUBCLASS OF {top} KIND auxiliary MAY CONTAIN {attributeCertificateAttribute} ID joint-iso-ccitt(2) ds(5) objectClass(6) pmiUser (24)} pmiAA OBJECT-CLASS ::= { -- an attribute authority SUBCLASS OF {top} KIND auxiliary MAY CONTAIN {aACertificate | attributeCertificateRevocationList | attributeAuthorityRevocationList} ID joint-iso-ccitt(2) ds(5) objectClass(6) pmiAA (25)} pmiSOA OBJECT-CLASS ::= { -- a PMI Source of Authority SUBCLASS OF {top} KIND auxiliary MAY CONTAIN {attributeCertificateRevocationList | attributeAuthorityRevocationList | attributeDescriptorCertificate} ID joint-iso-ccitt(2) ds(5) objectClass(6) pmiSOA (26)} 5.3 PMI Matching Rules 5.3.1 Attribute Certificate Exact Match The equality matching rule for all types of attribute with AttributeCertificate syntax is the attributeCertificateExactMatch, This is defined in 17.3.1 of [9]. It is reproduced below for the convenience of the reader. attributeCertificateExactMatch MATCHING-RULE ::= { SYNTAX AttributeCertificateExactAssertion ID joint-iso-ccitt(2) ds(5) mr (13) attributeCertificateExactMatch (45) } AttributeCertificateExactAssertion ::= SEQUENCE { serialNumber CertificateSerialNumber, issuer IssuerSerial } CertificateSerialNumber ::= INTEGER IssuerSerial ::= SEQUENCE { issuer GeneralNames, serial CertificateSerialNumber, issuerUID UniqueIdentifier OPTIONAL } UniqueIdentifier ::= BIT STRING The LDAP definition for the above matching rule is: ( 2.5.13.45 NAME 'attributeCertificateExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.m ) Note that the value of m is still to be allocated. The syntax definition is: ( 1.3.6.1.4.1.1466.115.121.1.m DESC 'Attribute certificate serial number and public key issuer and serial number' ) Values in this syntax are encoded as a string encoding of an integer (the serial number of the attribute certificate), a dollar ($) separator, a string representation of the distinguished name of the CA of the issuer, a dollar separator, a string encoding of an integer (the serial number of the issuer's public key certificate), a dollar separator and optionally a string encoding of the unique identifier bit string according to RFC 2252 e.g. '010111110'B. Editors note. Issuer DN is a subset of the allowed GeneralNames. Do we wish to allow any type? 5.3.2 Attribute Certificate Match Attribute certificate matching rule is defined in section 17.3.2 of [9]. For the convenience of the reader it is reproduced below: attributeCertificateMatch MATCHING-RULE ::= { SYNTAX AttributeCertificateAssertion ID joint-iso-ccitt(2) ds(5) mr (13) attributeCertificateMatch (42) } AttributeCertificateAssertion ::= SEQUENCE { subject [0] CHOICE { baseCertificateID [0] IssuerSerial, subjectName [1] GeneralNames} OPTIONAL, issuer [1] GeneralNames OPTIONAL, attCertValidity [2] GeneralizedTime OPTIONAL, attType [3] SET OF AttributeType OPTIONAL} --At least one component of the sequence must be present The LDAP definition of the attributeCertificateMatch matching rule is: ( 2.5.13.42 NAME 'attributeCertificateMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.n ) Note that the value of n is still be assigned. The syntax definition is: ( 1.3.6.1.4.1.1466.115.121.1.n DESC 'Attribute Certificate Assertion' ) The LDAP string encoding of this is: - Optionally a string encoding of a distinguished name, optionally followed by a "+" and a string encoding of an integer, Note. If the optional + and integer are missing the distinguished name is the name of the holder of the attribute certificate, whereas if they are present it is the name of the issuer of the certificate and the integer is the serial number of the holder's certificate. Editors note. Distinguished names are a subset of the allowed types in General Name. Is this OK or too restrictive? - followed by a dollar ($) separator, - followed by an optional string encoding of the distinguished name of the issuer, Editor's Note. This is a subset of the allowed General Names. Is it sufficient? - followed by a dollar separator, - followed by an optional string representation of the generalised time of the certificate validity (in the format yyyymmddhhmmssZ as specified in RFC 2252), - followed by a dollar separator, - followed by an optional string encoding of one or more object identifiers of attribute types each separated by "+" character if there is more than one. Editor's Note. X.509 defines the following matching rules for matching on various extensions within an attribute certificate. Before any of them is defined for LDAP, we need to decide how many of them are really useful. 5.3.3 Holder Issuer Match 5.3.4 Delegation Path Match 5.3.5 Authority Attribute Identifier Match 5.3.6 Role Specification Certificate Identifier Match 5.3.7 Basic Attribute Constraints Match 5.3.8 Delegated Name Constraints Match 5.3.9 Time Specification Match 5.3.10 Acceptable Certificate Policies Match 5.3.11 Attribute Descriptor Match 5.3.12 Source of Authority Match Note. This rule has not been defined by X.509, but this is perhaps an omission that should be rectified. It is an easy matching rule to define since it has a null syntax i.e. we will be matching on present or not. 6. Security Considerations This [Internet Draft/Standard] describes the schema for the storage and matching of attribute certificates and revocation lists in an LDAP directory server. It does not address the protocol for the retrieval of this information. LDAP servers SHOULD use access control information to protect the information during its storage. In addition, clients MAY choose to encrypt the attributes in the attribute certificates before storing them in an LDAP server. 7 Copyright Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 8. References [1] Bradner, S. The Internet Standards Process -- Revision 3. RFC 2026 October 1996. [2] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access Protocol", RFC 1777, March 1995. [3] M.Wahl. "A Summary of the X.500(96) User Schema for use with LDAPv3" RFC 2256, Dec 1997 [4] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", Dec. 1997, RFC 2251 [5] S.Bradner. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [6] M. Wahl, S. Kille, T. Howes. "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC2253, December 1997. [7] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, Dec 1997 [8] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key Infrastructure, LDAPv2 Schema", RFC 2587, June 1999 [9] ITU-T Rec. X.509(2000) The Directory: Authentication Framework 9 Authors Address David Chadwick IS Institute University of Salford Salford England M5 4WT Email: d.w.chadwick@salford.ac.uk Internet-Draft PKIX Operational Protocols - LDAP Schema 8 July 2000 --Message-Boundary-16738-- From list@netscape.com Sat Jul 8 22:44:36 2000 Received: from netscape.com ([205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12814 for ; Sat, 8 Jul 2000 22:44:36 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e692bfe09011; Sat, 8 Jul 2000 19:37:42 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e692gNw01401; Sat, 8 Jul 2000 19:42:23 -0700 (PDT) Resent-Date: Sat, 8 Jul 2000 19:42:23 -0700 (PDT) Date: Sat, 8 Jul 2000 19:42:19 -0700 (PDT) Message-Id: <200007090242.e692gIx03367@ywing.netscape.com> From: apic@yahoo.com To: "customer"@netscape.com Subject: Hi X-Reply-To: apic_2001@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"MpBJP.A.kV.Na-Z5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit HI; I am Leo DBA A Internet Professional Consultant. I am sending YOU this E-Mail to inform you that I am sending YOU some tips, suggestions. and maybe a New Letter. What I want to do if I can. I want help YOU in some way to better your life. "If you do not want to receive email updates, please send an email to apic_2001@yahoo.com and type 'remove" in the subject line" From list@netscape.com Sun Jul 9 04:47:14 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07014 for ; Sun, 9 Jul 2000 04:47:13 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e698bLg28160; Sun, 9 Jul 2000 01:37:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e698jc629878; Sun, 9 Jul 2000 01:45:38 -0700 (PDT) Resent-Date: Sun, 9 Jul 2000 01:45:38 -0700 (PDT) Date: Sun, 9 Jul 2000 01:45:14 -0700 (PDT) Message-Id: <200007090845.e698jDx21494@ywing.netscape.com> From: joe.OIFQ@ywing.netscape.com To: you.IXCA@netscape.com Subject: $EASY MONEY$ X-Reply-To: 123abc@freeze.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ayGSSD.A.XSH.wuDa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit **************************************************************** ***************************** To be removed from this list, please reply to this email with the word "REMOVE" and the EMAIL ADDRESS it was sent to in the subject box. See legal disclaimer at the end of this text. Thank you. **************************************************************** ***************************** This could be a great year for you! Please read all of this, it will only take a minute, don't just delete it, I nearly did ! EARN $100,000 PER YEAR SENDING E-MAIL!!! **************************************************************** ******* You can earn $50,000 or more in the next 90 days sending e-mail, seem impossible? Read on for details (no, there is no 'catch')... ----------------------------------------------------------------------- "AS SEEN ON NATIONAL T.V." Thank you for your time and Interest. This is the letter you've been hearing about in the news lately. Due to the popularity of this letter on the internet, a major nightly news program recently devoted an entire show to the investigation of the program, described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are, absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show have been truly remarkable. Since so many people are participating now, those involved are doing much better than ever before. Everyone makes more as more people try it out. It is very, very exciting to be a part of this plan. You will understand once you experience it. "HERE IT IS, BELOW" ================================================ ================================================ *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a look at. It can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days! Please read the enclosed program...THEN READ IT AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not require you to come into contact with people, do any hard work and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you've been waiting for, THIS IS IT! Simply follow the instructions, and your dreams will come true. This e-mail marketing program works perfectly...100%, EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this program now! MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multi-level methods by the late 1990's. This is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last few years in MLM. Moreover, statistics show 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump made an appearance on the David Letterman Show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response - "That's why I'm sitting up here and you are all sitting out there!" With network marketing you have two sources of income. Direct commissions from sales you make yourself and commissions from sales made by people you introduce to the business. Residual income is the secret of the wealthy. It means investing time or money once and getting paid again and again and again. In network marketing, it also means getting paid for the work of others. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. My name is Ellie Gilbert. Two years ago, the corporation I worked for, the past twelve years, down-sized and my position was eliminated. After many unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $40,000.. I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life, FINANCIALLY, FOREVER!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a best selling book to make it! But, as I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725- 2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 10,000 e-mails. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, the only expense is my time. I'm telling you as it is, I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it cost me. In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. If you don't, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER! Remember, it won't work if you don't try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work, you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a business owner and in financial trouble, as I was, or you want to start your own business, consider this a good luck sign. I DID! Sincerely, Ellie Gilbert P.S. Do you have any idea what $58,000 looks like piled up on a kitchen table? IT'S AWESOME! A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports you should have concluded that such a program, one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich". You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have already made over 4 MILLION DOLLARS! I have retired from the program after sending out over 16,000 programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000...and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent, IT IS NOW UP TO YOU! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLARS INSTRUCTIONS: This method of raising capital REALLY WORKS 100 %, EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi- Level Mail Order Marketing anywhere: This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if you don't order them). * For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! * When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, take this letter and remove the name and address under REPORT #4. This person has made it through the cycle and is no doubt counting their $50,000! c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you copy every name and address ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. 4. Now you're ready to start an advertising campaign on the WORLD WIDE WEB! SEND OUT THIS LETTER (with your name added) TO AS MANY PEOPLE AS YOU CAN, EVEN FRIENDS AND FAMILY. Advertising on the WEB can be very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Another avenue which you could use for advertising is e-mail lists. You can buy these lists for under $20/20,000 addresses or you can pay someone to take care of it for you. BE SURE TO START YOUR AD CAMPAIGN IMMEDIATELY! 5. For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME- DAY SERVICE ON ALL ORDERS! This will help guarantee that the e-mail THEY send out, with YOUR name and address on it, will be prompt because they can't advertise until they receive the report! To grow fast be prompt and courteous. ------------------------------------------ AVAILABLE REPORTS ------------------------------------------ ***Order Each REPORT by NUMBER and NAME*** Notes: - ALWAYS SEND $5 CASH FOR EACH REPORT - ALWAYS SEND YOUR ORDER VIA THE QUICKEST DELIVERY - Make sure the cash is concealed by wrapping it in at least two sheets of paper so no one steals it. - On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your postal address. ________________________________________________ REPORT #1 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES" ORDER REPORT #1 FROM: B. R. 1889 Merrill Rd Paradise, Ca 95969 ________________________________________________ REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES" ORDER REPORT #2 FROM: Omega8 328 Cambridge Drive Cincinnati, Ohio 45241 ________________________________________________ REPORT #3 "SOURCES FOR THE BEST MAILING LISTS" ORDER REPORT #3 FROM: MBI P.O.Box 1564 Portage, Indiana 46368 ________________________________________________ REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS" ORDER REPORT #4 FROM: C. Chen 6425 Aspen Way Cincinnati, Ohio 45224 ----------------------------------------------------------------------- HERE'S HOW THIS AMAZING PLAN WILL MAKE YOU $MONEY$ ----------------------------------------------------------------------- Let's say you decide to start small just to see how well it works. Assume your goal is to get 10 people to participate on your first level. (Placing a lot of FREE ads on the internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below. 1st level--your 10 members with $5.....................$50 2nd level--10 members from those 10 ($5 x 100)........$500 3rd level--10 members from those 100 ($5 x 1,000)...$5,000 4th level--10 members from those 1,000 ($5x10,000).$50,000 THIS TOTALS ------> $55,550 Remember, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Lots of people get 100s of participants! THINK ABOUT IT! Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an internet connection and e-mail is FREE! REPORT #3 shows you the most productive methods for bulk e-mailing and purchasing e-mail lists. Some list & bulk e-mail vendors even work on trade! Over 50,000, new people, get on the internet EVERYDAY (CBS NEWS)! *******TIPS FOR SUCCESS******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product (report) to comply with the U.S. Postal & Lottery Laws, Title 18, Sections 1302 and 1341 or Title 18, Section 3005 in the U.S. Code, also Code of Federal Regs. vol. 16, Sections 255 and 436, which state that "a product or service must be exchanged for money received." * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, the results WILL undoubtedly be SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! *******YOUR SUCCESS GUIDELINE******* Follow these guidelines to help assure your success: If you don't receive 10 to 20 orders for REPORT #1 within two weeks, continue advertising until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT #2. If you don't, continue advertising until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash can continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails and start the whole process again! There is no limit to the income you will generate from this business! PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal agency) 1-(800)827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings and results are highly dependant on your activities and advertising. This letter constitutes no guarantees stated nor implied. In the event that it is determined that this letter constitutes a guarantee of any kind, that guarantee is now void. Any testimonials or amounts of earnings listed in this letter may be factual or fictitious. If you have any question of the legality of this letter contact the Office of Associate Director for Marketing Practices Federal Trade Commission Bureau of Consumer Protection in Washington DC. *******T E S T I M O N I A L S******* This program does work, but you must follow it EXACTLY! Especially the rule of not trying to place your name in a different position, it won't work and you'll lose a lot of potential income. I'm living proof that it works. It really is a great opportunity to make relatively easy money, with little cost to you. If you do choose to participate, follow the program exactly, and you'll be on your way to financial security. Sean McLaughlin, Jackson, MS My name is Frank. My wife, Doris, and I live in Bel-Air, MD. I am a cost accountant with a major U.S. Corporation and I make pretty good money. When I received the program I grumbled to Doris about receiving "junk mail." I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I "knew" it wouldn't work. Doris totally ignored my supposed intelligence and jumped in with both feet. I made merciless fun of her, and was ready to lay the old "I told you so" on her when the thing didn't work... well, the laugh was on me! Within two weeks she had received over 50 responses. Within 45 days she had received over $147,200 in $5 bills! I was shocked! I was sure that I had it all figured and that it wouldn't work. I AM a believer now. I have joined Doris in her "hobby." I did have seven more years until retirement, but I think of the "rat race" and it's not for me. We owe it all to MLM. Frank T., Bel-Air, MD I just want to pass along my best wishes and encouragement to you. Any doubts you have will vanish when your first orders come in. I even checked with the U.S. Post Office to verify that the plan was legal. It definitely is! IT WORKS! Paul Johnson, Raleigh, NC The main reason for this letter is to convince you that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $36,470.00 in the first 14 weeks, with money still coming in. Phillip A. Brown, Esq. Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my medium-size post office box crammed with orders! For a while, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this plan is that it doesn't matter where in the U.S. people live. There simply isn't a better investment with a faster return. Mary Rockland, Lansing, MI I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program...11 months passed then it came...I didn't delete this one!...I made more than $41,000 on the first try!! D. Wilburn, Muncie, IN This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for you is if you do it. For your sake, and for your family's sake don't pass up this golden opportunity. Good luck and happy spending! Charles Fairchild, Spokane, WA ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! NOW IS THE TIME ! DECISIVE ACTION YIELDS POWERFUL RESULTS ! ************************************************************** ................... **************************************************************** ************ This message is sent in compliance of the new email bill HR 1910. Under Bill HR 1910 passed by the 106th U.S. Congress on May 24, 1999, this message cannot be Considered Spam as long as we include the way to be removed. Per Section HR 1910. Please type "Remove" in the subject line and reply to this email. All removal requests are handled personally and immediately once received. **************************************************************** ************ From list@netscape.com Sun Jul 9 07:42:44 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07610 for ; Sun, 9 Jul 2000 07:42:43 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e69Ba5e29113; Sun, 9 Jul 2000 04:36:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e69Bekg25633; Sun, 9 Jul 2000 04:40:46 -0700 (PDT) Resent-Date: Sun, 9 Jul 2000 04:40:46 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: , Date: Sun, 9 Jul 2000 12:39:41 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: String Encodings - was RE: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3" Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <3968728D.6264.5320B3B@localhost> Priority: normal In-reply-to: <000401bfe48c$c764ce50$b05508cb@osmium.adacel.com.au> References: <395B9787.30084.1B9DC3C@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"aAY-PD.A.IQG.8SGa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT > It's a shame the LDAP string encodings for attribute values weren't > defined by some algorithmic relationship to the ASN.1 type of the > syntax, much like the way ASN.1 value notation is related to the type. > It wouldn't then be necessary to define a string encoding for each new > attribute value syntax or assertion value syntax imported from X.500, > X.509, etc. The required string encoding would fall out naturally from > the relevant ASN.1 type. How right you are. I have noticed this when writing the latest schema ID for PKIX. > > It's never too late to start though. > I could really do with a BNF wiz kid to help me do this on the PKIX schema. Are you such a person? David > Regards, > Steven > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 9 07:42:49 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07619 for ; Sun, 9 Jul 2000 07:42:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e69BaIe29249; Sun, 9 Jul 2000 04:36:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e69Bexc25871; Sun, 9 Jul 2000 04:40:59 -0700 (PDT) Resent-Date: Sun, 9 Jul 2000 04:40:59 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: Bruce Greenblatt , Date: Sun, 9 Jul 2000 12:39:42 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: String Encodings - was RE: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3" Reply-to: d.w.chadwick@salford.ac.uk CC: Message-ID: <3968728E.4993.5320EE7@localhost> Priority: normal In-reply-to: <3.0.5.32.20000706083011.00926a70@pop.walltech.com> References: <4.3.2.7.0.20000706074219.00b0da30@infidel.boolean.net> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"HN_Dc.A.fTG.ITGa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Bruce said > That's not what I meant at all. Sorry for the confusion. Instead of > defining a new syntax, make use of the existing syntaxes. Here's a > simple example for the telephone number attribute. I could define a > new syntax like: > > TelephoneNumber ::= SEQUENCE { > countryCode [0] DirectoryString, > areaCode [1] DirectoryString, > localNumber [2] DirectoryString } > > for use in attribute types that need telephone numbers, or I could > just directly use the DirectoryString syntax for these, and indicate > that they obey the following BNF: > > telephoneNumber = countryCode whsp "$" whsp areaCode whsp "$" whsp > localNumber ... I think you will find that the approaches are identical i.e. if we were to create an LDAP syntax of the ASN.1 telephone number above we would end up with exactly the same string value that you did. The difference comes in the backend server. An LDAP one will store the LDAP string as the attribute value whereas an X.500 based one will store the ASN.1 value. An interesting point comes when we define the matching rules for this new telephone number. Will we let a user present just an area code, or just a local number or all three components, and what will be the syntax for the asserted value? David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 9 16:30:53 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10438 for ; Sun, 9 Jul 2000 16:30:49 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e69KOYe18315; Sun, 9 Jul 2000 13:24:34 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e69KTGs21663; Sun, 9 Jul 2000 13:29:16 -0700 (PDT) Resent-Date: Sun, 9 Jul 2000 13:29:16 -0700 (PDT) Message-Id: <3.0.5.32.20000709132524.00925e70@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sun, 09 Jul 2000 13:25:24 -0700 To: d.w.chadwick@salford.ac.uk, From: Bruce Greenblatt Subject: Re: String Encodings - was RE: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3" Cc: In-Reply-To: <3968728E.4993.5320EE7@localhost> References: <3.0.5.32.20000706083011.00926a70@pop.walltech.com> <4.3.2.7.0.20000706074219.00b0da30@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"dKZZDD.A._RF.aCOa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 12:39 PM 7/9/2000 +0100, David Chadwick wrote: >Bruce said > >> That's not what I meant at all. Sorry for the confusion. Instead of >> defining a new syntax, make use of the existing syntaxes. Here's a >> simple example for the telephone number attribute. I could define a >> new syntax like: >> >> TelephoneNumber ::= SEQUENCE { >> countryCode [0] DirectoryString, >> areaCode [1] DirectoryString, >> localNumber [2] DirectoryString } >> >> for use in attribute types that need telephone numbers, or I could >> just directly use the DirectoryString syntax for these, and indicate >> that they obey the following BNF: >> >> telephoneNumber = countryCode whsp "$" whsp areaCode whsp "$" whsp >> localNumber ... > >I think you will find that the approaches are identical i.e. if we were ... [snip] I think that is the point that I'm trying to make... There is no reason (that I can see) to define new atttribute syntaxes when you can use the existing ones. It is not always easy or possible to extend the syntaxes that are available on a directory server...Bruce ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com New Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html From list@netscape.com Sun Jul 9 22:22:53 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14021 for ; Sun, 9 Jul 2000 22:22:53 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6A2Cfg11865; Sun, 9 Jul 2000 19:12:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6A2Kxg28769; Sun, 9 Jul 2000 19:21:00 -0700 (PDT) Resent-Date: Sun, 9 Jul 2000 19:21:00 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Bruce Greenblatt'" , "'Kurt D. Zeilenga'" Cc: , Subject: RE: String Encodings - was RE: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3" Date: Mon, 10 Jul 2000 12:23:24 +1000 Message-ID: <000501bfea15$d3b65d20$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <3.0.5.32.20000706083011.00926a70@pop.walltech.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Resent-Message-ID: <"jOUNJC.A.MBH.KMTa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Bruce, > -----Original Message----- > From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] > Sent: Friday, 7 July 2000 1:30 > To: Kurt D. Zeilenga > Cc: steven.legg@adacel.com.au; d.w.chadwick@salford.ac.uk; > ietf-ldapext@netscape.com > Subject: Re: String Encodings - was RE: Applicability Stmt (AS) > rescinding "IESG Note" and defining "LDAPv3" > > > At 07:42 AM 7/6/2000 -0700, Kurt D. Zeilenga wrote: > >At 12:42 PM 7/5/00 -0700, Bruce Greenblatt wrote: > >>At 11:02 AM 07/05/2000 -0700, Kurt D. Zeilenga wrote: > >>>At 11:19 AM 7/3/00 +1000, Steven Legg wrote: > >>>>It's a shame the LDAP string encodings for attribute > values weren't > defined > >>>>by some algorithmic relationship to the ASN.1 type of the > syntax, much > >>>>like the way ASN.1 value notation is related to the type. > It wouldn't > >>>>then be necessary to define a string encoding for each > new attribute > >>>>value syntax or assertion value syntax imported from > X.500, X.509, etc. > >>>>The required string encoding would fall out naturally > from the relevant > >>>>ASN.1 type. > >>>> > >>>>It's never too late to start though. > >>> > >>>You could request ;binary transfer for all attributes... :-) > >> > >>Or one could stop defining these new attribute syntaxes, > and make do with > strings... > > > >And treat attributes as blobs, sure, why not? > > > > Kurt, > > That's not what I meant at all. Sorry for the confusion. Instead of > defining a new syntax, make use of the existing syntaxes. > Here's a simple > example for the telephone number attribute. I could define a > new syntax like: > > TelephoneNumber ::= SEQUENCE { > countryCode [0] DirectoryString, > areaCode [1] DirectoryString, > localNumber [2] DirectoryString } > > for use in attribute types that need telephone numbers, or I > could just > directly use the DirectoryString syntax for these, and > indicate that they > obey the following BNF: > > telephoneNumber = countryCode whsp "$" whsp areaCode whsp "$" > whsp localNumber > ... > > IMHO, this is a better approach. I see no benefit in > defining that exact > structure of the data at the Presentation Layer. As far as > I've seen, even > when new syntaxes are defined, additional code must be > written to interpret > and validate the attribute value anyway. So, to me, it isn't > clear exactly > what purpose they serve. There is a benefit to me. The build of the Adacel View500 directory is highly automated around ASN.1 type definitions. To add a new attribute syntax I only need to paste the ASN.1 type definition into an ASN.1 source text file, add a single line of C code to an array initializer, and start a rebuild. The ASN.1 compiler and ASN.1 run-time environment take care of everything else, which includes BER + DER encoding & decoding (obviously), formatting functions for rendering attribute values in human readable form (i.e. ASN.1 value notation), parsing routines to read them back in again, hashing functions used in indexing, syntax checking routines, and integrity maintenance for any embedded DNs. The report generation and diagnostic tools automatically become capable of accessing the components of an attribute value, so a directory administrator could, for example, write a script for the data extraction utility that printed out only the ".localNumber" component of your TelephoneNumber syntax above. If the new syntax is amenable to one of the three *FirstComponentMatch matching rules (or any other implemented matching rule for that matter) then I need only add one line to another array initializer to provide matching and indexing of values of the syntax. In the case of directoryStringFirstComponentMatch this gives me access for free to a range of approximate matching (phonetic, keyword, synonym, etc) on the directory string first component. Not bad productivity from a handful of lines of text. However, I have to hand craft code to take care of the corresponding LDAP string encodings. If the string encoding was algorithmically related to the ASN.1 type then I could automate that stuff too! If there is some internal structure to an attribute syntax that makes it appropriate to define BNF to describe it then it is easier for me if that internal structure is described by ASN.1, but I'll settle for the BNF and ASN.1 being related in a predictable way. > So, use the existing ASN.1 > syntaxes, and define > the BNF as is done in clause 6 of RFC 2256... This has the > added benefit > of making the protocol easier to visually interpret by those > of us that > have to look directly at it... As an aside, a colleague of mine from Telstra recently put together an LDAPv3 client that accepts as input the ASN.1 value notation for the whole of an LDAP operation. It pushes readability to new levels. A typical LDAP search request looks like this in value notation: { messageID 1, protocolOp searchRequest:{ baseObject "O=Deltawing, C=AU", scope wholeSubtree, derefAliases neverDerefAliases, sizeLimit 50, timeLimit 100, typesOnly FALSE, filter equalityMatch:{ attributeDesc "CN", assertionValue "Andrew Sherman" }, attributes { "S" } } } Imagine if this were the actual protocol message instead of BER :-) . Strictly speaking the assertionValue field is an OCTET STRING, but our ASN.1 run-time environment accepts octet strings containing only printable characters as character strings for convenience. Regards, Steven > > Bruce > > > > > ============================================== > Bruce Greenblatt, Ph. D. > Directory Tools and Application Services, Inc. > http://www.directory-applications.com > Sign up for our LDAP Technical Overview Seminar at: > http://www.acteva.com/go/dtasi > > From list@netscape.com Sun Jul 9 23:07:39 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15267 for ; Sun, 9 Jul 2000 23:07:38 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6A2vug14367; Sun, 9 Jul 2000 19:57:56 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6A36F207653; Sun, 9 Jul 2000 20:06:15 -0700 (PDT) Resent-Date: Sun, 9 Jul 2000 20:06:15 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Rob Byrne - Sun Microsystems'" , "'Mark C Smith'" Cc: "'Kurt D. Zeilenga'" , , , "'Ed Reed'" Subject: RE: LDAP subentry alignment with X.500 subentry Date: Mon, 10 Jul 2000 13:07:22 +1000 Message-ID: <000601bfea1b$f83f0740$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <3966195F.E13E6B30@france.sun.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Resent-Message-ID: <"fpiEM.A.E3B.l2Ta5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Rob, > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Rob Byrne - Sun > Microsystems > Sent: Saturday, 8 July 2000 3:55 > To: Mark C Smith > Cc: Kurt D. Zeilenga; ietf-ldapext@netscape.com; ietf-ldup@imc.org; Ed > Reed > Subject: Re: LDAP subentry alignment with X.500 subentry > > > > Mark, > > I would say that the complexity of the X.500 style specifier > would be a barrier > to it's adoption for the LDAP access control model. > So I would say some simplified subtree specifier would be > preferable (base, > onelevel, subtree ?). Would it be acceptable to use the X.500 SubtreeSpecification but constrain it for use in LDAP ? I would rather deal with a subset of existing functionality than a separate mechanism to do the same thing. It would also provide an obvious upgrade path in future versions of LDAP by relaxing the constraints, if it proves desirable. The simple subtree specifier above would be equivalent to providing only the "minimum" or "maximum" component of a ChopSpecification, e.g. base equates to "{ maximum 0 }" onelevel equates to "{ minimum 1, maximum 1 }" or maybe "{ maximum 1 }" subtree equates to "{ }" All other fields being absent. Regards, Steven > > Even ignoring the subtree specifier there are cons associated > with putting acis > into subentries compared to just storing them as > attributes--for example you need > to control access to the subentries which, becuase subentries > do not behave like > ordinary entries, requires at least one additional aci > attribute (something like > entryACI or subEntryACI). > > Rob. > > Mark C Smith wrote: > > > > > > I primarily make these suggestions because I believe > these changes would > > > make subentries within LDAP more usable, in particular, > when used in > > > support of the access control model. > > > > Interesting. Before we throw out the simple LDAPsubentry > that Ed has > > defined, I think someone should list the additional > requirements that > > are needed for the access control effort to successfully > use subentries. > > > > -- > > Mark Smith > > iPlanet > > From list@netscape.com Sun Jul 9 23:40:02 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15827 for ; Sun, 9 Jul 2000 23:40:01 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6A3XuU07231; Sun, 9 Jul 2000 20:33:56 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6A3ccE14019; Sun, 9 Jul 2000 20:38:38 -0700 (PDT) Resent-Date: Sun, 9 Jul 2000 20:38:38 -0700 (PDT) Reply-To: From: "Steven Legg" To: Cc: Subject: RE: String Encodings - was RE: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3" Date: Mon, 10 Jul 2000 13:41:04 +1000 Message-ID: <000701bfea20$ad874640$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <3968728D.6264.5320B3B@localhost> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Resent-Message-ID: <"VU8m6.A.haD.8UUa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit David, > -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] > Sent: Sunday, 9 July 2000 21:40 > To: ietf-ldapext@netscape.com; steven.legg@adacel.com.au > Subject: Re: String Encodings - was RE: Applicability Stmt (AS) > rescinding "IESG Note" and defining "LDAPv3" > > > > > It's a shame the LDAP string encodings for attribute values weren't > > defined by some algorithmic relationship to the ASN.1 type of the > > syntax, much like the way ASN.1 value notation is related > to the type. > > It wouldn't then be necessary to define a string encoding > for each new > > attribute value syntax or assertion value syntax imported > from X.500, > > X.509, etc. The required string encoding would fall out > naturally from > > the relevant ASN.1 type. > > How right you are. I have noticed this when writing the latest > schema ID for PKIX. > > > > > It's never too late to start though. > > > > I could really do with a BNF wiz kid to help me do this on the PKIX > schema. Are you such a person? I can help you on this. I've seen more than enough BNF and ASN.1 to be useful. Let me know what you need done. Cheers, Steven > > David > > > Regards, > > Steven > > > > > > > *************************************************** > > David Chadwick > IS Institute, University of Salford, Salford M5 4WT > Tel +44 161 295 5351 Fax +44 161 745 8169 > Mobile +44 790 167 0359 > Email D.W.Chadwick@salford.ac.uk > Home Page http://www.salford.ac.uk/its024/chadwick.htm > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string MLJ9-DU5T-HV8J > > *************************************************** > > From list@netscape.com Mon Jul 10 00:59:33 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16409 for ; Mon, 10 Jul 2000 00:59:33 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6A4rPU11032; Sun, 9 Jul 2000 21:53:25 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6A4w7629601; Sun, 9 Jul 2000 21:58:07 -0700 (PDT) Resent-Date: Sun, 9 Jul 2000 21:58:07 -0700 (PDT) Message-Id: <200007100458.e6A4vwx05134@ywing.netscape.com> From: "Sonny Hadly" Subject: Our Elite Membership #6AF3 To: invite9o@ywing.netscape.com X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Sun, 09 Jul 2000 23:27:53 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"3DwdJ.A.KOH.efVa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Executive Guild Membership ApplicationResponse-O-Matic Form Dear Candidate,

You were recently selected by The Office of the Managing
Director for a free listing on The International Executive
Who's Who=2E

Our Researchers gather information from many recognized
sources, including professional associations and societies,
trade organizations, newspaper and magazine articles,
professional reference publications, web presence, and
referrals from existing members=2E

As a highly respected professional in your field of
expertise, we believe your contributions merit very
serious consideration for inclusion on The International
Executive Who's Who=2E  To maintain the highest
level of accuracy, we ask you fill out the brief bit of
information below required for inclusion=2E

There is no cost or obligation to be listed on The
International Executive Who's Who=2E
 

My Sincere Thanks,

Lorraine A=2E Michaels
Office Of Managing Director


The International Executive Who's Who is not affiliated or associated with Marquis Who's Who=2E

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E
International Executive Who's Who
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Who's Who=2E For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Who's Who=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of www=2E  Confirmation of its delivery= is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

The International Executive is not affiliated or associated with Marquis Who's Who=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From list@netscape.com Mon Jul 10 04:53:30 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00805 for ; Mon, 10 Jul 2000 04:53:29 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6A8l9U22994; Mon, 10 Jul 2000 01:47:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6A8pqc18392; Mon, 10 Jul 2000 01:51:52 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 01:51:52 -0700 (PDT) Sender: Robert.Byrne@france.Sun.COM Message-ID: <39698E86.EF4B7470@france.sun.com> Date: Mon, 10 Jul 2000 10:51:18 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: steven.legg@adacel.com.au CC: "'Mark C Smith'" , "'Kurt D. Zeilenga'" , ietf-ldapext@netscape.com, ietf-ldup@imc.org, "'Ed Reed'" Subject: Re: LDAP subentry alignment with X.500 subentry References: <000601bfea1b$f83f0740$b05508cb@osmium.adacel.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"gkLAzD.A.DfE.n6Ya5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Stephen, If we were to use subentries to store aci items then your "restriction" proposal sounds like a good approach. However, it could be argued that it would be useful to extend the X.500 subtree specifier to allow the refinement to be a generic filter (not just on the objectclass attribute). So, on the subject of a subtree specifier for LDAP, then wrt the X.500 specifier I would venture something like: drop the chops (in favour of a start point and base, onelevel and subtree) and allow the refinement to be a generic filter (not just on the objectclass). However, I would also like to see a discussion of why we should put acis into subentries rather than just store them as ldapACI attributes in entries. What are the pros and cons ? Cheers, Rob. Steven Legg wrote: > Rob, > > > -----Original Message----- > > From: owner-ietf-ldup@mail.imc.org > > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Rob Byrne - Sun > > Microsystems > > Sent: Saturday, 8 July 2000 3:55 > > To: Mark C Smith > > Cc: Kurt D. Zeilenga; ietf-ldapext@netscape.com; ietf-ldup@imc.org; Ed > > Reed > > Subject: Re: LDAP subentry alignment with X.500 subentry > > > > > > > > Mark, > > > > I would say that the complexity of the X.500 style specifier > > would be a barrier > > to it's adoption for the LDAP access control model. > > So I would say some simplified subtree specifier would be > > preferable (base, > > onelevel, subtree ?). > > Would it be acceptable to use the X.500 SubtreeSpecification but > constrain it for use in LDAP ? I would rather deal with a subset of > existing functionality than a separate mechanism to do the same thing. > It would also provide an obvious upgrade path in future versions of LDAP > by relaxing the constraints, if it proves desirable. > > The simple subtree specifier above would be equivalent to providing > only the "minimum" or "maximum" component of a ChopSpecification, e.g. > > base equates to "{ maximum 0 }" > onelevel equates to "{ minimum 1, maximum 1 }" or maybe "{ maximum 1 }" > subtree equates to "{ }" > > All other fields being absent. > > Regards, > Steven > > > > > Even ignoring the subtree specifier there are cons associated > > with putting acis > > into subentries compared to just storing them as > > attributes--for example you need > > to control access to the subentries which, becuase subentries > > do not behave like > > ordinary entries, requires at least one additional aci > > attribute (something like > > entryACI or subEntryACI). > > > > Rob. > > > > Mark C Smith wrote: > > > > > > > > > I primarily make these suggestions because I believe > > these changes would > > > > make subentries within LDAP more usable, in particular, > > when used in > > > > support of the access control model. > > > > > > Interesting. Before we throw out the simple LDAPsubentry > > that Ed has > > > defined, I think someone should list the additional > > requirements that > > > are needed for the access control effort to successfully > > use subentries. > > > > > > -- > > > Mark Smith > > > iPlanet > > > > From list@netscape.com Mon Jul 10 05:41:08 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01229 for ; Mon, 10 Jul 2000 05:41:08 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6A9VNg05704; Mon, 10 Jul 2000 02:31:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6A9TwI28846; Mon, 10 Jul 2000 02:29:58 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 02:29:58 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C4B4D8C@aspams01.cai.com> From: "Lloyd, Alan" To: Rob Byrne - Sun Microsystems , steven.legg@adacel.com.au Cc: "'Mark C Smith'" , "'Kurt D. Zeilenga'" , ietf-ldapext@netscape.com, ietf-ldup@imc.org, "'Ed Reed'" Subject: RE: LDAP subentry alignment with X.500 subentry Date: Mon, 10 Jul 2000 19:29:43 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"bexoYD.A.HCH.UeZa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com The reason for ACI in subentries is that one can support the nested directory admin model and make domain based ACI decisions over distributed (X.500) DSAs. Whereas entry level ACI - may let a user do operations on the directory using the directory resources only to find they are denied to do these at the entry level (and on millions of other entries.. ie entry level ACI is easy to implement - but a rally bad way of working in terms of system level resource protection, large scale protected distributed systems - and operationally hard to configure and manage.. ie. configuring entry level ACI for millions of entries - across many servers - at the entry level takes time ... This process is also open to having errors introduced where back door holes might be the result of misconfiguration. If one adopts admin points and rules based configuration and deals with large scale distributed directory entries - then the nested admin model is best - simply becuase it does scale and is easier to operate with rules - This approach also align with conventional management models used by business ie top down. If an entry level aci is used - one must consider the cost to configure and test, the use of directory resource before making the actual ACI decision, the hierarchy of entries, their denials and permissions and any alias derefencing... as an example - say one has a distributed directory with 250 million entries in it and one wanted to apply a new rule for a new set of users and business services - for each entry... if an entry takes even half a minute to configure.. the job will be a life time career... regards alan Stephen, snip However, I would also like to see a discussion of why we should put acis into subentries rather than just store them as ldapACI attributes in entries. What are the pros and cons ? Cheers, Rob. snip From list@netscape.com Mon Jul 10 05:56:27 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01348 for ; Mon, 10 Jul 2000 05:56:27 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6A9oIU28432; Mon, 10 Jul 2000 02:50:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6A9oac06549; Mon, 10 Jul 2000 02:50:36 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 02:50:36 -0700 (PDT) Sender: Robert.Byrne@france.Sun.COM Message-ID: <39699C32.7EB36556@france.sun.com> Date: Mon, 10 Jul 2000 11:49:38 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Lloyd, Alan" CC: steven.legg@adacel.com.au, "'Mark C Smith'" , "'Kurt D. Zeilenga'" , ietf-ldapext@netscape.com, ietf-ldup@imc.org, "'Ed Reed'" Subject: Re: LDAP subentry alignment with X.500 subentry References: <11981F9F5649D411BC92009027D0D18C4B4D8C@aspams01.cai.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"uchf7D.A.CmB.qxZa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hi Alan, Thanks for that...but I think I was not precise enough in my question. The current proposal for ldapACI does put them in entries but they come with a built in scope rule, which can be "subtree". So, I suppose my question is rather, "apart from leveraging the scoping rule of subentries what is the big plus we get from putting acis into subentries ?". Thanks, Rob. "Lloyd, Alan" wrote: > The reason for ACI in subentries is that one can support the nested > directory admin model and make domain based ACI decisions over distributed > (X.500) DSAs. Whereas entry level ACI - may let a user do operations on the > directory using the directory resources only to find they are denied to do > these at the entry level (and on millions of other entries.. ie entry level > ACI is easy to implement - but a rally bad way of working in terms of system > level resource protection, large scale protected distributed systems - and > operationally hard to configure and manage.. > > ie. configuring entry level ACI for millions of entries - across many > servers - at the entry level takes time ... This process is also open to > having errors introduced where back door holes might be the result of > misconfiguration. > > If one adopts admin points and rules based configuration and deals with > large scale distributed directory entries - then the nested admin model is > best - simply becuase it does scale and is easier to operate with rules - > This approach also align with conventional management models used by > business ie top down. If an entry level aci is used - one must consider the > cost to configure and test, the use of directory resource before making the > actual ACI decision, the hierarchy of entries, their denials and permissions > and any alias derefencing... > > as an example - say one has a distributed directory with 250 million entries > in it and one wanted to apply a new rule for a new set of users and business > services - for each entry... if an entry takes even half a minute to > configure.. the job will be a life time career... > > regards alan > > Stephen, > > snip > > However, I would also like to see a discussion of why we should put acis > into subentries rather than just store them as ldapACI attributes in > entries. What are the pros and cons ? > > Cheers, > Rob. > > snip From list@netscape.com Mon Jul 10 06:09:36 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01491 for ; Mon, 10 Jul 2000 06:09:36 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6AA3UU28992; Mon, 10 Jul 2000 03:03:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6AA8D211742; Mon, 10 Jul 2000 03:08:13 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 03:08:13 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C4B4E8D@aspams01.cai.com> From: "Lloyd, Alan" To: Rob Byrne - Sun Microsystems Cc: steven.legg@adacel.com.au, "'Mark C Smith'" , "'Kurt D. Zeilenga'" , ietf-ldapext@netscape.com, ietf-ldup@imc.org, "'Ed Reed'" Subject: RE: LDAP subentry alignment with X.500 subentry Date: Mon, 10 Jul 2000 20:08:01 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"WfsKgD.A.H3C.LCaa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com No worries - but the real issue to me is an administrative plane in a directory for schema, collectives, security, aci, etc means that these entries can be partitioned into their own regime - in that there is administrative security applied to these entries and they get named seperately from the "user entry plane"..ie does the ACI on ORG x get its ACI properties from a management plane of named entries (which have their own ACI regime - distinct from the user ACI regime ) or are they coupled because it all exists as one compound entry. There are five aspects to ACI..that is coupled to the User authentication process.. these are The Operation The Name Space The Object Class of the entry The attribute type/value within OC/entry and the Time the operation is allowed. Given that very strong ACI code (in terms of vetting) can be applied to the directory operation and name space of the entry and its OC. Having named subentries for management is a much more trustworthy approach than compound OCs that exist under a User "named" DIT. In addition if entries are renamed becuase of business, service and user changes, it may means the ACI management model has to be recalculated re its security. Whereas the named entry for management - admin model is still the ACI and schema reference point in the directory. Naturally this discussion can be lengthy - but one area that one looks at in military security - is "seperation of duty" - and how operations that change one thing affect others.. An explicit "named" management and security information model with its own privileges and ACI - to me is much better than a compound one - that can be accidentally affected by such things a user information name changes.. I hope this "helps".. regards alan -----Original Message----- From: Rob Byrne - Sun Microsystems [mailto:Robert.Byrne@france.sun.com] Sent: Monday, July 10, 2000 7:50 PM To: Lloyd, Alan Cc: steven.legg@adacel.com.au; 'Mark C Smith'; 'Kurt D. Zeilenga'; ietf-ldapext@netscape.com; ietf-ldup@imc.org; 'Ed Reed' Subject: Re: LDAP subentry alignment with X.500 subentry Hi Alan, Thanks for that...but I think I was not precise enough in my question. The current proposal for ldapACI does put them in entries but they come with a built in scope rule, which can be "subtree". So, I suppose my question is rather, "apart from leveraging the scoping rule of subentries what is the big plus we get from putting acis into subentries ?". Thanks, Rob. "Lloyd, Alan" wrote: > The reason for ACI in subentries is that one can support the nested > directory admin model and make domain based ACI decisions over distributed > (X.500) DSAs. Whereas entry level ACI - may let a user do operations on the > directory using the directory resources only to find they are denied to do > these at the entry level (and on millions of other entries.. ie entry level > ACI is easy to implement - but a rally bad way of working in terms of system > level resource protection, large scale protected distributed systems - and > operationally hard to configure and manage.. > > ie. configuring entry level ACI for millions of entries - across many > servers - at the entry level takes time ... This process is also open to > having errors introduced where back door holes might be the result of > misconfiguration. > > If one adopts admin points and rules based configuration and deals with > large scale distributed directory entries - then the nested admin model is > best - simply becuase it does scale and is easier to operate with rules - > This approach also align with conventional management models used by > business ie top down. If an entry level aci is used - one must consider the > cost to configure and test, the use of directory resource before making the > actual ACI decision, the hierarchy of entries, their denials and permissions > and any alias derefencing... > > as an example - say one has a distributed directory with 250 million entries > in it and one wanted to apply a new rule for a new set of users and business > services - for each entry... if an entry takes even half a minute to > configure.. the job will be a life time career... > > regards alan > > Stephen, > > snip > > However, I would also like to see a discussion of why we should put acis > into subentries rather than just store them as ldapACI attributes in > entries. What are the pros and cons ? > > Cheers, > Rob. > > snip From list@netscape.com Mon Jul 10 06:32:17 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02042 for ; Mon, 10 Jul 2000 06:32:16 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6AAMUg09481; Mon, 10 Jul 2000 03:22:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6AAUnE16728; Mon, 10 Jul 2000 03:30:49 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 03:30:49 -0700 (PDT) Message-Id: <200007101030.GAA01771@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldap-grouping-00.txt Date: Mon, 10 Jul 2000 06:30:42 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"4nKMsB.A.hEE.WXaa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAPv3: Grouping of Related Operations Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-grouping-00.txt Pages : 9 Date : 07-Jul-00 This document provides a general mechanisms for grouping related LDAP operations. Grouping of operations may be used to support replication, proxies, and higher level operations such as transactions. This document describes a set of LDAP [RFC2251] extended operations and other protocol and schema elements to support grouping of related operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-grouping-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-grouping-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-grouping-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000707143247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-grouping-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-grouping-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000707143247.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Mon Jul 10 06:33:41 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02294 for ; Mon, 10 Jul 2000 06:33:40 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6AANpg10193; Mon, 10 Jul 2000 03:23:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6AAWAs18212; Mon, 10 Jul 2000 03:32:10 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 03:32:10 -0700 (PDT) Message-Id: <200007101032.GAA02016@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldap-namedref-00.txt Date: Mon, 10 Jul 2000 06:32:04 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"YJlDBB.A.McE.nYaa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Named References in LDAP Directories Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-namedref-00.txt Pages : 12 Date : 07-Jul-00 This document defines schema and protocol elements for representing and manipulating generic knowledge information in LDAP [RFC2251] directories. An attribute type 'ref' is used to store URIs [RFC1738] which may refer to LDAP and non-LDAP services. An object class 'referral' is used to construct entries in an LDAP directory which references to other directories or services. An control, ManageDsaIT, is defined to allow clients to manipulate referral objects as normal entries. The document describes procedures directory servers should follow when supporting these elements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-namedref-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-namedref-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-namedref-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000707143530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-namedref-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-namedref-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000707143530.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Mon Jul 10 06:34:41 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02403 for ; Mon, 10 Jul 2000 06:34:40 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6AARaU01501; Mon, 10 Jul 2000 03:27:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6AAWIU18332; Mon, 10 Jul 2000 03:32:18 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 03:32:18 -0700 (PDT) Message-Id: <200007101032.GAA02030@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldap-root-01.txt Date: Mon, 10 Jul 2000 06:32:10 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"zE-bkC.A.qdE.tYaa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OpenLDAP Root Service An experimental LDAP referral service Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-root-01.txt Pages : 11 Date : 07-Jul-00 The OpenLDAP Project is operating an experimental LDAP [RFC2251] referral service known as the 'OpenLDAP Root Service.' The automated system generates referrals based upon service location information published in DNS [RFC1034] SRV [RFC2782] resource records. This document describes this service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-root-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-root-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-root-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000707143543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-root-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-root-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000707143543.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Mon Jul 10 06:34:42 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02413 for ; Mon, 10 Jul 2000 06:34:42 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6AAPxU00646; Mon, 10 Jul 2000 03:26:00 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6AAUgY16612; Mon, 10 Jul 2000 03:30:42 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 03:30:42 -0700 (PDT) Message-Id: <200007101030.GAA01757@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldap-passwd-exop-04.txt Date: Mon, 10 Jul 2000 06:30:36 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"kLUrlC.A.PDE.QXaa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP Password Modify Extended Operation Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-passwd-exop-04.txt Pages : 6 Date : 07-Jul-00 The integration of LDAP [RFC2251] and external authentication services has introduced non-DN authentication identities and allowed for non-directory storage of passwords. As such, mechanisms which update the directory, such as Modify operation, cannot be used to change a user's password. This document describes an LDAP extended operation to allow allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-passwd-exop-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-passwd-exop-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-passwd-exop-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000707143234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-passwd-exop-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-passwd-exop-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000707143234.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Mon Jul 10 10:44:32 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11062 for ; Mon, 10 Jul 2000 10:44:31 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6AEXgg25180; Mon, 10 Jul 2000 07:33:42 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6AEg1I16626; Mon, 10 Jul 2000 07:42:01 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 07:42:01 -0700 (PDT) Date: Mon, 10 Jul 2000 07:41:30 -0700 (PDT) Message-Id: <200007101441.e6AEfT713393@xwing.netscape.com> From: free_cigs@yahoo.com To: @netscape.com Subject: "CHAIN-LETTER" It's Legal..Make A TON OF CASH ! ! ! Also..FREE Cigarettes ! ! X-Reply-To: free_cigs@yahoo.com Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"gEoOwB.A.ZDE.3Cea5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit

CHAIN-LETTER It's Legal, It Works, It's EASY ! ! !

EVERY0NE ON THIS LIST GETS PAID EVERY TIME !!! Invest $15 and get your name on the list, you will not regret it ! ($5 to each person)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Parents of 15 yr.old Find $71,000 cash hidden in his closet.

CASH JUST KEEPS COMING IN MY MAIL"! !

Dear Friend,

It Works, Its Legal, Its Easy, so Why Not?

Parents of 15-year-old find $71,000 cash hidden in his closet.

Does this headline look familiar?Of course it does.You most likely have just seen this story recently featured on a major nightly news program (USA).

His mother was cleaning and putting laundry away when she came across a large brown paper bag that was suspiciously buried beneath some clothes and a skateboard in the back of her 15-year-old sons closet.Nothing could have prepared her for the shock she got when she opened the bag and found it was full of cash.Five-dollar bills, twenties, fifties and hundreds - all neatly rubber-banded in labeled piles.

"My first thought was that he had robbed a bank", says the 41-year-old woman, "There was over $71,000 dollars in that bag -- thats more than my husband earns in a year".

The woman immediately called her husband at the car-dealership where he worked to tell him what she had discovered.He came home right away and they drove together to the boys school and picked him up.Little did they suspect that where the money came from was more shocking than actually finding it in the closet.

As it turns out, the boy had been sending out, via E-mail, a type of "chain-letter" to E-mail addresses that he obtained off of the Internet.Everyday after school for the past 2 months, he had been doing this right on his computer in his bedroom.

"I just got the E-mail one day and I figured what the heck, I put my name on it like the instructions said and I started sending it out", says the clever 15-year-old.

The E-mail letter listed 3 addresses and contained instructions to send one $5 dollar bill to each person on the list, then delete the address at the top and move the other 2 addresses up, and finally to add your name to the bottom oflist.

The letter goes on to state that you would receive several thousand dollars in five-dollar bills within 2 weeks if you sent out the letter with your name at the bottom of the 3-address list. "I get junk E-mail all the time, andreally did not think it was going to work", the boy continues.

Within the first few days of sending out the E-mail, the Post Office Box that his parents had gotten him for his video-game magazine subscriptions began to fill up with not magazines, but envelopes containing $5 bills.

"About a week later I rode [my bike] down to the post office and my box had 1 magazine and about 300 envelops stuffed in it. There was also a yellow slip that said I had to go up to the [post office] counter. I thought I was in trouble or something (laughs)". He goes on, "I went up to the counter and they had a whole box of more mail for me.I had to ride back home and empty out my backpack because I could not carry it all".

Over the next few weeks, the boy continued sending out the E-mail."The money just kept coming in and I just kept sorting it and stashing it in the closet,barely had time for my homework".He had also been riding his bike to several of the banks in his area and exchanging the $5 bills for twenties, fifties and hundreds.

"I didnt want the banks to get suspicious so I kept riding to different banks with like five thousand at a time in my backpack. I would usually tell the lady at the bank counter that my dad had sent me in [to exchange the money] and he was outside waiting for me.One time the lady gave me a really strange look and told me that she would not be able to do it for me and my dad would have to come in and do it, but I just rode to the next bank down the street (laughs)."

Surprisingly, the boy did not have any reason to be afraid.The reporting news team examined and investigated the so-called "chain-letter" the boy was sending out and found that it was not a chain-letter at all.In fact, it was completely legal according to US Postal and Lottery Laws, Title 18, Section 1302 and 1341, or Title 18, Section 3005 in the US code, also in the code of federal regulations, Volume 16, Sections 255 and 436, which state a product or service must be exchanged for money received.

Every five-dollar bill that he received contained a little note that read, "Please add me to your mailing list".This simple note made the letter legal because he was exchanging a service (adding the purchasers name to his mailing list) for a five-dollar fee.

Here is the letter that the 15-year-old was sending out by E-mail, you can do the exact same thing he was doing, simply by following the instructions in this letter.

--------------------------------------------

Here are instructions on how to make $10,000 US cash in the next 2 weeks:

There are 3 addresses listed below.

Send each person on the list a $5 bill wrapped in 2 pieces of paper (to securely hide it), along with a note that says: "Please add me to your mailing list".

Then delete the name at the top, move the other 2 up and put your name at the bottom.

Now start sending this ENTIRE e-mail back out to people.When 20 people receive it, those 20 people will move your name up to the middle position and they will each send out 20.That totals 400 people that will receive this letter with your name in the middle.

Then, those 400 people will move your name up to the top and they will each send out 20 E-mails.That totals 8,000 people that will receive this E-mail with your name on it and they will each send you a $5 bill

.

8,000 people each sending you a $5 bill = $40,000 cash.Thats if everyone responds to this E-mail, but not everyone will, so you can expect more realistically to receive about $10,000 cash $5 bills in your mailbox.

This will work for anyone, anywhere in the world in any country, but send only US CASH $5 bill.

The more E-mails you send out, the more cash you will receive.If each person sends out 100 E-mails, there will be 1,000,000 people that receive this letter with your name on it. If only 1% of those people respond, you will still get $50,000 cash.

Here is the list:

--------------------------------------------

1 Jenny Gariss

7119 196th St SW

Lynnwood,Wa. 98036

2 Margaret Vines

9792 Edmonds Way

# 218

Edmonds, Wash. 98020

3 Ken Derricott

13619 Mukilteo Speedway

Suite D-5 #142

Lynnwood, Wa. 98037-1606

---------------------------------------------

THERES NOTHING MORE TO DO. When you start sending this out within a few days, you will start receiving $5 bills from other people just like yourself, who are willing to invest three $5 bills to receive $10,000 cash.

EVERYONE on this list gets Paid EVERY TIME…invest $15 & get your name on the list, you will not regret it !

If you dont try it- you will never know.

=============================================

{BELOW ARE MORE LUCRATIVE OPPORTUNITIES}

*************************************************************************************

Another Great CHAIN-LETTER…$6 will bring you A TON OF CASH ! ! !

Send a blank email to: CHAIN_CASH@themail.com

*******************************************************************************************************

*******************************************************

FREE ADVERTISING

********************************************************

FOR LOTS OF FREE CLASSIFIED ADVERTISING

GO TO: http://www.homestead.com/good1395cigs/freecigarettes.html

*****************************************************

FREE $20 BILLS

*****************************************************

EVERYONE-who signs up SENDS YOU $20 CASH, 100s of people a day!!!

Plus FREE Advertising to MILLIONS!! CHECK THIS OUT...You will be GLAD you did!

http://www.magic-nj.com/office/suite17601.shtml

********************************************************

FREE CIGARETTES

********************************************************

Quality CIGARETTES $13.95 per carton, FREE Samples!! Make BIG MONEY!!!

GROUND FLOOR OPPORTUNITY!

http://www.homestead.com/good1395cigs/freecigarettes.html

You are getting this email because we are members of the same list.

**************************************************************************************************** You are Receiving this because we have corresponded in the past, or you have recently sent me an offer for your business.

message is sent in compliance of the new email bill section 301.Per Section 301 Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you by replying to goodcigs@mail.comPlease type "Remove" in the subject line.

Your request to be removed will be processed within 24 hours. DISCLAIMER: Under Bill s.1618 TITLE III passed by the 105th US Congress this letter Cannot be considered Spam as long as the sender includes contact information & a method of removal.To be removed from future mailings just reply withREMOVE in thesubject line.Thank you for your kind consideration. From list@netscape.com Mon Jul 10 20:06:30 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02223 for ; Mon, 10 Jul 2000 20:06:30 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6ANx3U03332; Mon, 10 Jul 2000 16:59:04 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6B03lc21570; Mon, 10 Jul 2000 17:03:47 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 17:03:47 -0700 (PDT) Date: Mon, 10 Jul 2000 17:03:37 -0700 (PDT) From: Opportunity To: Message-Id: <419.436717.71080197Opp@teamhealthnetwork.com> Subject: A True Ground Floor Opportunity Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"5HvglC.A.JQF.gRma5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit A True Ground Floor Opportunity: Extraordinary Opportunity For: Experienced, Hard Working Networking Professionals http://64.225.82.202/thn .10 Generation Payout .Exciting Jump Start Bonus ..You Can Never Lose You Position ...Up To 25% Personal Rebate Vist This Link: http://64.225.82.202/thn For A Free Business Package. http://64.225.82.202/thn (REMOVAL INSTRUCTIONS) We respect your online privacy and apologize if you have received this message in error. If you would like to be removed from our mailing list just click on the link below. SUBSCRIBE OR UNSUBSCRIBE TO OUR MAILING LIST: http://64.225.82.202/elist From list@netscape.com Mon Jul 10 21:16:04 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02939 for ; Mon, 10 Jul 2000 21:16:03 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6B19FU11941; Mon, 10 Jul 2000 18:09:15 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6B1Dws19385; Mon, 10 Jul 2000 18:13:58 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 18:13:58 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C4D5AFD@aspams01.cai.com> From: "Ramsay, Ron" To: Rob Byrne - Sun Microsystems Cc: ietf-ldapext@netscape.com Subject: RE: LDAP subentry alignment with X.500 subentry Date: Tue, 11 Jul 2000 11:13:42 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"DgQd4C.A.auE.UTna5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Rob, I can so no purpose either for a general filter in a subentry of for scopes in entry ACI. The problem with the former is that, if the filter relates to telephoneNumber, for example, and the user deletes this attribute from his entry, the ACI may now behave unpredictably. The problem with scope in entry ACI is that, when searching below a scoped entry, how do you determine the applicable ACI. Read all superior entries? Since you asked for pros and cons, another aspect of entry ACI that is suboptimal is the cost of applying it. Everyone seems to assume it is free and yet it has a significant impact on server performance (no figures, sorry). For example, suppose subtree A contains 10000 entries, 9000 of which are in subtree B under A. Suppose user X is not authorised to access B. Because of entry ACI, a search by X of the subtree A will result in all 10000 entries being read for their ACI, whereas the use of prescriptive (subentry) ACI will mean that at most 1000 entries will be accessed. Ron. -----Original Message----- From: Rob Byrne - Sun Microsystems [mailto:Robert.Byrne@france.Sun.COM] Sent: Monday, 10 July 2000 19:50 To: Lloyd, Alan Cc: steven.legg@adacel.com.au; 'Mark C Smith'; 'Kurt D. Zeilenga'; ietf-ldapext@netscape.com; ietf-ldup@imc.org; 'Ed Reed' Subject: Re: LDAP subentry alignment with X.500 subentry Hi Alan, Thanks for that...but I think I was not precise enough in my question. The current proposal for ldapACI does put them in entries but they come with a built in scope rule, which can be "subtree". So, I suppose my question is rather, "apart from leveraging the scoping rule of subentries what is the big plus we get from putting acis into subentries ?". Thanks, Rob. "Lloyd, Alan" wrote: > The reason for ACI in subentries is that one can support the nested > directory admin model and make domain based ACI decisions over distributed > (X.500) DSAs. Whereas entry level ACI - may let a user do operations on the > directory using the directory resources only to find they are denied to do > these at the entry level (and on millions of other entries.. ie entry level > ACI is easy to implement - but a rally bad way of working in terms of system > level resource protection, large scale protected distributed systems - and > operationally hard to configure and manage.. > > ie. configuring entry level ACI for millions of entries - across many > servers - at the entry level takes time ... This process is also open to > having errors introduced where back door holes might be the result of > misconfiguration. > > If one adopts admin points and rules based configuration and deals with > large scale distributed directory entries - then the nested admin model is > best - simply becuase it does scale and is easier to operate with rules - > This approach also align with conventional management models used by > business ie top down. If an entry level aci is used - one must consider the > cost to configure and test, the use of directory resource before making the > actual ACI decision, the hierarchy of entries, their denials and permissions > and any alias derefencing... > > as an example - say one has a distributed directory with 250 million entries > in it and one wanted to apply a new rule for a new set of users and business > services - for each entry... if an entry takes even half a minute to > configure.. the job will be a life time career... > > regards alan > > Stephen, > > snip > > However, I would also like to see a discussion of why we should put acis > into subentries rather than just store them as ldapACI attributes in > entries. What are the pros and cons ? > > Cheers, > Rob. > > snip From list@netscape.com Tue Jul 11 01:58:44 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14023 for ; Tue, 11 Jul 2000 01:58:44 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6B5mGg07030; Mon, 10 Jul 2000 22:48:16 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6B5ua616692; Mon, 10 Jul 2000 22:56:36 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 22:56:36 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C4FC6B6@aspams01.cai.com> From: "Lloyd, Alan" To: "Ramsay, Ron" , Rob Byrne - Sun Microsystems Cc: ietf-ldapext@netscape.com Subject: RE: LDAP subentry alignment with X.500 subentry Date: Tue, 11 Jul 2000 15:56:26 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"Ao08iC.A.fEE.Scra5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com In addition to Ron's input - which is always spot on .. With this issue one has to step back and look at the major issue with LDAP servers and their lack of distribution - that X.500 already has. When machines do diffrent things, (eg LDAP servers vs distributed X.500), their management and control architecture will also be different. Certainly when one gets into distributed system management, knowledge engineering and security systems - the management will be very different to that of a single client-server system . As per my last mail re separation of duty - and dedicated control planes (as per X.500 DSE types, admin and subentry named - ACIand schema objects/object classes, etc) - If one has a clear management and control model of distributed directory space - that deals with schema management, Authentication levels - tied to ACI regimes, Collective Attributes, Contexts (time/language), Labels (MLS military security), etc (as per X.500).. then one can engineer these control planes as distributed, nested administration points - and write the processing for these as quite distinct processes from the code that services the normal user access to directory entries - which of course must be policed by the control regimes. Whereas with no control plane agenda or model - and the use of compound entries, this could lead to all sorts of operational weaknesses (as Ron describes) and the possible inclusion of weak fragile security and management code. When a user binds to a directory with none, simple, strong authentication that the ACI processing is latched to. Ho do you vet the processing is clean and trusted comensurate to the authentication level demanded if it is scattered through out the User plane processing. In addition - and probably this is the main distinction between LDAP servers and distributed X.500 with its distinct Admin area management system - is that these dedicated management objects for ACI/schema control, etc, can be (and must be)propagated to subordinate directory systems more cleanly than filtering partial replicas of user entries - which can be under all sorts of dynamics. This obviously means that the hierarchy of management control and its security is effected across the distributed system in a much more trusted (separated) way. With the Search issues like Ron describes - as well as embedded attributes for management control in normal entries - how would one enforce such a random control process - eg upwards, sidewards and downwards? and dont forget alias issues ! With the X.500 admin point and dedicated ACI and schema type objects the governance its always downwards - and "always" means it can be built in trust worthy way. It can be designed to be "predictive" and any resulting pre processing of ACI when ACI or schema control is changed, can be propagated across a distributed system - consistently and effectively.. My issue with - and always has been with non distributed LDAP servers - where one must replicate everything to everywhere - and there is no distribution and no distributed coherent control plane management model - does mean that any operational security is bound to be weak and fragile.. When one sees a distrubuted directory service to underpin a global organisation's business infrastructure with PKI, OCSP, DEN, DNS, User authentication regimes, white, blue, green, yellow pages services, catalogues - 10s - 100s of millions of role based users - and the need to support a predictable, high capacity, distributed authentication/ACI model (to protect the directory service), the X.500 Admin model and subentry ACI with profiled rules - wins out. And when you apply this fundamental processing things to a system do slow down a little compared to those servers that dont apply ACI or are just a single server. And its a pitty that ACI and information integrity testing does not get incuded in some directory test reports we see.. There is a danger in discussing ACI models that by saying X.500 does this and LDAP servers do that.. that the LDAP server ACI approach will firmly concrete the role of an LDAP server to be nothing more that a single non scaleable single ACI regime system. The basics of X.500's nested admin points, DSEs, knowledge and control planes - is that it works for a single DSA or as a distributed system - in a way that it can be built - and trusted. In discussing this re an ACI attribute or an Admin/Subentry ACI, etc - one must look at the system model and its distribution requirements and the ability to do predictable govenance. regards alan -----Original Message----- From: Ramsay, Ron Sent: Tuesday, July 11, 2000 11:14 AM To: Rob Byrne - Sun Microsystems Cc: ietf-ldapext@netscape.com Subject: RE: LDAP subentry alignment with X.500 subentry Rob, I can so no purpose either for a general filter in a subentry of for scopes in entry ACI. The problem with the former is that, if the filter relates to telephoneNumber, for example, and the user deletes this attribute from his entry, the ACI may now behave unpredictably. The problem with scope in entry ACI is that, when searching below a scoped entry, how do you determine the applicable ACI. Read all superior entries? Since you asked for pros and cons, another aspect of entry ACI that is suboptimal is the cost of applying it. Everyone seems to assume it is free and yet it has a significant impact on server performance (no figures, sorry). For example, suppose subtree A contains 10000 entries, 9000 of which are in subtree B under A. Suppose user X is not authorised to access B. Because of entry ACI, a search by X of the subtree A will result in all 10000 entries being read for their ACI, whereas the use of prescriptive (subentry) ACI will mean that at most 1000 entries will be accessed. Ron. -----Original Message----- From: Rob Byrne - Sun Microsystems [mailto:Robert.Byrne@france.Sun.COM] Sent: Monday, 10 July 2000 19:50 To: Lloyd, Alan Cc: steven.legg@adacel.com.au; 'Mark C Smith'; 'Kurt D. Zeilenga'; ietf-ldapext@netscape.com; ietf-ldup@imc.org; 'Ed Reed' Subject: Re: LDAP subentry alignment with X.500 subentry Hi Alan, Thanks for that...but I think I was not precise enough in my question. The current proposal for ldapACI does put them in entries but they come with a built in scope rule, which can be "subtree". So, I suppose my question is rather, "apart from leveraging the scoping rule of subentries what is the big plus we get from putting acis into subentries ?". Thanks, Rob. "Lloyd, Alan" wrote: > The reason for ACI in subentries is that one can support the nested > directory admin model and make domain based ACI decisions over distributed > (X.500) DSAs. Whereas entry level ACI - may let a user do operations on the > directory using the directory resources only to find they are denied to do > these at the entry level (and on millions of other entries.. ie entry level > ACI is easy to implement - but a rally bad way of working in terms of system > level resource protection, large scale protected distributed systems - and > operationally hard to configure and manage.. > > ie. configuring entry level ACI for millions of entries - across many > servers - at the entry level takes time ... This process is also open to > having errors introduced where back door holes might be the result of > misconfiguration. > > If one adopts admin points and rules based configuration and deals with > large scale distributed directory entries - then the nested admin model is > best - simply becuase it does scale and is easier to operate with rules - > This approach also align with conventional management models used by > business ie top down. If an entry level aci is used - one must consider the > cost to configure and test, the use of directory resource before making the > actual ACI decision, the hierarchy of entries, their denials and permissions > and any alias derefencing... > > as an example - say one has a distributed directory with 250 million entries > in it and one wanted to apply a new rule for a new set of users and business > services - for each entry... if an entry takes even half a minute to > configure.. the job will be a life time career... > > regards alan > > Stephen, > > snip > > However, I would also like to see a discussion of why we should put acis > into subentries rather than just store them as ldapACI attributes in > entries. What are the pros and cons ? > > Cheers, > Rob. > > snip From list@netscape.com Tue Jul 11 02:27:30 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21116 for ; Tue, 11 Jul 2000 02:27:29 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6B6HIg08855; Mon, 10 Jul 2000 23:17:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6B6PdA22734; Mon, 10 Jul 2000 23:25:39 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 23:25:39 -0700 (PDT) Date: Mon, 10 Jul 2000 23:25:32 -0700 (PDT) Message-Id: <200007110625.e6B6PU711189@xwing.netscape.com> From: Your.Personal.Mentor@xwing.netscape.com, "Nezy " To: ietf-ldapext@DIES.netscape.com Subject: A GENUINE BUSINESS OPPORTUNITY - NO BULL, NO HYPE! -LUWK X-Reply-To: nezy@speedlink.com.au Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FCln4C.A.qiF.h3ra5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hello ietf-ldapext Your email address was given to me as someone who was interested in business opportunities, if your details were submitted in error, may I apologise for the intrusion, rest assured this is a one of mailing. If you are interested, please feel free to continue, you won't be sorry. Good luck in your endeavours. Regards, Nezy. ****************************************************************************************************************************** STAY HOME & WORK ONLINE Earn $500-$5000 per month working from home in your spare time. Easy step by step duplicatable system for E-Commerce Personal mentor training provided Online automated program ensures excellent income and growth FREE E-book: http://onlinehomebusiness.cjb.net ***************************************************************************************************************************** From list@netscape.com Tue Jul 11 02:39:03 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21219 for ; Tue, 11 Jul 2000 02:39:02 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6B6WtU02712; Mon, 10 Jul 2000 23:32:56 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6B6bd225442; Mon, 10 Jul 2000 23:37:39 -0700 (PDT) Resent-Date: Mon, 10 Jul 2000 23:37:39 -0700 (PDT) X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Rob Byrne - Sun Microsystems'" , Cc: "'Mark C Smith'" , "'Kurt D. Zeilenga'" , , , "'Ed Reed'" Subject: RE: LDAP subentry alignment with X.500 subentry Date: Tue, 11 Jul 2000 16:37:04 +1000 Message-ID: <000601bfeb02$6e45e6c0$17448490@vic.bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <39698E86.EF4B7470@france.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Resent-Message-ID: <"yxUl4C.A.JNG.xCsa5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit [RB] Stephen, If we were to use subentries to store aci items then your "restriction" proposal sounds like a good approach. However, it could be argued that it would be useful to extend the X.500 subtree specifier to allow the refinement to be a generic filter (not just on the objectclass attribute). So, on the subject of a subtree specifier for LDAP, then wrt the X.500 specifier I would venture something like: drop the chops (in favour of a start point and base, onelevel and subtree) and allow the refinement to be a generic filter (not just on the objectclass). However, I would also like to see a discussion of why we should put acis into subentries rather than just store them as ldapACI attributes in entries. What are the pros and cons ? Cheers, Rob. [AL] Extending X.500 subtree specifier to allow a generic filter (not just on objectclass attribute) would be a bad idea, for reasons explained below. I agree with Steve's proposal to use a subset of X.500, not a superset. This subset should be the minimum necessary to support replication subentries (which isn't much), but using the generic standard so that implementors needing more (eg for ACI) don't have to duplicate effort. First, apologies to all, and especially to Steve, for long delay responding to Steve's careful response re MDCR etc. Will be replying in detail but had to put it aside and will still have to do so for at least another week due to other priorities. (Got an excuse though, also waiting for authors reply re requirements ;-) Meanwhile, a quick point re this thread, as I can write about ACI and subentries from off the top of my head, whereas multi-master replication is HARD. From above and other messages I suspect there may be some talking at cross purposes re implementation issues vs protocol issues. X.500 style subentries with chop sepecifications (by minimum and maximum depth, plus named lower boundaries, plus arbitrary boolean filters on object class only, can be implemented either by logic applied to traversal of the path from the (administrative point of) the subentry or by logic applied to COPIES of the subentry aci physically stored with the affected entry aci as part of the entry. Both implementation methods can conform to the same protocol standards that separate the administration of entry aci from the administration of subentry aci. The second method has all the administrative advantages mentioned by Alan, because the subentry aci stored within an entry is administered from the subentry point, independently of the entry aci. But it provides much greater efficiency for read dominated directories at the expense of slower application of changes to subentry aci (which are relatively infrequent). eg Active Directory uses inheritance (from Admin points, not true named subentries) to propagate the admin point aci downwards from the minimum depth of the chop spec (limited to 0 or 1), to the maximum depth (limited to 0, 1 or infinite) with limited specification of object classes. Whenever the inherited aci is changed, a write has to be made to EVERY affected entry, which can be very slow for changes applied from high up, but the whole idea of delegation is that such changes should be infrequent. This is effectively the same as "base, one level and subtree" but with the important addition of "below one level only". That enables the vitally important specification of ACI that does not become effective until propagated BELOW the point of application - effectively allowing a form of unaffected subentries even when applied from an admin point (because subentries have their own object class). The mechanism used in Active Directory simply uses a bit to specify whether inherited aci is "inherit only", in which case it is "dead" at the entry but becomes "live" when copied to entries below. By changing this to an integer instead of a bit you would get a chop min. Likewise a "don't propagate" bit cuts off further copying for inheritance below. Changing that to an integer would give a chop max. There is no reason why the same general "inheritance by copy" approach could not be used for true named subentry ACI (calculating inheritance from the base instead of the subentry, even though the specification is named by the subentry). Also the Active Directory limitation on chop specs and object class filters seems related to transition from historical* NT/DCE security descriptors rather than any inherent limitation in this model. (* Your spelling of "historical" may vary, however the use of admin points instead of named subentries can only be spelled one way, "hysterical"). The first method also has all the administrative advantages mentioned by Alan, is simpler to implement and allows much faster changes since a change only has to be written once, where it is physically stored only at the subentry (or admin point). However it slows down reads and writes and especially searches to the affected entries themselves and is therefore in my view precisely the wrong optimization for directories. (Except where there is so little delegation that all the non-entry ACI can be kept in RAM anyway, as with many LDAP servers based on the U Michigan release with highly centralized administration, even editing config files to change ACI). It is also very intertwined with the naming structure. A regexp on naming path for access control in a search would severely complicate the use of aliases. That is why X.500 specifies ACI controls based on the unique primary distinguished name of an entry, not on path names. LDAP standards must not unnecessarily limit implementation choices. Filter specifications on object classes work with either model, since every entry knows its object classes and can easily calculate an arbitrary filter on them quickly when determining visibility during searches. General filters really only work with a traversal based implementation and are basically just an attempt to substitute regexp evaluation on path names familiar to centralized web administrators for a serious admin model that can actually be delegated. The apparant additional flexibility is illusory since it doesn't scale with real delegation, whereas the combination of min and max depth, base, named lower bounds and object class filters does allow for adequate delegation of directory access control domains independently of the naming structure. Independence from the naming structure is essential for scalable delegation. This is also relevant to replication management issues when we move beyond current scope and need to support opportunistic delegated replication agreements for subsets of a replicated area, as mentioned in Alison's contribution. Most of this thread is more related to LDAP ACI extensions than to replication. However the mechanism used for replication subentries should be consistent with that used for any other purpose and should therefore be a subset, not a superset. Also, the generalization of subentries to families of related entries is very relevant to dealing with atomicity and replication granularity issues. As mentioned in MDCR attributes that need to be changeable independently and concurrently at multiple replicas can be in separate subentries or child entries of a parent family entry. Any such generalization of subentries need only rely on object classes. Most importantly, the multi-master replication of subentries MUST have sufficient consistency properties to support their use for ACI. If the replication mechanism is so broken that one has to rely on per replica subentries to administer it, I don't see how it could possibly support replicated access controls of any useful kind at all. This was also mentioned in MDCR: http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt From list@netscape.com Tue Jul 11 04:58:46 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22476 for ; Tue, 11 Jul 2000 04:58:46 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6B8n2g18167; Tue, 11 Jul 2000 01:49:02 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6B8vMY26262; Tue, 11 Jul 2000 01:57:22 -0700 (PDT) Resent-Date: Tue, 11 Jul 2000 01:57:22 -0700 (PDT) Message-ID: <06bf01bfeb8d$649ba020$3029b0cb@w3l8s9> To: From: "Your Way To Global Success" Subject: MAKE CASH DAILY Date: Tue, 11 Jul 2000 02:55:17 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06BC_01BFEB52.B83CC820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Resent-Message-ID: <"kd5q.A.AaG.xFua5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multi-part message in MIME format. ------=_NextPart_000_06BC_01BFEB52.B83CC820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, MAKE YOUR COMPUTER YOUR PERSONAL ATM MACHINE! =20 You only need a few minutes to do this. Start Now!=20 NOW, you can make $50 an hour through your computer. Newbies, = Professionals, anybody who has the desire can do this. It's so simple. = You can even start earning right now. YES RIGHT NOW! It will only take = you 40 minutes to set-up. START NOW! Just simply reply to this e-mail with Send More Info as the text and = we'll show you how simple it is. Thank you very much. BONG =20 * * * * * * * * * * * * * * * * * * * * * * * * = * * * * =20 If you wish to be remove from our list, just reply to this e-mail with = Remove as the text and we will removed you immediately. We honor remove = requests religiously. ------=_NextPart_000_06BC_01BFEB52.B83CC820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 
Hello,
 
MAKE YOUR COMPUTER YOUR PERSONAL ATM=20 MACHINE!
 
You only need a few minutes to do this. = Start Now!=20
 
NOW, you can make $50 an hour through your=20 computer. Newbies, Professionals, anybody = who has=20 the desire can do this. It's so simple. You can even start earning = right now. YES RIGHT NOW! It will only take you 40 minutes = to set-up.=20 START NOW!
 
Just simply reply to this e-mail with = Send More=20 Info as the text and we'll show you how simple it = is.
 
Thank you very much.
 
BONG
 
*  *  *  *  = * =20 *  *  *  *  *  *  *  *  *  = * =20 *  *  *  *  *  *  *  *  *  = * =20 *  *  * 
If you wish to be remove from our list, = just reply=20 to this e-mail with Remove as the text and we = will=20 removed you immediately. We honor remove requests=20 religiously.
------=_NextPart_000_06BC_01BFEB52.B83CC820-- From list@netscape.com Tue Jul 11 18:44:56 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22406 for ; Tue, 11 Jul 2000 18:44:55 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6BMbnU07535; Tue, 11 Jul 2000 15:37:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6BMgYI29221; Tue, 11 Jul 2000 15:42:34 -0700 (PDT) Resent-Date: Tue, 11 Jul 2000 15:42:34 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" Date: Tue, 11 Jul 2000 23:35:59 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Revised Matched Values Draft Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <396BAF5F.18224.11D7E459@localhost> Priority: normal In-reply-to: <4.3.2.7.0.20000701213030.00afe420@infidel.boolean.net> References: <395E667D.20321.CB299BF@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"3Vntm.A.QIH.YL6a5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Kurt I have produced a version 03 including your comments as described below, but I wont release it until after Pittsburgh and any other comments that I get > >1. Introduction > > > >When reading an attribute from an entry using LDAP v2 [1] or LDAPv3 > >[2], > > I suggest not mentioning LDAP v2... done > > >it is normally only possible to read either the attribute type, or > >the attribute type and all its values. It is not possible to > >selectively read just a few of the attribute values. If an attribute > >holds many values, for example, the userCertificate attribute, or the > > subschema publishing operational attributes objectClasses and > >attributeTypes [3], then it may be desirable for the user to be able > >to selectively retrieve a subset of the values, specifically, those > >attribute values that match some user defined selection criteria. > >Without the control specified in this [ID/standard] a client must > > s/[ID/standard]/document/ done > > >read all of the attribute's values and filter out the unwanted > >values, necessitating the client to implement the matching rules. It > >also requires the client to potentially read and process many > >irrelevant values, which can be inefficient if the values are large > >or complex, or there are many values stored per attribute. > > > >This Internet Draft specifies an LDAPv3 control to enable a user to > > s/Internet Draft/document/ done > > > > >return only those values that matched (i.e. returned TRUE to) one or > >more elements of a newly defined "values return" filter. This control > > can be especially useful when used in conjunction with extensible > >matching rules that match on one or more components of complex binary > > attribute values. > > > >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 RFC 2119 [5]. > > > > > >2. The valuesReturnFilter Control > > > >The valuesReturnFilter control MAY be critical or non-critical as > >determined by the user. It is only applicable to the Search > >operation, and SHALL be ignored by the server if it is present on any > > other LDAP operation (even if marked critical on such operations). > > I suggest that if this control is provided to non-search operations > and marked critical that an unavailableCriticalExtension > (unsupportedCriticalExtension) error should be returned. This is > consistent with RFC 2251, 4.1.12. done > If the control is not appropriate for the operation and criticality > field is TRUE, the server MUST NOT perform the operation, and MUST > instead return the resultCode unsupportedCriticalExtension. > > > >The object identifier for this control is 1.2.826.0.1.3344810.2.3 > > > > > >The controlValue is > > > > ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem > > > > SimpleFilterItem ::= CHOICE { > > equalityMatch [3] AttributeValueAssertion, > > substrings [4] SubstringFilter, > > greaterOrEqual [5] AttributeValueAssertion, > > lessOrEqual [6] AttributeValueAssertion, > > present [7] AttributeDescription, > > approxMatch [8] AttributeValueAssertion, > > extensibleMatch [9] SimpleMatchingAssertion } > > > > SimpleMatchingAssertion ::= SEQUENCE { > > matchingRule [1] MatchingRuleId OPTIONAL, > > type [2] AttributeDescription OPTIONAL, > > matchValue [3] AssertionValue} > > > >All the above data types have their standard meanings as defined in > >[2]. > > > >If the server supports this control, the server MUST make use of the > >control as follows: > > > >(1) The Search Filter is first executed in order to determine > >which entries satisfy the Search criteria. The control has no > >impact on this step. > > > >(2) If the typesOnly parameter of the Search Request is TRUE, > >the control has no effect and the Search Request SHOULD be > >processed as if the control had not been specified. > > > >(3) If the attributes parameter of the Search Request consists > >of a list containing only the attribute with OID "1.1" > >(specifying that no attributes are to be returned), the control has > >no effect and the Search Request SHOULD be processed as if the > >control had not been specified. > > > >(4) For each attribute listed in the attributes parameter of the > >Search Request, the server MUST apply the control as follows: > > > >i) Every attribute value that evaluates TRUE against one or > >more elements of the ValuesReturnFilter is placed in the > >SearchResultEntry. > >ii) Every attribute value that evaluates FALSE or undefined > >against all elements of the ValuesReturnFilter is not > >placed in the SearchResultEntry. An attribute that has no > >values selected is returned with an empty set of vals. > > > >Editor's Note. There is possibly a more efficient but slightly more > >complex way of achieving the value filtering. An alternative is to > >remove the 'present' SimpleFilterItem (which obviously evaluates true > > for every attribute value of the 'present' attribute description), > >and to say that any attribute whose type is not mentioned in the > >ValuesReturnFilter is not filtered and has all its attribute values > >returned. Comments please. > > I prefer the specified approach as it appears easier to implement > especially for servers which separate filter evaluation from attribute > list processing. That is, in U-Mich derived servers, filter evaluation > is done by database backends and attribute list processing is done by > the frontend. Implementing this control with the above design might > prove to be more than slightly complex and the efficient gain may > actually be quite slight. Editors note removed > > >3. Relationship to X.500 > > > >The control is a superset of the matchedValuesOnly boolean of the > >X.500 DAP [4] Search argument, as amended in the latest version [6]. > >Close examination of the matchedValuesOnly boolean by the LDAPExt > >group revealed ambiguities and complexities in the MVO boolean that > >could not easily be resolved. For example, are only those attribute > >values that contributed to the overall truth of the filter governed > >by the MVO boolean, or all values of attributes in the filter > >governed by the MVO boolean, even if the filter item containing the > >attribute evaluated to false. For this reason the LDAP group decided > >to replace the MVO boolean with a simple filter that removes any > >uncertainty as to whether an attribute value has been selected or > >not. > > > > > >4. Examples > > > >(1) The first example simply shows how the control can be used to > >selectively read a subset of attribute values. > > > >The entry below represents a groupOfNames object class containing > >several members from different organizations. > > Please specify a DN, object classes, and ensure entry is valid per > Standard Track schema in all examples. The examples are not that good and so I have redone them. Example one has been deleted completely. Please review in the revised ID when it is published > You might specify that entries > are provided in LDIF (RFC2849). Done > > >cn: Cross Organizational Standards Body > >member: cn=joe,o=acme > >member: cn=alice,o=acme > >member: cn=bob,o=foo > >member: cn=sue,o=bar > > > >An LDAP search operation is specified with a baseObject set to the DN > >of the entry, a baseObject scope, a filter set to "member=*o=acme", > >and the list of attributes to be returned set to "member". In > >addition, a ValuesReturnFilter control is set to "member=*o=acme". > > Note that filter (which is missing parentheses) is should evaluation > to Undefined as member attribute type does specify a substrings > matching rule. Noted. This is why I have redone the examples! > > >The search results returned by the server would consist of the > >following entry: > > > >cn: Cross Organizational Standards Body > >member: cn=joe, o=acme > >member: cn=alice, o=acme > > > > > >(2) The second example shows how the control can be set to match on > >attributes that are (mail) and are not (telephoneNumber) part of the > >search filter. It also shows how a user can filter some attribute > >values (mail) and not others (telephoneNumber). > > Note sure why you have parentheses around these attribute types. It was to show which ones were which in the example, that's all. But its gone now. > > >The entries below represent inetOrgPerson [7] object classes located > >below some distinguished name in the directory. > > I would suggest using organizationalPerson (w/ appropriate attributes) > instead of inetOrgPerson as inetOrgPerson is Informational (though I > don't be this use would cause a standard track maturity issue). I would rather keep it as well as adding orgPerson, as I need the mail attribute. > > >cn: Sean Mullan > >mail: sean.mullan@sun.com > >mail: mullan@east.sun.com > >telephoneNumber: +1 781 442 0926 > >telephoneNumber: 555-9999 > > > >cn: David Chadwick > >mail: d.w.chadwick@salford.ac.uk > > > >An LDAP search operation is specified with a baseObject set to the DN > >of the entry, a subtree scope, a filter set to > >"(|(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk))", and > > the list of attributes to be returned set to "mail telephoneNumber". > > In addition, a ValuesReturnFilter control is set to > >"mail=sean.mullan@sun.com, mail=d.w.chadwick@salford.ac.uk, > >telephoneNumber=*" > > Please use parentheses. In fact, you may want to define a string > format for ValuesReturnFilter. I suggest something like: > > (:(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk)(teleph > oneNumber=*)) > > or if that looks too much like a search filter: > > {(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk)(telepho > neNumber=*)} I think it would be a good idea for the LDAP group to settle on a character that can represent the ASN.1 type SEQUENCE, and another that can represent a SET. I need this also for my PKI and PMI schema document. Steven Legg is working on this at the moment, but lets assume for now that comma , represents SEQUENCE and + represents SET. Unfortunately we have not been too consistent in this in the past, as comma has represented both, and + has also represented SET (e.g. as in DNs) > > >The search results returned by the server would consist of the > >following entries: > > > >cn: Sean Mullan > >mail: sean.mullan@sun.com > >telephoneNumber: +1 781 442 0926 > >telephoneNumber: 555-9999 > > > >cn: David Chadwick > >mail: d.w.chadwick@salford.ac.uk > > > >Note that the control has no effect on the values returned for the > >"telephoneNumber" attribute (all of the values are returned), since > >the control specified that all values should be returned. > > > >(3) The third example shows how one might retrieve a single attribute > > type schema definition for the "gunk" attribute with OID 1.2.3.4.5 > > > >Assume the subschema subentry is held somewhere below the root entry > >with RDN "subschema subentry", and this holds an attributeTypes > >operational attribute holding the descriptions of the 35 attributes > >known to this server (each description is held as a single attribute > >value of the attributeTypes attribute). > > > >cn: subschema subentry > >objectClass: subschema > >attributeTypes: ( 2.5.4.3 NAME 'cn' SUP name ) > >attributeTypes: ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE ) > >attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY > >objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) > >attributeTypes: ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY > >generalizedTimeMatch ORDERING generalizedTimeOrderingMatch > >SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER- > >MODIFICATION USAGE directoryOperation ) > >attributeTypes: ( 2.5.21.6 NAME 'objectClasses' EQUALITY > >objectIdentifierFirstComponentMatch SYNTAX > >1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation ) > >attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch > >SUBSTR caseIgnoreSubstringsMatch SYNTAX > >1.3.6.1.4.1.1466.115.121.1.44{64} ) attributeTypes: ( 2.5.21.5 NAME > >'attributeTypes' EQUALITY objectIdentifierFirstComponentMatch SYNTAX > >1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation ) > > > >plus another 28 - you get the idea. > > > > > >The user creates an LDAP search operation with a baseObject set to > >root, a subtree scope, a filter set to "objectClass=subschema", the > >list of attributes to be returned set to "attributeTypes", and the > >ValuesReturnFilter set to "attributeTypes=1.2.3.4.5" > > Per RFC 2251, subschema subentries should be retrieved using a search > with a base of the subschema subentry's DN, scope base, and filter > (objectclass=subschema). Please use this procedure in your example. > Done > >The search result returned by the server would consist of the > >following entry: > > > >cn: subschema subentry > >attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch > >SUBSTR caseIgnoreSubstringsMatch SYNTAX > >1.3.6.1.4.1.1466.115.121.1.44{64} ) > > > >(4) The final example shows how the control can be set to match on > >attributes that are not part of the search filter. For example, > >searching for all entries that have an email address in the sun.com > >domain, and returning the telephone number for any attribute values > >that start with "555". > > > >The entries below represent inetOrgPerson [7] object classes located > >below some distinguished name in the directory. > > > >cn: Sean Mullan > >mail: sean.mullan@sun.com > >mail: mullan@east.sun.com > >telephoneNumber: +1 781 442 0926 > >telephoneNumber: 555-9999 > > > >cn: David Chadwick > >mail: d.w.chadwick@salford.ac.uk > > > >An LDAP search operation is specified with a baseObject set to the DN > >of the entry, a subtree scope, a filter set to "mail=*sun.com", and > >the list of attributes to be returned set to "telephoneNumber". In > >addition, a ValuesReturnFilter control is set to > >"telephoneNumber=555*" > > > >The search results returned by the server would consist of the > >following entry: > > > >cn: Sean Mullan > >telephoneNumber: 555-9999 > > > > > >5. Security Considerations > > > >This Internet Draft does not discuss security issues at all. > > s/Internet Draft/document/ Done > > I suggest you strike this statement as this section discussion > security issues (though mute). I suggest you revise the comments > below into primary considerations. > > >Note that attribute values MUST only be returned if the access > >controls applied by the LDAP server allow them to be returned, and in > > this respect the effect of the ValuesReturnFilter control is of no > >consequence. > > How do "search" versus "read" access to be applied. That is, where > "search" access is required to evaluation search filters and "read" > access is required to return return attributes, is this mechanism > considered part of "searching" or part of "reading"? Though the > mechanism uses filters, I'm thinking it's part of "reading" as the > mechanism is only applied entries which match the search filter and > scope. Would treating the mechanism as part of "reading" be > consistent with X.500/LDAP/vendor access controls? > Actually I think that ValuesReturnFilter should be independent of the access control mechanism. In other words, search access is used as now to find the entries, then valuesReturnFilter filters the attributes free of any access contol provisions, then read access is applied as now to the filtered attributes to see if they can be returned or not. (You could in fact consider the ValuesReturnFilter as an access control applied by the user!! or maybe not) > >Note that the ValuesReturnFilter control may have a positive effect > >on the deployment of public key infrastructures. Certain PKI > >operations, like searching for specific certificates, become more > >practical (when combined with X.509 certificate matching rules at the > > server) and more scalable, since the control avoids the downloading > >of potentially large numbers of irrelevant certificates which would > >have to be processed and filtered locally (which in some cases is > >very difficult to perform). > > > > > >6. Acknowledgements > > > >The authors would like to thank members of the LDAPExt list for their > > constructive comments on earlier versions of this draft, and in > > s/draft/document/ Done > > >particular to Harald Alvestrand who first suggested having an > >attribute return filter and Bruce Greenblatt who first proposed a > >syntax for this control. > > > >7. Copyright > > > >Copyright (C) The Internet Society (date). All Rights Reserved. > > Date should be specified. I think that is left until the RFC is published is it not? > > >8. References > > > >[7] M. Smith. "Definition of the inetOrgPerson LDAP Object Class", > >Internet Draft , April 1999. > > Published as RFC 2798. Done Many thanks David > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Tue Jul 11 18:49:18 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22449 for ; Tue, 11 Jul 2000 18:49:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6BMfQU08357; Tue, 11 Jul 2000 15:41:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6BMggs29374; Tue, 11 Jul 2000 15:42:42 -0700 (PDT) Resent-Date: Tue, 11 Jul 2000 15:42:42 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" Date: Tue, 11 Jul 2000 23:36:00 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Revised Matched Values Draft Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <396BAF60.31957.11D7E698@localhost> Priority: normal In-reply-to: <4.3.2.7.0.20000701225708.00ae3a60@infidel.boolean.net> References: <395E667D.20321.CB299BF@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"zytY2C.A.1JH.fL6a5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date sent: Sat, 01 Jul 2000 23:05:21 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: Revised Matched Values Draft Copies to: ietf-ldapext@netscape.com > Another comment: > >If the server supports this control, the server MUST make use of the > >control as follows: > > > >(1) The Search Filter is first executed in order to determine > >which entries satisfy the Search criteria. The control has no > >impact on this step. > > > >(2) If the typesOnly parameter of the Search Request is TRUE, > >the control has no effect and the Search Request SHOULD be > >processed as if the control had not been specified. > > > >(3) If the attributes parameter of the Search Request consists > >of a list containing only the attribute with OID "1.1" > >(specifying that no attributes are to be returned), the control has > >no effect and the Search Request SHOULD be processed as if the > >control had not been specified. > > This step seems unnecessary. Agreed but I would rather keep it in, as it removes any ambiguity, and in the future someone is sure to ask "what about an attribute of 1.1?". Whilst you can argue that the clause is covered by the preceding one, this just makes sure it is crystal clear. > > > >(4) For each attribute listed in the attributes parameter of the > >Search Request, the server MUST apply the control as follows: > > > >i) Every attribute value that evaluates TRUE against one or > >more elements of the ValuesReturnFilter is placed in the > >SearchResultEntry. > >ii) Every attribute value that evaluates FALSE or undefined > >against all elements of the ValuesReturnFilter is not > >placed in the SearchResultEntry. An attribute that has no > >values selected is returned with an empty set of vals. > > How is the control applied if no attribute list is provided or "*" is > in the list. I would assume, in both cases, that all user attributes > contain in entry would be evaluated (per step 4) as if they were > explicitly listed. Correct. I have added a note to this effect. David > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Tue Jul 11 21:00:14 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24482 for ; Tue, 11 Jul 2000 21:00:13 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6C0reU02236; Tue, 11 Jul 2000 17:53:40 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6C0wOY28572; Tue, 11 Jul 2000 17:58:24 -0700 (PDT) Resent-Date: Tue, 11 Jul 2000 17:58:24 -0700 (PDT) Message-Id: <4.3.1.0.20000711173837.00ad3c30@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 11 Jul 2000 18:01:38 -0700 To: d.w.chadwick@salford.ac.uk, "Kurt D. Zeilenga" From: Bruce Greenblatt Subject: Re: Revised Matched Values Draft Cc: ietf-ldapext@netscape.com In-Reply-To: <396BAF60.31957.11D7E698@localhost> References: <4.3.2.7.0.20000701225708.00ae3a60@infidel.boolean.net> <395E667D.20321.CB299BF@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"9o4KzD.A.C-G.tK8a5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I'll voice the same reservations this time that I voiced last time. Use of this control solves a problem that normally exists due to poor schema and DIT design. There is no obvious reason why an entry should have so many values of an attribute that an LDAP client would have a problem retrieving them all. Do not put hundreds of values (or however many you have in mind) in the attribute. The introduction uses the userCertificate attribute as an example. While it is true that a single user in the real world may have numerous certificates, this should not translate into an LDAP entry that has numerous userCertificate attribute values. IMHO, this is poor schema/DIT design. By creating this control, we only encourage this type of design, when we really need to discourage it. In my mind it is analogous to encouraging non-normalized SQL schemas. I wrote a little draft a while back (http://www.ietf.org/internet-drafts/draft-greenblatt-ldap-certinfo-schema-02.txt) that recommends a schema/DIT design for holding certificate information in the schema that allows for selective retrieval of certificates without requiring any protocol extensions (or even any new syntaxes). I have had several people ask me privately about this draft with indications that they were interested in implementing it. Additionally, I believe that implementation of this control could place an unnecessary burden on the server for sifting through the attribute values, when it should be done on the client (perhaps this is more of a stylistic issue). In any case, I would not be in favor of promoting this draft along the standards track. Last time this came up, and I voice this same objection to the draft, I received several notes supporting my position. I think that we need to think carefully about what kinds of protocol extension that should be standardized, and how they benefit LDAP applications. In my mind this extension provides no benefits to LDAP applications. Bruce From list@netscape.com Tue Jul 11 21:28:48 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24798 for ; Tue, 11 Jul 2000 21:28:47 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6C1LCU05007; Tue, 11 Jul 2000 18:21:12 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6C1Pvg07368; Tue, 11 Jul 2000 18:25:57 -0700 (PDT) Resent-Date: Tue, 11 Jul 2000 18:25:57 -0700 (PDT) Date: Tue, 11 Jul 2000 20:24:41 -0500 From: Mark Wahl Subject: Reminder: draft submission deadline is Friday Sender: wahl@austin.innosoft.com To: ietf-ldapext@netscape.com Message-id: <16579.963365081@threadgill.austin.innosoft.com> Resent-Message-ID: <"KC0YcB.A.vyB.jk8a5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com The IETF draft submission deadline is Friday for documents to be discussed in Pittsburgh. Once I know what drafts there are I'll send out a preliminary agenda for the Pittsburgh LDAPEXT meeting. FYI an overall IETF schedule is not yet available, so I don't know yet what day LDAPEXT is meeting. Mark Wahl, Directory Architect, Service Provider/Infrastructure Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Wed Jul 12 00:37:44 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29332 for ; Wed, 12 Jul 2000 00:37:44 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6C4V7U20796; Tue, 11 Jul 2000 21:31:07 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6C4Zqs27964; Tue, 11 Jul 2000 21:35:52 -0700 (PDT) Resent-Date: Tue, 11 Jul 2000 21:35:52 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Tue, 11 Jul 2000 22:35:27 -0600 From: "Jim Sermersheim" To: Cc: Subject: Submission of draft-ietf-ldapext-ldapv3-dupent-04.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_421A1D8D.56374115" Resent-Message-ID: <"haY5cC.A.l0G.mW_a5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_421A1D8D.56374115 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I-D editor,=20 Please publish this draft as an update to draft-ietf-ldapext-ldapv3-dupent-= 03.txt. This is a document of the ldapext working group.=20 Thanks. LDAPEXTers, I believe consensus was reached on all last call issues, and those issues = have been worked back into this draft. Following is a summary of those = changes: - Clarified the way attribute subtypes are handled (only the exact = attribute specified is used). - Specified that transport-specific attr type options (like binary) SHOULD = NOT be sent.. - Fixed problems with lowercase mays and shoulds, changed a couple shoulds = to MUSTs. - Added a Security Considerations section. - Changed the error code for the condition of duplicate attribute = descriptions in the request control from unwillingToPerform to protocolErro= r. - Now allow any LDAP error to be returned in the response, and highlighted = those that have special meanings in the context of the response control. - Changed all examples to use dc=3Dexample,dc=3Dnet, and example.net and = removed all references to Warner Brothers Looney Tunes characters (sob). - Added a second response control that is sent with each search result = that has been affected by the control and highlighted its behavior in the = examples. - Talksed about server chaining in the implementation section. - Specified that all search response entries must match the original = search filter. Jim --=_421A1D8D.56374115 Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldapext-ldapv3-dupent-04.txt" LDAPEXT Working Group J. Sermersheim Internet Draft Novell, Inc Document: draft-ietf-ldapext-ldapv3-dupent-04.txt July 2000 Category: Proposed Standard LDAP Control for a Duplicate Entry Representation of Search Results 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 2. Abstract This document describes a Duplicate Entry Representation control extension for the LDAP Search operation. By using the control with an LDAP search, a client requests that the server return separate entries for each value held in the specified attributes. For instance, if a specified attribute of an entry holds multiple values, the search operation will return multiple instances of that entry, each instance holding a separate single value in that attribute. 3. Overview The Server-Side Sorting control [SSS] allows the server to order search result entries based on attribute values (sort keys). It does not allow one to specify behavior when an attribute contains multiple values. The default behavior, as outlined in 7.9 of [X.511], is to use the smallest value as the sort key. An application may need to produce an ordered list of entries, sorted by a multi-valued attribute, where each attribute value is represented in the list. In order to do this, a separate control is needed which causes the set of entries to be expanded sufficiently to represent each attribute value prior to sorting. Sermersheim Standards Track - Expires Jan 2001 Page 1 LDAP Control for a Duplicate Entry Representation of Search Results This document describes controls, which allow duplicate entries in the result set of search, where each entry represents a distinct value of a given multiple valued attribute. An example of this would be a sorted list of all telephone numbers in an organization. Because any entry may have multiple telephone numbers, and the list is to be sorted by telephone number, the list must be able to contain duplicate entries, each with its own unique telephone number. Another example would be an application that needs to display an ordered list of all members of a group. It would use this control to create a result set of duplicate groupOfNames entries, each with a single, unique value in its member attribute. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" used in this document carry the meanings described in [RFC2119]. 4. The Controls Support for the controls is advertised by the presence of their OID in the supportedControl attribute of a server's root DSE. The OID for the request control is "2.16.840.1.113719.1.27.101.1" and the OID for the response control is "2.16.840.1.113719.1.27.101.2". 4.1 Request Control This control is included in the searchRequest message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [RFC2251]. The controlType is set to "2.16.840.1.113719.1.27.101.1". The criticality MAY be set to either TRUE or FALSE. The controlValue is an OCTET STRING, whose value is the BER encoding of the following type: DuplicateEntryRequest ::= SEQUENCE { AttributeDescriptionList, PartialResultsAllowed BOOLEAN DEFAULT TRUE } The "AttributeDescriptionList" data type is described in 4.1.5 of [RFC2251] and describes a list of 0 or more AttributeDescription types as also described in 4.1.5 of [RFC2251]. Both definitions are repeated here for convenience: AttributeDescriptionList ::= SEQUENCE OF AttributeDescription AttributeDescription ::= [ ";" ] While processing a search request, a server implementation examines this list. If a specified attribute exists in an entry to be Sermersheim Standards Track - Expires Jan 2001 Page 2 LDAP Control for a Duplicate Entry Representation of Search Results returned by search, and that attribute holds multiple values, the server treats the entry as if it were multiple, duplicate entries -- the specified attributes each holding a single, unique value from the original set of values of that attribute. These duplicate entries are returned to the client only if they still match the asserted search filter. Attribute subtypes are not considered when evaluating an attribute. An AttributeDescription MUST only occur once in the list. If an AttributeDescription is included in the DuplicateEntryRequest multiple times, the server MUST return a protocolError error in the DuplicateEntryResponseDone control. Client implementations SHOULD NOT specify attribute type options that indicate transfer encoding. When two or more attribute types are specified by this control, the number of duplicate entries is the combination of all values in each attribute. Because of the potential complexity involved in servicing multiple attribute types, server implementations MAY choose to support a limited number of attribute types in the control. There is a special case where either no attributes are specified, or an attribute description value of "*" is specified. In this case, all attributes are used. (The "*" allows the client to request all user attributes in addition to specific operational attributes). The PartialResultsAllowed field is used to specify whether the client will allow the server to apply this control to a subset of the search result set. If TRUE, the server is free to arbitrarily apply this control to no, any, or all search results. If FALSE, the server MUST either apply the control to all search results or fail to support the control at all. Client implementation use the 4.2 Response Controls Two response controls are defined to provide feedback while the search results are being processed; DuplicateSearchResult and DuplicateEntryResponseDone. The DuplicateSearchResult control is sent with all SearchResultEntry operations that contain search results which have been modified by the DuplicateEntryRequest control. The DuplicateEntryResponseDone control is sent with the SearchResultDone operation in order to convey completion information. 4.2.1 The DuplicateSearchResult control Sermersheim Standards Track - Expires Jan 2001 Page 3 LDAP Control for a Duplicate Entry Representation of Search Results This control is included in the SearchResultEntry message of any search result that holds an entry that has been modified by the DuplicateEntryRequest control as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [RFC2251]. This control is absent on search results that are unaffected by DuplicateEntryRequest control. The controlType is set to "2.16.840.1.113719.1.27.101.2". The criticality is FALSE (MAY be absent). The controlValue is not included. 4.2.2 The DuplicateEntryResponseDone control This control is included in the searchResultDone message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [RFC2251]. The controlType is set to "2.16.840.1.113719.1.27.101.3". The criticality is FALSE (MAY be absent). The controlValue is an OCTET STRING, whose value is the BER encoding of the following SEQUENCE: DuplicateEntryResponseDone ::= SEQUENCE { resultCode, -- From [RFC2251] errorMessage, [0] LDAPString, OPTIONAL attributeType [1] AttributeDescription OPTIONAL } A result field is provided here to allow feedback in the case where the criticality of the request control is FALSE, and the server could not process the control - yet it could complete the search operation successfully. If the request control's criticality is TRUE, and the server cannot process the control, the resultCode of the LDAPResult is used to report the error. Though any result code that is defined in [RFC2251] MAY be returned the following list assigns special meanings to certain result codes when returned in this control: - success: The control was successful. - protocolError Invalid data in request control. - timeLimitExceeded Time limit reached before attribute values could be processed. - sizeLimitExceeded Size limit reached as a result of this control. - adminLimitExceeded result set too large for server to handle. - noSuchAttribute unrecognized attribute description. - unwillingToPerform Server cannot process control. errorMessage MAY be populated with a human-readable string in the event of an erroneous result code. attributeType MAY be set to the value of the first attribute type specified by the DuplicateEntryRequest that was in error. The client MUST ignore the attributeType field if the result is success. Sermersheim Standards Track - Expires Jan 2001 Page 4 LDAP Control for a Duplicate Entry Representation of Search Results 5. Protocol Examples 5.1 Simple example This example will show this control being used to produce a list of all telephone numbers in the dc=example,dc=net container. Let's say the following three entries exist in this container; dn: cn=User1,dc=example,dc=net telephoneNumber: 555-0123 dn: cn=User2,dc=example,dc=net telephoneNumber: 555-8854 telephoneNumber: 555-4588 telephoneNumber: 555-5884 dn: cn=User3,dc=example,dc=net telephoneNumber: 555-9425 telephoneNumber: 555-7992 First an LDAP search is specified with a baseDN of "dc=example,dc=net", subtree scope, filter set to "telephoneNumber=*". A DuplicateEntryRequest control is attached to the search, specifying "telephoneNumber" as the attribute description, and the search request is sent to the server. The set of search results returned by the server would then consist of the following entries: dn: cn=User1,dc=example,dc=net telephoneNumber: 555-0123 dn: cn=User2,dc=example,dc=net telephoneNumber: 555-8854 dn: cn=User2,dc=example,dc=net telephoneNumber: 555-4588 dn: cn=User2,dc=example,dc=net telephoneNumber: 555-5884 dn: cn=User3,dc=example,dc=net telephoneNumber: 555-9425 dn: cn=User3,dc=example,dc=net telephoneNumber: 555-7992 All but the first entry are accompanied by the DuplicateSearchResult control when sent from the server. Sermersheim Standards Track - Expires Jan 2001 Page 5 LDAP Control for a Duplicate Entry Representation of Search Results Note that it is not necessary to use an attribute type in this control that is specified in the search filter. This example only does so, because the result was to obtain a list of telephone numbers. 5.2 Specifying multiple attributes A more complicated example involving multiple attributes will result in more entries. If we assume these entries in the directory: dn: cn=User1,dc=example,dc=net givenName: User1 mail: user1@example.net dn: cn=User2,dc=example,dc=net givenName: User2 givenName: User Two mail: user2@example.net mail: usertwo@example.net And both "mail" and "givenName" are specified as attribute types in this control, the resulting set of entries would be this: dn: cn=User1,dc=example,dc=net givenName: User1 mail: user1@example.net dn: cn=User2,dc=example,dc=net givenName: User2 mail: user2@example.net dn: cn=User2,dc=example,dc=net givenName: User2 mail: usertwo@example.net dn: cn=User2,dc=example,dc=net givenName: User Two mail: user2@example.net dn: cn=User2,dc=example,dc=net givenName: User Two mail: usertwo@example.net 5.3 Listing the members of a groupOfNames This example shows how the controls can be used to turn a single groupOfNames entry into multiple duplicate entries. Let’s say this is our groupOfNames entry: dn: cn=Administrators,dc=example,dc=net cn: Administrators member: cn=aBaker,dc=example,dc=net member: cn=cDavis,dc=example,dc=net Sermersheim Standards Track - Expires Jan 2001 Page 6 LDAP Control for a Duplicate Entry Representation of Search Results member: cn=bChilds,dc=example,dc=net member: cn=dEvans,dc=example,dc=net We could set our search base to "cn=Administrators,dc=example,dc=net ", filter to "objectClass=*", use an object scope (to restrict it to this entry) and send the duplicateEntryRequest control with "member" as its attribute value. The resulting set would look like this: dn: cn=Administrators,dc=example,dc=net member: cn=aBaker,dc=example,dc=net dn: cn=Administrators,dc=example,dc=net member: cn=cDavis,dc=example,dc=net dn: cn=Administrators,dc=example,dc=net member: cn=bChilds,dc=example,dc=net dn: cn=Administrators,dc=example,dc=net member: cn=dEvans,dc=example,dc=net This list can then be sorted by member and displayed (also by member) in a list. 5.4 Returning a subset of duplicates due to a stricter filter. This example is similar to that shown in 5.1 except that the search filter is modified to cause only a subset of certain duplicate entries to be returned. Assume the following three entries exist; dn: cn=User1,dc=example,dc=net telephoneNumber: 555-5123 dn: cn=User2,dc=example,dc=net telephoneNumber: 555-8854 telephoneNumber: 555-5588 telephoneNumber: 555-5884 dn: cn=User3,dc=example,dc=net telephoneNumber: 555-9425 telephoneNumber: 555-5992 An LDAP search is specified with a baseDN of "dc=example,dc=net", subtree scope, filter set to "telephoneNumber=555-5*". A DuplicateEntryRequest control is attached to the search, specifying "telephoneNumber" as the attribute description, and the search request is sent to the server. The set of search results returned by the server would then consist of the following entries: dn: cn=User1,dc=example,dc=net telephoneNumber: 555-5123 Sermersheim Standards Track - Expires Jan 2001 Page 7 LDAP Control for a Duplicate Entry Representation of Search Results dn: cn=User2,dc=example,dc=net telephoneNumber: 555-5588 dn: cn=User2,dc=example,dc=net telephoneNumber: 555-5884 dn: cn=User3,dc=example,dc=net telephoneNumber: 555-5992 DuplicateSearchResult controls are included with all search results except the first (as noted). A subtlety that should be noted is that even though the last search result is not duplicated (from the view of the client -- due to the application of the search filter), it is still sent with a DuplicateSearchResult control. 6 Relationship to other controls This control is intended (but not limited) to be used with the Server Side Sorting control [SSS]. By pairing this control with the Server Side Sorting control, One can produce a set of entries, sorted by attribute values, where each attribute value is represented in the sorted set. Server implementations MUST ensure that this control is processed before sorting the result of a search, as this control alters the result set of search. This control MAY also be used with the Virtual List View [VLV] control (which has a dependency on the Server Side Sort control). The nature of the dependency between the VLV control and the Sort control is such that the Sorting takes place first. Because the sort happens first, and because this control is processed before the sort control, the impact of this control on the VLV control is minimal. Some server implementations may need to carefully consider how to handle the typedown functionality of the VLV control when paired with this control. The details of this are heavily implementation dependent and are beyond the scope of this document. 7. Notes for Implementers Both client and server implementations MUST be aware that using this control could potentially result in a very large set of search results. Servers MAY return an adminLimitExceeded result in the response control due to inordinate consumption of resources. This may be due to some a priori knowledge such as a server restriction of the number of attribute types in the request control that it's willing to service, or it may be due to the server attempting to service the control and running out of resources. Client implementations MUST be aware that search entries returned, when using this control will contain a subset of the values of any specified attribute. Sermersheim Standards Track - Expires Jan 2001 Page 8 LDAP Control for a Duplicate Entry Representation of Search Results If this control is used in a chained environment, servers SHOULD NOT pass this control to other servers. Instead they SHOULD gather results and apply this control themselves. 8. Security Considerations This control allows finer control of the result set returned by an LDAP search operation and as such may be used in a denial of service attack. See Section 7 for more information on how this is detected and handled. 9. Acknowledgments The author gratefully thanks the input and support of participants of the LDAP-EXT working group. 10. References [RFC2251] Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access Protocol (v3)", Internet Standard, December, 1997. Available as RFC2251. [SSS] Wahl, M, A. Herron and T. Howes, "LDAP Control Extension for Server Side Sorting of Search Results", Internet Draft, June, 2000. Available as draft-ietf-ldapext-sorting-03.txt. [VLV] Boreham, D, Sermersheim, J, Anantha, A, Armijo, M, "LDAP Extensions for Scrolling View Browsing of Search Results", Internet Draft, April, 2000. Available as draft-ietf-ldapext-ldapv3-vlv-04.txt. [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993. [RFC2119] Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement Levels", Internet Draft, March, 1997. Available as RFC2119. 11. Author's Address Jim Sermersheim Novell, Inc. 122 East 1700 South Provo, Utah 84606, USA jimse@novell.com +1 801 861-3088 Sermersheim Standards Track - Expires Jan 2001 Page 9 --=_421A1D8D.56374115-- From list@netscape.com Wed Jul 12 01:07:27 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29956 for ; Wed, 12 Jul 2000 01:07:26 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6C50pU23017; Tue, 11 Jul 2000 22:00:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6C55ao05480; Tue, 11 Jul 2000 22:05:36 -0700 (PDT) Resent-Date: Tue, 11 Jul 2000 22:05:36 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C536E01@aspams01.cai.com> From: "Lloyd, Alan" To: Bruce Greenblatt , d.w.chadwick@salford.ac.uk, "Kurt D. Zeilenga" Cc: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft Date: Wed, 12 Jul 2000 15:05:32 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"DYhxYC.A.TVB.fy_a5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com My personal view.. I agree with Bruce.. a directory is a common repository for many applications and users.. It follows that those using it are "looking for things fast" or browsing. It follows that good, predicatble schema design is essential if the directory is to be effective. A user who is looking for things will not have to much pre knowledge of an attributes value or values.. Too many values (more than 8 say) is NOT good schema design - ie. having 200 values and reading an entry (all) will clutter the browser.. What happens with this - if a full sequence of all 7 filter values are used on all values - eg the lot on all values eg.. exact match, sounds like, substring, begins with, ends with - what gets returned? In the case of human users, how many will be trained to understand critical extensions and Sequences of Value filters? Doesnt "sounds like" do this job? regards alan -----Original Message----- From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] Sent: Wednesday, July 12, 2000 11:02 AM To: d.w.chadwick@salford.ac.uk; Kurt D. Zeilenga Cc: ietf-ldapext@netscape.com Subject: Re: Revised Matched Values Draft I'll voice the same reservations this time that I voiced last time. Use of this control solves a problem that normally exists due to poor schema and DIT design. There is no obvious reason why an entry should have so many values of an attribute that an LDAP client would have a problem retrieving them all. Do not put hundreds of values (or however many you have in mind) in the attribute. The introduction uses the userCertificate attribute as an example. While it is true that a single user in the real world may have numerous certificates, this should not translate into an LDAP entry that has numerous userCertificate attribute values. IMHO, this is poor schema/DIT design. By creating this control, we only encourage this type of design, when we really need to discourage it. In my mind it is analogous to encouraging non-normalized SQL schemas. I wrote a little draft a while back (http://www.ietf.org/internet-drafts/draft-greenblatt-ldap-certinfo-schema-0 2.txt) that recommends a schema/DIT design for holding certificate information in the schema that allows for selective retrieval of certificates without requiring any protocol extensions (or even any new syntaxes). I have had several people ask me privately about this draft with indications that they were interested in implementing it. Additionally, I believe that implementation of this control could place an unnecessary burden on the server for sifting through the attribute values, when it should be done on the client (perhaps this is more of a stylistic issue). In any case, I would not be in favor of promoting this draft along the standards track. Last time this came up, and I voice this same objection to the draft, I received several notes supporting my position. I think that we need to think carefully about what kinds of protocol extension that should be standardized, and how they benefit LDAP applications. In my mind this extension provides no benefits to LDAP applications. Bruce From list@netscape.com Wed Jul 12 05:01:04 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13999 for ; Wed, 12 Jul 2000 05:01:03 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6C8qQU06282; Wed, 12 Jul 2000 01:52:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6C8vB620131; Wed, 12 Jul 2000 01:57:11 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 01:57:11 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 12 Jul 2000 02:54:57 -0600 From: "Subbu K. k." To: Subject: Re: Revised Matched Values Draft Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e6C8v9120104 Resent-Message-ID: <"J-bm8B.A.O6E.mLDb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit Bruce, > Bruce Greenblatt 07/12/00 06:28AM >>> >...There is no obvious reason why an entry >should have >so many values of an attribute that an LDAP client would have a >problem >retrieving them all. Do not put hundreds of values (or however >many you >have in mind) in the attribute...... Sorry to digress from the main point, but there are valid reasons why a multi-valued attribute can have a large number of values. Take the example of a group member list. This can run into thousands and possibly millions of values on the Internet. Mailing list servers can also build up membership lists that are large. While such groups can be implemented using containers there are both pros and cons in going that way and not everyone will be happy with that choice. Group vs. OU is a separate topic for debate. I do see some merit in supporting a server-side filter for an attribute value read operation. This should help in bridging any 'impedance' mismatch between an LDAP client and the server. Subbu K. K. -------------------------------------------------------------- K. K. Subramaniam, email: kksubramaniam@novell.com, subbu@novell.com Product Manager, NDS eDirectory (UNIX/Linux) Novell Software, Bangalore, INDIA Ph: +91 (80) 572-1290x2212, (USA) 801-861-7000x42612x2206, cell:801-361-1339 From list@netscape.com Wed Jul 12 06:33:52 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15376 for ; Wed, 12 Jul 2000 06:33:52 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CARWU11193; Wed, 12 Jul 2000 03:27:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CAWHQ08329; Wed, 12 Jul 2000 03:32:17 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 03:32:17 -0700 (PDT) Message-Id: <200007121032.GAA15215@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org, ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt Date: Wed, 12 Jul 2000 06:32:11 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"y7PHdB.A.0BC.vkEb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Additional LDAP Schema for PKIs and PMIs Author(s) : D. Chadwick Filename : draft-ietf-pkix-ldap-schema-00.txt Pages : 11 Date : 11-Jul-00 This document describes LDAP schema features in addition to RFC 2587 that are needed to support a Privilege Management Infrastructure and a Public Key Infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-schema-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ldap-schema-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ldap-schema-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000711135117.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ldap-schema-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ldap-schema-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000711135117.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Wed Jul 12 06:47:05 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15588 for ; Wed, 12 Jul 2000 06:47:05 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CAbBg10745; Wed, 12 Jul 2000 03:37:11 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CAjYY11036; Wed, 12 Jul 2000 03:45:34 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 03:45:34 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: Bruce Greenblatt Date: Wed, 12 Jul 2000 11:44:48 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Revised Matched Values Draft Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <396C5A30.3791.2869721@localhost> Priority: normal In-reply-to: <4.3.1.0.20000711173837.00ad3c30@pop.walltech.com> References: <396BAF60.31957.11D7E698@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"RFwsqD.A.EsC.MxEb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date sent: Tue, 11 Jul 2000 18:01:38 -0700 To: d.w.chadwick@salford.ac.uk, "Kurt D. Zeilenga" From: Bruce Greenblatt Subject: Re: Revised Matched Values Draft Copies to: ietf-ldapext@netscape.com > I'll voice the same reservations this time that I voiced last time. Bruce there are two separate though inter-related issues addressed in your ID. i) the first concerns the DIT structure and the storage of multiple, possibly related, attribute values in separate entries rather than in a single entry ii) the second concerns matching on complex attribute values. Matched values assumes for i) that separate entries will not always be employed, and so helps in cases where they are not. Interestingly, for the first issue you describe a DIT structure that is very similar to the family of entries structure I proposed in (now expired). I think that this sort of structure is sensible for grouping single values together and has lots of uses. We agree that we should try to standardise schema and controls for handling this type of subtree, as it has wide applicability (and is already in use in many directory implementations). However, even if we can agree on a standard approach to creating subtrees of related entries, there is no guarantee that every DIT will always use this approach, so there is still some value in the matchedValues ID. For the matching issue your proposal is that we actually dissect a complex attribute into its component parts, create separate attributes for each part and then put them together in a single entry. I dont like this approach for several reasons. Firstly it puts the onus on someone to read an attribute, dissect it, create separate attributes, and store them together, and make sure that the whole bunch are kept atomic. This is not a sensible approach as it puts a huge burden on some administrator or the creation of a new administration tool to do this. It also is a way of introducing errors since you are duplicating data. Secondly it mandates the subtree of entries approach and cannot work without it. Thirdly, it is not secure in the case of certificates (your example). A certificate is a digitally signed construct that cannot be manipulated. Your set of simple attributes are not digitally signed and therefore can be manipulated. There is no security control (outside of directory access controls) that stops this manipulation, and nothing that allows the user to check that these simple attributes are correct (either due to tampering or negligence or simple error), other than retrieving the certificate and comparing it to his matching criteria (i.e. he cannot trust the directory to perform correct matching). The better approach (I believe) is to define a matching rule that will match on a complex attribute. The matching software only has to be implemented in the server (in fact it is usually a combination of simple already-existing matching rules that need to be combined) and then we remove the overhead of dissection and attribute creation which is an ongoing process (we also significantly reduce storage space as well). Finally it will work with both subtrees of related entries and with single entries with lots of values. The new ID proposes an LDAP schema for this. > > Use of this control solves a problem that normally exists due to poor > schema and DIT design. There is no obvious reason why an entry should > have so many values of an attribute that an LDAP client would have a > problem retrieving them all. I suggest that subschema publishing is one such set of attributes that have this property. And this is mandatory to support in every LDAPv3 server. Thus the authors of LDAPv3 and X.500 are poor schema designers by implication. The other point is that every LDAPv3 will need a matchedValues type control if it is to return individual schema definitions. > Do not put hundreds of values (or > however many you have in mind) in the attribute. The introduction > uses the userCertificate attribute as an example. While it is true > that a single user in the real world may have numerous certificates, > this should not translate into an LDAP entry that has numerous > userCertificate attribute values. IMHO, this is poor schema/DIT > design. By creating this control, we only encourage this type of > design, when we really need to discourage it. In my mind it is > analogous to encouraging non-normalized SQL schemas. I wrote a little > draft a while back > (http://www.ietf.org/internet-drafts/draft-greenblatt-ldap-certinfo-sc > hema-02.txt) that recommends a schema/DIT design for holding > certificate information in the schema that allows for selective > retrieval of certificates without requiring any protocol extensions > (or even any new syntaxes). I have had several people ask me > privately about this draft with indications that they were interested > in implementing it. > > Additionally, I believe that implementation of this control could > place an unnecessary burden on the server for sifting through the > attribute values, when it should be done on the client (perhaps this > is more of a stylistic issue). We have had this discussion previously and several messages to the list said that sorting through complex attributes was a task that should be performed by the server and not the client. David > In any case, I would not be in favor > of promoting this draft along the standards track. Last time this > came up, and I voice this same objection to the draft, I received > several notes supporting my position. I think that we need to think > carefully about what kinds of protocol extension that should be > standardized, and how they benefit LDAP applications. In my mind this > extension provides no benefits to LDAP applications. > > Bruce > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Wed Jul 12 06:52:21 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15654 for ; Wed, 12 Jul 2000 06:52:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CAihU12759; Wed, 12 Jul 2000 03:44:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CAnSs13656; Wed, 12 Jul 2000 03:49:28 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 03:49:28 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Lloyd, Alan" Date: Wed, 12 Jul 2000 11:48:46 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: Revised Matched Values Draft Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <396C5B1E.32256.28A3859@localhost> Priority: normal In-reply-to: <11981F9F5649D411BC92009027D0D18C536E01@aspams01.cai.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"u7Iz6C.A._UD.20Eb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT From: "Lloyd, Alan" To: Bruce Greenblatt , d.w.chadwick@salford.ac.uk, "Kurt D. Zeilenga" Copies to: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft Date sent: Wed, 12 Jul 2000 15:05:32 +1000 > My personal view.. > > I agree with Bruce.. a directory is a common repository for many > applications and users.. It follows that those using it are "looking > for things fast" or browsing. It follows that good, predicatble schema > design is essential if the directory is to be effective. A user who is > looking for things will not have to much pre knowledge of an > attributes value or values.. I disagree. The version that I am preparing has examples in which this is precisely the case. They are i) a user who wants a particular schema definition ii) a user who wants a certificate with particular key usage bits (e.g. an encryption certificate) David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Wed Jul 12 07:10:09 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16080 for ; Wed, 12 Jul 2000 07:10:09 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CB0Eg12724; Wed, 12 Jul 2000 04:00:14 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CB8bQ17586; Wed, 12 Jul 2000 04:08:37 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 04:08:37 -0700 (PDT) Message-ID: <37701240971DD31193970000F6CCB9F7015249A8@duke.datcon.co.uk> From: Dave Watts To: "'Jim Sermersheim'" Cc: ietf-ldapext@netscape.com, Kurt@openldap.org Subject: RE: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt Date: Wed, 12 Jul 2000 12:08:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"wdk2gD.A.dSE.zGFb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Jim, Sorry to come in on this discussion late. There was one thing I noticed in your draft RFC - I think that you **should** consider subtypes for duplicate entries. This is more consistent with the general LDAP/X.500 rule: - subtypes count for interrogation operations - subtypes are ignored for modification operations. Regards, David -----Original Message----- From: Jim Sermersheim [mailto:JIMSE@novell.com] Sent: 15 June 2000 00:43 To: ietf-ldapext@netscape.com; Kurt@OpenLDAP.org Subject: Re: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt >>> "Kurt D. Zeilenga" 6/14/00 12:14:53 PM >>> >How does this control behave in the face of subtypes of the >provided AttributeDescriptions? If an attribute is specified, only that attribute is considered for returning duplicate entries, subtypes of that attribute are not considered. I'll add text to make this clear. From list@netscape.com Wed Jul 12 07:26:08 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16583 for ; Wed, 12 Jul 2000 07:26:08 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CBHLU14890; Wed, 12 Jul 2000 04:17:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CBM6A20596; Wed, 12 Jul 2000 04:22:06 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 04:22:06 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C54B238@aspams01.cai.com> From: "Lloyd, Alan" To: d.w.chadwick@salford.ac.uk Cc: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft Date: Wed, 12 Jul 2000 21:22:02 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"hE-WK.A.7AF.dTFb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David - Yes a case can always be made for something - In fact in my early days in manchester (ICL) we designed machines and systems that had 600 + User features on their screens - But in operational reality mode - in a real survey , it said that the human users only used 15% of these features because they did not understand the rest... In these cases with complex filters - one relies on the user to have a lot of pre and detailed knowledge.. This for 99.99% of the directory searches I see is not the case. In fact we built an advanced search screen into our DAP DXplorer to give the user access to complex filters (ANDs, ORs, NOTs etc) - and guess what - In addition component matching rules are really good for searching for certificates and CRls (as per the standard) and and other complex attributes because one can characterise the search properties on the client screen with the order of the construction and the attribute types within the compound attribute.. That is why we are applying Cert and CRL component matching rules.. and other component matching capabilities. How do expect a normal "user" to know what all the fields in a cert,crl, compound attribute, etc are it by name, value and syntax...? So IMHO - some of the argument breaks down when considered operationally - in that a user must have the mind of a directory schema management module to use this stuff - and if it does not work, ie because it isnt supported - they have to revert to look and see methods anyway. The point is... the feature is questionabe for general use and needs a schema, directory filter expert to use it. As for mail lists - sounds like, begins with, etc deal with most of the partial access/retrieval issues. And just becuause we have a compound attribute for schema publication - to be used by engineering types - it does not necessarily follow - that we need to pile more filter features added on to all the products - just to see bits of it. After all, If I have a file, an image or a document as an attribute - do we now need a filter extension to count the words, pixels in them? woops.... regards as always alan -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] Sent: Wednesday, July 12, 2000 8:49 PM To: Lloyd, Alan Cc: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft From: "Lloyd, Alan" To: Bruce Greenblatt , d.w.chadwick@salford.ac.uk, "Kurt D. Zeilenga" Copies to: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft Date sent: Wed, 12 Jul 2000 15:05:32 +1000 > My personal view.. > > I agree with Bruce.. a directory is a common repository for many > applications and users.. It follows that those using it are "looking > for things fast" or browsing. It follows that good, predicatble schema > design is essential if the directory is to be effective. A user who is > looking for things will not have to much pre knowledge of an > attributes value or values.. I disagree. The version that I am preparing has examples in which this is precisely the case. They are i) a user who wants a particular schema definition ii) a user who wants a certificate with particular key usage bits (e.g. an encryption certificate) David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Wed Jul 12 07:26:55 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16652 for ; Wed, 12 Jul 2000 07:26:54 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CBGqg14416; Wed, 12 Jul 2000 04:16:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CBPFQ21679; Wed, 12 Jul 2000 04:25:15 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 04:25:15 -0700 (PDT) Message-Id: <200007121125.HAA16571@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ldapext@netscape.com From: The IESG Subject: Protocol Action: LDAP Extensions for Scrolling View Browsing of Search Results to Proposed Standard Date: Wed, 12 Jul 2000 07:25:08 -0400 Sender: scoya@cnri.reston.va.us Resent-Message-ID: <"Hz7H_B.A.XSF.aWFb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com The IESG has approved the Internet-Draft 'LDAP Extensions for Scrolling View Browsing of Search Results' as a Proposed Standard. This document is the product of the LDAP Extension Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom. Technical Summary This document describes a Virtual List View control extension for the LDAP Search operation. This control is designed to allow the "virtual list box" feature, common in existing commercial e-mail address book applications, to be supported efficiently by LDAP servers. LDAP servers' inability to support this client feature is a significant impediment to LDAP replacing proprietary protocols in commercial e-mail systems. The control allows a client to specify that the server return, for a given LDAP search with associated sort keys, a contiguous subset of the search result set. This subset is specified in terms of offsets into the ordered list, or in terms of a greater than or equal comparison value. Working Group Summary The working group had consensus on producing this paper even though a similar functionality exists already in "Simple Paged Results" which is specified in RFC 2696 (as described in section 8 of this document). Protocol Quality Patrik Faltstrom reviewed the document for the IESG. From list@netscape.com Wed Jul 12 08:35:05 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19167 for ; Wed, 12 Jul 2000 08:35:05 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CCSVU19493; Wed, 12 Jul 2000 05:28:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CCXGI05874; Wed, 12 Jul 2000 05:33:16 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 05:33:16 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Lloyd, Alan" , ietf-ldapext@netscape.com Date: Wed, 12 Jul 2000 13:32:35 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: Revised Matched Values Draft Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <396C7373.29861.2E947DB@localhost> Priority: normal In-reply-to: <11981F9F5649D411BC92009027D0D18C54B238@aspams01.cai.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"_gCpX.A.QbB.KWGb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT > David - Yes a case can always be made for something - In fact in my > early days in manchester (ICL) we designed machines and systems that > had 600 + User features on their screens - But in operational reality > mode - in a real survey , it said that the human users only used 15% > of these features because they did not understand the rest... > I agree. Same goes for Word and other general purpose applications. However, different types of clients will need different features. I would not expect a PKI LDAP client to be the same as a general browse client (and indeed it is not in Netscape for example) > In these cases with complex filters - one relies on the user to have a > lot of pre and detailed knowledge.. No, it should be the user interface that has the knowledge, not the user. So for example, I retrieve an attribute and the interface does not understand it, but the interface knows how to construct a search to fetch the single schema definition. This could even be done automatically without any user intervention. It is not necessarily an engineer that uses this feature. Or, I want to fetch an encryption certificate to send an email, so, the interface software knows hows to construct the search operation, but has a very simplified screen display to the user. Ultimately, you cannot escape from the user interface having to know about the directory schema. You client (Dxplorer - still one of the best on the market to my mind, and free at that) has the complete X.501 schema built into it and can be configured to know about more elements. However what it is missing in Dxplorer is knowing for example that ordering matching is not applicable to telephone numbers or titles. It allows the user to try these out and get an error from the server. So an enhanced Dxplorer would know that when I am searching for a certificate that certificateExactMatch and certificateMatch should be used and bring up an appropriate display for this. All the user needs to know is i) I want to find a certificate ii) the display shows me the types I can search for iii) the display optionally asks me about validity periods iv) the display optionally asks me which CA I am interested in etc. etc. The point is, the user does not need to know the schema, the client software does, and it should guide the user through this. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Wed Jul 12 09:06:16 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20695 for ; Wed, 12 Jul 2000 09:06:15 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CCPoU18907; Wed, 12 Jul 2000 05:25:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CCUZ604532; Wed, 12 Jul 2000 05:30:35 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 05:30:35 -0700 (PDT) Message-Id: <200007121220.IAA01263@roadblock.missi.ncsc.mil> From: "Miklos, Sue A." To: "'Lloyd, Alan'" , Bruce Greenblatt , d.w.chadwick@salford.ac.uk, "Kurt D. Zeilenga" Cc: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft Date: Wed, 12 Jul 2000 08:31:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Resent-Message-ID: <"Q--G6B.A.fGB.qTGb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com All, I can think of instances where there may be many values in an attribute, but they are mostly related to mail lists. I have requirements to be able to manage varying sizes of lists (AllMil which is essentially a series of nested lists, down to smaller, 10-30 member lists). Can this narrow requirement be managed through superior schema design, or do I need to be able to match on member characteristics (name?) to selectively delete/update the information? Regards, Sandi -----Original Message----- From: Lloyd, Alan [mailto:Alan.Lloyd@ca.com] Sent: Wednesday, July 12, 2000 1:06 AM To: Bruce Greenblatt; d.w.chadwick@salford.ac.uk; Kurt D. Zeilenga Cc: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft My personal view.. I agree with Bruce.. a directory is a common repository for many applications and users.. It follows that those using it are "looking for things fast" or browsing. It follows that good, predicatble schema design is essential if the directory is to be effective. A user who is looking for things will not have to much pre knowledge of an attributes value or values.. Too many values (more than 8 say) is NOT good schema design - ie. having 200 values and reading an entry (all) will clutter the browser.. What happens with this - if a full sequence of all 7 filter values are used on all values - eg the lot on all values eg.. exact match, sounds like, substring, begins with, ends with - what gets returned? In the case of human users, how many will be trained to understand critical extensions and Sequences of Value filters? Doesnt "sounds like" do this job? regards alan -----Original Message----- From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] Sent: Wednesday, July 12, 2000 11:02 AM To: d.w.chadwick@salford.ac.uk; Kurt D. Zeilenga Cc: ietf-ldapext@netscape.com Subject: Re: Revised Matched Values Draft I'll voice the same reservations this time that I voiced last time. Use of this control solves a problem that normally exists due to poor schema and DIT design. There is no obvious reason why an entry should have so many values of an attribute that an LDAP client would have a problem retrieving them all. Do not put hundreds of values (or however many you have in mind) in the attribute. The introduction uses the userCertificate attribute as an example. While it is true that a single user in the real world may have numerous certificates, this should not translate into an LDAP entry that has numerous userCertificate attribute values. IMHO, this is poor schema/DIT design. By creating this control, we only encourage this type of design, when we really need to discourage it. In my mind it is analogous to encouraging non-normalized SQL schemas. I wrote a little draft a while back (http://www.ietf.org/internet-drafts/draft-greenblatt-ldap-certinfo-schema-0 2.txt) that recommends a schema/DIT design for holding certificate information in the schema that allows for selective retrieval of certificates without requiring any protocol extensions (or even any new syntaxes). I have had several people ask me privately about this draft with indications that they were interested in implementing it. Additionally, I believe that implementation of this control could place an unnecessary burden on the server for sifting through the attribute values, when it should be done on the client (perhaps this is more of a stylistic issue). In any case, I would not be in favor of promoting this draft along the standards track. Last time this came up, and I voice this same objection to the draft, I received several notes supporting my position. I think that we need to think carefully about what kinds of protocol extension that should be standardized, and how they benefit LDAP applications. In my mind this extension provides no benefits to LDAP applications. Bruce **************************************************************************** * This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **************************************************************************** ** From list@netscape.com Wed Jul 12 09:15:05 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20990 for ; Wed, 12 Jul 2000 09:15:04 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CCo0g20523; Wed, 12 Jul 2000 05:50:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CCwMo12094; Wed, 12 Jul 2000 05:58:22 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 05:58:22 -0700 (PDT) Sender: Ludovic.Poitou@france.Sun.COM Message-ID: <396C6B1F.771BB165@France.sun.com> Date: Wed, 12 Jul 2000 14:57:03 +0200 From: Ludovic Poitou Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com Subject: [Fwd: I-D ACTION:draft-behera-ldap-password-policy-02.txt] Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"-nXQL.A.T8C.ttGb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit LDAPEXTers,

Could you please review and comment the following internet draft ?

Changes from previous version :
- Changed the pwdGraceLeft attribute (integer counter) into a pwdGraceUseTime (UTCTime).
- Updated the security section.
- Minor editing changes.

Thanks,

Ludovic.

Internet-Drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Password Policy for LDAP Directories
        Author(s)       : P. Behera, V. Chu, L. Poitou, J. Sermersheim
        Filename        : draft-behera-ldap-password-policy-02.txt
        Pages           : 27
        Date            : 11-Jul-00

Password policy is a set of rules that controls how passwords are
used in LDAP directories. In order to improve the security of LDAP
directories and make it difficult for password cracking programs to
break into directories, it is desirable to enforce a set of rules on
password usage.  These rules are made to ensure that users change
their passwords periodically, passwords meet construction
requirements, the re-use of old password is restricted, and users
are locked out after a certain number of failed attempts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-behera-ldap-password-policy-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-behera-ldap-password-policy-02.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.
 

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

  ------------------------------------------------------------------------
Content-Type: text/plain
Content-ID:     <20000711134749.I-D@ietf.org>

-- 
Ludovic Poitou
Sun Microsystems Inc.
iPlanet E-Commerce Solutions - Directory Group - Grenoble - France
  From list@netscape.com Wed Jul 12 09:55:25 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22933 for ; Wed, 12 Jul 2000 09:55:24 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CDUqg23563; Wed, 12 Jul 2000 06:30:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CDdFg21986; Wed, 12 Jul 2000 06:39:15 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 06:39:15 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C54B3B4@aspams01.cai.com> From: "Lloyd, Alan" To: "Miklos, Sue A." , Bruce Greenblatt , d.w.chadwick@salford.ac.uk, "Kurt D. Zeilenga" Cc: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft Date: Wed, 12 Jul 2000 23:38:33 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"ZG8YlC.A.UVF.9THb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Sue - the issues of nested lists - is a good one - and with directory operators - what would be the approach to find a memeber three levels down if "fuzzy searching" is applied in a nested sequence - and the accuracy or concept of searching is open to the user..? I always tend to think (and please dont debate that point on the list) that where compound information and relationship issues exist on directory information, its better to have a directory enabled utility to manage that ie "find and clear duplicate or really old certs".. "provide mail list hierarchies where end users have...name, properties, etc." ie dont update protocols - have functional utilities.. How does an SQL application get more functionality?... they dont keep updating the SQL standard do they? This utility approach is far less damaging to directory suppliers who have to go through formal releases of software to thousands of users - with online deployed global systems - because of a specific or theoretical requirement from somewhere..that only deals one instance a problem related to the multi value, nested refernces and operationally related information. Does the utility idea - sound useful for managing lists? Isnt it amazing that the reason for LDAP was that DAP was too complex - and here we are (years later) adding more complexity to LDAP beyond that of DAP..:-) regards alan -----Original Message----- From: Miklos, Sue A. [mailto:samiklo@missi.ncsc.mil] Sent: Wednesday, July 12, 2000 10:31 PM To: Lloyd, Alan; Bruce Greenblatt; d.w.chadwick@salford.ac.uk; Kurt D. Zeilenga Cc: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft All, I can think of instances where there may be many values in an attribute, but they are mostly related to mail lists. I have requirements to be able to manage varying sizes of lists (AllMil which is essentially a series of nested lists, down to smaller, 10-30 member lists). Can this narrow requirement be managed through superior schema design, or do I need to be able to match on member characteristics (name?) to selectively delete/update the information? Regards, Sandi -----Original Message----- From: Lloyd, Alan [mailto:Alan.Lloyd@ca.com] Sent: Wednesday, July 12, 2000 1:06 AM To: Bruce Greenblatt; d.w.chadwick@salford.ac.uk; Kurt D. Zeilenga Cc: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft My personal view.. I agree with Bruce.. a directory is a common repository for many applications and users.. It follows that those using it are "looking for things fast" or browsing. It follows that good, predicatble schema design is essential if the directory is to be effective. A user who is looking for things will not have to much pre knowledge of an attributes value or values.. Too many values (more than 8 say) is NOT good schema design - ie. having 200 values and reading an entry (all) will clutter the browser.. What happens with this - if a full sequence of all 7 filter values are used on all values - eg the lot on all values eg.. exact match, sounds like, substring, begins with, ends with - what gets returned? In the case of human users, how many will be trained to understand critical extensions and Sequences of Value filters? Doesnt "sounds like" do this job? regards alan -----Original Message----- From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] Sent: Wednesday, July 12, 2000 11:02 AM To: d.w.chadwick@salford.ac.uk; Kurt D. Zeilenga Cc: ietf-ldapext@netscape.com Subject: Re: Revised Matched Values Draft I'll voice the same reservations this time that I voiced last time. Use of this control solves a problem that normally exists due to poor schema and DIT design. There is no obvious reason why an entry should have so many values of an attribute that an LDAP client would have a problem retrieving them all. Do not put hundreds of values (or however many you have in mind) in the attribute. The introduction uses the userCertificate attribute as an example. While it is true that a single user in the real world may have numerous certificates, this should not translate into an LDAP entry that has numerous userCertificate attribute values. IMHO, this is poor schema/DIT design. By creating this control, we only encourage this type of design, when we really need to discourage it. In my mind it is analogous to encouraging non-normalized SQL schemas. I wrote a little draft a while back (http://www.ietf.org/internet-drafts/draft-greenblatt-ldap-certinfo-schema-0 2.txt) that recommends a schema/DIT design for holding certificate information in the schema that allows for selective retrieval of certificates without requiring any protocol extensions (or even any new syntaxes). I have had several people ask me privately about this draft with indications that they were interested in implementing it. Additionally, I believe that implementation of this control could place an unnecessary burden on the server for sifting through the attribute values, when it should be done on the client (perhaps this is more of a stylistic issue). In any case, I would not be in favor of promoting this draft along the standards track. Last time this came up, and I voice this same objection to the draft, I received several notes supporting my position. I think that we need to think carefully about what kinds of protocol extension that should be standardized, and how they benefit LDAP applications. In my mind this extension provides no benefits to LDAP applications. Bruce **************************************************************************** * This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **************************************************************************** ** From list@netscape.com Wed Jul 12 10:13:21 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23727 for ; Wed, 12 Jul 2000 10:13:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CE6AU26954; Wed, 12 Jul 2000 07:06:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CEAtE02271; Wed, 12 Jul 2000 07:10:55 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 07:10:55 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C54B3F6@aspams01.cai.com> From: "Lloyd, Alan" To: d.w.chadwick@salford.ac.uk Cc: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft Date: Thu, 13 Jul 2000 00:10:53 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"80vMzB.A.Kj.uxHb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com A "for ever" debate ! - > In these cases with complex filters - one relies on the user to have a > lot of pre and detailed knowledge.. No, it should be the user interface that has the knowledge, order..not the user. Alan: NO the user interface has the mechanisms to display syntax - and the pre defined procedures and configuration to get the displays in order - I dont call this knowledge.. I call this "configuration" . The user applies their "knowledge" to interpret what has been displayed for the purpose required. So for example, I retrieve an attribute and the interface does not understand it, but the interface knows how to construct a search to fetch the single schema definition. This could even be done automatically without any user intervention. Alan: Oh I see - we dont know what this is - but we do know what the syntax of this is (what ever it is)... and then we will generate the code to graphically display that syntax that we guessed - ? It is not necessarily an engineer that uses this feature. Or, I want to fetch an encryption certificate to send an email, so, the interface software knows hows to construct the search operation, but has a very simplified screen display to the user. Alan: thats OK - directory enabled client applications should be doing the detailed directory work.. Ultimately, you cannot escape from the user interface having to know about the directory schema. You client (Dxplorer - still one of the best on the market to my mind, and free at that) has the complete X.501 schema built into it and can be configured to know about more elements. Alan: Yes - we know... However what it is missing in Dxplorer is knowing for example that ordering matching is not applicable to telephone numbers or titles. Alan: One needs semantic information to order things - eg Rank - Geographical points, etc..So who is standardising on that then.. What happens when a new value is stored - ie when in London how do you deal with entries that have a row of cities and you need to order them according to "local" distance?? See my other response to Sandi - re mail lists.. and application specific directory utilities. It allows the user to try these out and get an error from the server. So an enhanced Dxplorer would know that when I am searching for a certificate that certificateExactMatch and certificateMatch should be used and bring up an appropriate display for this. All the user needs to know is i) I want to find a certificate ii) the display shows me the types I can search for iii) the display optionally asks me about validity periods iv) the display optionally asks me which CA I am interested in etc. etc. Alan: watch out for "certificate and CRL component matching"... :-) The point is, the user does not need to know the schema, the client software does, and it should guide the user through this. Alan: and being a logical person - the client needs to be configured with the syntax of the schema - and from a user perspective if I am guided through something and making decisions about the next step, then I must be using knowledge of the schema and its values relative to my comprension of what I want and where I want to be... If I dont have any knowledge of anything at the start or at the end of the process... how and why did I use a directory in the first place - and how can I remember any results or how I got them.. :_)) Ooooh look - I just got data... regards - and send us a pack of Boddies (beer) if you can. alan David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Wed Jul 12 11:16:01 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27026 for ; Wed, 12 Jul 2000 11:16:01 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CEecU29953; Wed, 12 Jul 2000 07:40:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CEjOc12358; Wed, 12 Jul 2000 07:45:24 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 07:45:24 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Lloyd, Alan" , ietf-ldapext@netscape.com Date: Wed, 12 Jul 2000 15:44:30 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: Revised Matched Values Draft Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <396C925E.29828.3621323@localhost> Priority: normal In-reply-to: <11981F9F5649D411BC92009027D0D18C54B3F6@aspams01.cai.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"GOXXFD.A.hAD.CSIb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date forwarded: Wed, 12 Jul 2000 07:10:56 -0700 (PDT) From: "Lloyd, Alan" To: d.w.chadwick@salford.ac.uk Copies to: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft Date sent: Thu, 13 Jul 2000 00:10:53 +1000 Forwarded by: ietf-ldapext@netscape.com > A "for ever" debate ! Cut David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Wed Jul 12 11:47:17 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28742 for ; Wed, 12 Jul 2000 11:47:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CFN4g04548; Wed, 12 Jul 2000 08:23:04 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CFVRQ00611; Wed, 12 Jul 2000 08:31:27 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 08:31:27 -0700 (PDT) Message-Id: <4.3.2.7.0.20000712074920.00b22a80@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jul 2000 07:55:03 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: String Encodings - was RE: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3" In-Reply-To: <000501bfea15$d3b65d20$b05508cb@osmium.adacel.com.au> References: <3.0.5.32.20000706083011.00926a70@pop.walltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"3Rru.A.NJ.N9Ib5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Regardless of whether you use a string representation or a BER/DER representation of a value of a particular syntax, you need to define an LDAPsyntaxes and appropriate matchingRules (and code that implements them) if you want your server to check/match per the syntax. Otherwise, to the server, it's just a BLOB. Kurt From list@netscape.com Wed Jul 12 13:14:23 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02986 for ; Wed, 12 Jul 2000 13:14:21 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CGbVU13604; Wed, 12 Jul 2000 09:37:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CGgGc05322; Wed, 12 Jul 2000 09:42:16 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 09:42:16 -0700 (PDT) Date: Wed, 12 Jul 2000 09:42:10 -0700 (PDT) Message-Id: <200007121642.e6CGg9x21555@ywing.netscape.com> From: Frank_Kennedy To: Dear.Business.Opportunity.Seeker@netscape.com Subject: Outstanding Business Opportunity X-Reply-To: Frank_Kennedy1@excite.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"g_mAED.A.nSB.m_Jb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Would you like to be a part of a business opportunity that sells world wide, offers products that people want/need and are exclusive, requires minimal labor and very little overhead? Would you like a career that offers an excellent opportunity for personal growth, excitement and intellectual development? I know it sounds too good to be true, but it's not. It is very much real and available to you right NOW! If you are interested in an Internet based business where you can earn what you are worth while helping people at the same time, reply tome today. Thank you for your time, Frank Kennedy Please pardon the intrusion.... Under Bill s.1618 TITLE III passed by the 105th US Congress this letter can not be considered Spam as long as the sender includes contact information & a method of "removal". To be removed from future mailings just reply with REMOVE in the subject line. Thank you for your kind consideration From list@netscape.com Wed Jul 12 14:14:27 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06499 for ; Wed, 12 Jul 2000 14:14:27 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CI04g26341; Wed, 12 Jul 2000 11:00:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CI6fg14034; Wed, 12 Jul 2000 11:06:41 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 11:06:41 -0700 (PDT) Message-Id: <4.3.2.7.0.20000712095723.00aedef0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jul 2000 10:04:45 -0700 To: "Lloyd, Alan" From: "Kurt D. Zeilenga" Subject: RE: Revised Matched Values Draft Cc: "Miklos, Sue A." , Bruce Greenblatt , d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com In-Reply-To: <11981F9F5649D411BC92009027D0D18C54B3B4@aspams01.cai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"zQ7x5C.A.lXD.pOLb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:38 PM 7/12/00 +1000, Lloyd, Alan wrote: >Isnt it amazing that the reason for LDAP was that DAP was too complex - and >here we are (years later) adding more complexity to LDAP beyond that of >DAP..:-) > regards alan The primary complexity of DAP that LDAP removed was need to implement the ISO protocol stack. As far as other so-called simplications made, I would argue that many of them have actually made things more complex. Note that in X.500/DAP, a client did not need to discover the syntax of attributes simply to browse a directory... now everything is a BLOB until the client reads and recognizes syntaxes of values as published in the subschema. From list@netscape.com Wed Jul 12 14:45:32 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08326 for ; Wed, 12 Jul 2000 14:45:31 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CINGg00025; Wed, 12 Jul 2000 11:23:17 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CIVeA23733; Wed, 12 Jul 2000 11:31:40 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 11:31:40 -0700 (PDT) Sender: Sean.Mullan@ireland.Sun.COM Message-ID: <396CB983.81DC54B3@sun.com> Date: Wed, 12 Jul 2000 19:31:31 +0100 From: Sean Mullan X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: d.w.chadwick@salford.ac.uk CC: ietf-pkix@imc.org, ietf-ldapext@netscape.com Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt References: <200007121032.GAA15215@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BRGnGB.A.eyF.KmLb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hi David, Some comments on the draft below. Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. > > Title : Internet X.509 Public Key Infrastructure Additional > LDAP Schema for PKIs and PMIs > Author(s) : D. Chadwick > Filename : draft-ietf-pkix-ldap-schema-00.txt > Pages : 11 > Date : 11-Jul-00 Section 3.2 Certificate Match I think the X.509 certificate matching rules are missing some essential and important fields in the certificateAssertion structure for filtering on certificates. We may want to consider defining a superset. I submitted these comments to the X.509 editors but apparently it was too late to integrate them into the 2000 update. * you should be able to match on more than one pathToName and on non-X500 name types. This is inconsistent with name constraints which allow you to constrain to more than one name and different name types. * you should be able to match on more than the subject alt name type. You should also be able to match on the subject alt name itself, and specify more than one subject alt name as certificates can contain more than one. * you should be able to match on the subject public key as well as the subject public key algorithm OID. * you should be able to match on the basic constraints extension, especially the maxPathLen value. This is useful for finding potential certificates when building certification paths from the target to the most-trusted CA. For ex, if a partial path has been built, any candidate certificate must have a maxPathLen value greater than or equal to the number of certificates in the partial path. I think it is very important to include the Certificate pair matching rules, as these are very useful when building certification paths and trying to discover which of many cross certificates satisfy various validation constraints, and eliminating those that do not. Other comments: * What RFC format are you using for the encoding of DNs - 1779? This should be referenced. Section 4.2 Certificate List Match There is an error in the CertificateListAssertion definition in X.509 2000. The authorityKeyIdentifier component should be marked OPTIONAL. This probably doesn't affect your definition, but I just wanted to make you aware of it. --Sean From list@netscape.com Wed Jul 12 14:53:56 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08737 for ; Wed, 12 Jul 2000 14:53:55 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CIWVg01867; Wed, 12 Jul 2000 11:32:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CIesY27574; Wed, 12 Jul 2000 11:40:54 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 11:40:54 -0700 (PDT) Sender: Sean.Mullan@ireland.Sun.COM Message-ID: <396CBBAF.39D848B6@sun.com> Date: Wed, 12 Jul 2000 19:40:47 +0100 From: Sean Mullan X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: d.w.chadwick@salford.ac.uk, ietf-pkix@imc.org, ietf-ldapext@netscape.com Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt References: <200007121032.GAA15215@ietf.org> <396CB983.81DC54B3@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"gkv6uD.A.cuG.1uLb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit One other comment - I have mentioned this previously when commenting on RFC 2587, but as of yet no changes have been made. Building certification paths in a 'reverse' direction (from trust anchor to EE) is a valid way to build certification paths. However, RFC 2587 (PKIX LDAPv2 schema) specifies that the storage of cross certificates in the reverse component of the crossCertificatePair is optional. It is not possible to efficiently build a certification path in a 'reverse' direction unless the certificates are populated in the reverse component of the crossCertificatePair attribute. Specifying that this feature is optional makes it difficult to build paths in a reverse direction in a trust model where lots of cross certificates and multiple directories are involved and you don't know if the CAs support the optional storage. I would like to suggest that RFC 2587 be amended/updated to make storage of cross certificates in the reverse component of the crossCertificatePair attribute mandatory. Thanks, Sean Sean Mullan wrote: > > Hi David, > > Some comments on the draft below. > > Internet-Drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. > > > > Title : Internet X.509 Public Key Infrastructure Additional > > LDAP Schema for PKIs and PMIs > > Author(s) : D. Chadwick > > Filename : draft-ietf-pkix-ldap-schema-00.txt > > Pages : 11 > > Date : 11-Jul-00 > > Section 3.2 Certificate Match > > I think the X.509 certificate matching rules are missing some essential and > important fields in the certificateAssertion structure for filtering on > certificates. We may want to consider defining a superset. I submitted these > comments to the X.509 editors but apparently it was too late to integrate them > into the 2000 update. > > * you should be able to match on more than one pathToName and on non-X500 > name types. This is inconsistent with name constraints which allow you > to constrain to more than one name and different name types. > > * you should be able to match on more than the subject alt name type. You > should also be able to match on the subject alt name itself, and specify more than > one subject alt name as certificates can contain more than one. > > * you should be able to match on the subject public key as well as the subject public > key algorithm OID. > > * you should be able to match on the basic constraints extension, especially the > maxPathLen value. This is useful for finding potential certificates when > building certification paths from the target to the most-trusted CA. For ex, > if a partial path has been built, any candidate certificate must have a > maxPathLen value greater than or equal to the number of certificates in the > partial path. > > I think it is very important to include the Certificate pair matching rules, as > these are very useful when building certification paths and trying to discover > which of many cross certificates satisfy various validation constraints, and eliminating > those that do not. > > Other comments: > > * What RFC format are you using for the encoding of DNs - 1779? This should be referenced. > > Section 4.2 Certificate List Match > > There is an error in the CertificateListAssertion definition in X.509 2000. The > authorityKeyIdentifier component should be marked OPTIONAL. This probably doesn't > affect your definition, but I just wanted to make you aware of it. > > --Sean From list@netscape.com Wed Jul 12 16:47:14 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14323 for ; Wed, 12 Jul 2000 16:47:12 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6CKeSU21579; Wed, 12 Jul 2000 13:40:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6CKjEI24810; Wed, 12 Jul 2000 13:45:14 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 13:45:14 -0700 (PDT) Message-Id: <200007122043.WAA03944@catalogix.ac.se> X-Mailer: exmh version 2.1.1 10/15/1999 To: internet-drafts@ietf.org cc: ietf-ldapext@netscape.com Subject: New draft on knowledge references in LDAP Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1135548320" Date: Wed, 12 Jul 2000 22:43:23 +0200 From: Roland Hedberg Resent-Message-ID: <"EDRRh.A.RDG.YjNb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multipart MIME message. --==_Exmh_1135548320 Content-Type: text/plain; charset=us-ascii Could you please publish the attached draft. -- Roland ------------------------------------------------ Roland Hedberg phone : +47 23 08 29 96 Dalsveien 53 mobile(NO): +47 90 66 44 52 No-0775 Oslo mobile(SE): +46 70 520 420 3 Norway --==_Exmh_1135548320 Content-Type: text/plain ; name="draft-ietf-ldapext-refer-00.txt"; charset=us-ascii Content-Description: draft-ietf-ldapext-refer-00.txt Content-Disposition: attachment; filename="draft-ietf-ldapext-refer-00.txt" IETF LDAPEXT Working Group Roland Hedberg Internet-Draft Catalogix Expires: January 12, 2000 July 12, 2000 Referrals in LDAP Directories Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 January 12, 2000. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Hedberg Expires September 30, 2000 [Page 1] Internet-Draft LDAP Knowledge references July 2000 Abstract This document defines two reference attributes and associated "referral" object class for representing generic knowledge information in LDAP directories [RFC2251]. The attribute uses URIs [RFC1738] to represent knowledge, enabling LDAP and non-LDAP services alike to be referenced. The object class can be used to construct entries in an LDAP directory containing references to other directories or services. This document also defines procedures directory servers should follow when supporting these schema elements and when responding to requests for which the directory server does not contain the requested object but may contain some knowledge of the location of the requested object. 1. Background and intended usage The broadening of interest in LDAP directories beyond their use as front ends to X.500 directories has created a need to represent knowledge information in a more general way. Knowledge information is information about one or more servers maintained in another server, used to link servers and services together. This document is based on the following basic assumptions: - several naming domains The usage of LDAP as a access protocol to other than X.500 servers has created islands of directory service systems containing one or more LDAP servers. Each of these islands are free to pick their own naming domain. And that they also do; some use the old country,organization, organizationalUnit naming scheme[X.521], some use the newer domain name based naming scheme but these two are in no way the only ones in use. The existence of several naming domains are in itself no real problem as long as they produce unique names for the objects in the directory. Still naming schemes like the domain name based one, might easily create non-continues naming structures because some toplevel domain names might no find organizations that are interested and/or willing to manage them. Therefor tree transversal might not longer be possible except in parts of the whole tree. - authoritive structure vs directory structure In some instances even if a part of the tree is delegated to one organization, the organization doing the delegation might want to remain as the authority for the baseobject of the delegated tree. - support for onelevel searches At points in the tree where the responsibility for all or almost all of the children of a object is delegated to different organizations and resides in different directory servers a one-level search is not very efficient if not supported by special facilities in the directory as such. Hedberg Expires September 30, 2000 [Page 2] Internet-Draft LDAP Knowledge references July 2000 -- directory server discovery LDAP servers that do not use dc nameing or are not registered with SRV records in the DNS are very hard to find. This document defines a general method of representing knowledge information in LDAP directories, based on URIs. Two types of knowledge reference are defined: refer and subRefer. The key words "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [RFC2119]. 2. Knowledge references 2.1 The refer attribute ( 1.2.752.17.1.100 NAME 'refer' DESC 'URL reference' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE distributedOperation ) The refer attribute type has IA5 syntax and is case sensitive. It is multivalued. Values placed in the attribute MUST conform to the specification given for the labeledURI attribute as defined in [RFC2079]. The labeledURI specification defines a format that is a URI, optionally followed by whitespace and a label. This document does not make use of the label portion of the syntax. Future documents MAY enable new functionality by imposing additional structure on the label portion of the syntax as it appears in a refer attribute. If the URI contained in a refer attribute refers to an LDAP server, it must be in the LDAP URI format described in [RFC2255]. When returning a referral result, the server must not return the label portion of the labeledURI as part of the referral. Only the URI portion of the refer attributes should be returned. The refer attribute can be further specified by the use of options as defined in section 4.1.5 of [RFC2251]. This document defines five options and their use. Future documents might defined other options. The options defined are: "me", "sup", "cross", "nssr" and "sub" . 'refer;me' is used to hold the reference of this server, and is always held in the root DSE 'refer;sup' is used to hold the reference of a server superior to this one in this global LDAP naming domain e.g. a server holding the dc=com, dc=se, or the c=se node. The 'refer;sup' is always held in the root DSE. Hedberg Expires September 30, 2000 [Page 3] Internet-Draft LDAP Knowledge references July 2000 'refer;cross' indicates that this is a cross reference pointing to another naming context within or outside this global LDAP naming domain. 'refer;sub' indicates that this is a subordinate reference pointing to a subordinate naming context in this global LDAP naming domain. 'refer;nssr' indicates that this is a non-specific subordinate reference pointing to a subordinate naming context in this global LDAP naming domain. 3. Use of the knowledge attribute Except when the manageDsaIT control (documented in section 6 of this document) is present in the operation request, the refer attribute is not visible to clients, except as its value is returned in referrals or con- tinuation references. If the manageDsaIT control is not set, and the entry named in a request contains the refer attribute, and the entry is not the root DSE, the server returns an LDAPResult with the resultCode field set to "referral" and the referral field set to contain the value(s) of the refer attribute minus any optional trailing whitespace and labels that might be present. If the manageDsaIT control is not set, and an entry containing the ref attribute is in the scope of a one level or subtree search request, the server returns a SearchResultReference for each such entry containing the value(s) of the entry's refer attribute. When the manageDsaIT control is present in a request, the server will treat an entry containing the refer attribute as an ordinary entry, and the refer attribute as an ordinary attribute, and the server will not return referrals or continuation references corresponding to refer attributes. 4 Behaviour specification 4.1 Name resolution for any operation Clients SHOULD perform at least simple "depth-of-referral count" loop detection by incrementing a counter each time a new set of referrals is received. (The maximum value for this count SHOULD be twice the number of RDNs in the target object less one, to allow for ascending and descending the DIT.) Clients MAY perform more sophisticated loop detection, for example not chasing the same referral twice. Case 1: The target entry is not held by the server and is superior to some entry held by the server. If the server DSE contains a "refer;sup" attribute then the server will return an LDAPResult with the result code field set Hedberg Expires September 30, 2000 [Page 4] Internet-Draft LDAP Knowledge references July 2000 to referral, and the referral field set to contain the value(s) of the "refer;sup" attribute minus any optional trailing whitespace and labels that might be present. Case 2: The target entry is not held by the server and is subordinate to some entry, held by the server, that contains a refer attribute. The server will return an LDAPResult with the result code field set to referral, and the referral field set to contain the value(s) of the refer attribute minus any optional trailing whitespace and labels that might be present. Case 3: The target entry is held by the server and contains a refer attribute without the 'nssr' option. The server will return an LDAPResult with the result code field set to referral, and the referral field set to contain the value(s) of the refer attribute minus any optional trailing whitespace and labels that might be present. Case 4: The target entry is not held by the server, and is not subordinate or superior to any object held by the server. If the server contains a "refer;cross" attribute in the root DSE with a baseobject that is either the same or superior to the target entry then the server will return an LDAPResult with the result code field set to referral, and the referral field set to contain the value(s) of these refer attributes minus any optional trailing whitespace and labels that might be present. 4.2 Search evaluation For search operations, once the base object has been found and determined NOT to contain a refer attribute without the 'nssr' option, the search may progress. 4.2.1 base-level If the entry matches the filter and does NOT contain a refer attribute it will be returned to the client as described in [RFC2251]. If the entry matches the filter contains a refer attribute without the 'nssr' option it will be returned as a referral as described here. If a matching entry contains a refer attribute and the URI contained in the refer attribute is NOT an LDAP URI [RFC2255], the server should return the URI value contained in the refer attribute of that entry in a SearchResultReference. Hedberg Expires September 30, 2000 [Page 5] Internet-Draft LDAP Knowledge references July 2000 If a matching entry contains a refer attribute in the LDAP URI syntax, the server will return an SearchResultReference containing the value(s) of the refer attribute minus any optional trailing whitespace and labels that might be present. The URL from the refer attribute must be modified before it is returned by adding or substituting a "base" scope into the URL. If the URL does not contain a scope specifier, the "base" scope specifier must be added. If the URL does contain a scope specifier, the existing scope specifier must be replaced by the "base" scope. 4.2.2 One-level Any entries matching the filter and one level scope that do NOT contain a refer attribute are returned to the client normally as described in [RFC2251]. Any entries matching the filter and one level scope that contains a refer attribute without the 'nssr' option must be returned as referrals as described here. If a matching entry contains a refer attribute and the URI contained in the refer attribute is NOT an LDAP URI [RFC2255], the server should return the URI value contained in the refer attribute of that entry in a SearchResultReference. If a matching entry contains a refer attribute in the LDAP URI syntax, the server will return an SearchResultReference containing the value(s) of the refer attribute minus any optional trailing whitespace and labels that might be present. The URL from the refer attribute must be modified before it is returned by adding or substituting a "base" scope into the URL. If the URL does not contain a scope specifier, the "base" scope specifier must be added. If the URL does contain a scope specifier, the existing scope specifier must be replaced by the "base" scope. 4.2.3 Subtree search evaluation Any entries, held by the server, matching the filter and subtree scope that do NOT contain a refer attribute or contains a refer attribute with the 'nssr' option are returned to the client normally as described in [RFC2251]. Any entries matching the subtree scope and containing a refer attribute must be returned as referrals as described here. If a matching entry contains a refer attribute and the URI contained in that attribute is NOT an LDAP URI [RFC2255], the server should return the URI value contained in the refer attribute of that entry in a SearchResultReference. Hedberg Expires September 30, 2000 [Page 6] Internet-Draft LDAP Knowledge references July 2000 If a matching entry contains a refer attribute in the LDAP URI syntax, the server will return an SearchResultReference containing the value(s) of the refer attribute minus any optional trailing whitespace and labels that might be present. N.B. in subtree search evaluation a entry containing a refer attribut with the 'nssr' option might appear twice in the result, first as a entry and then as a reference. A client following all references might therefore end up with a resultset containing two representations of the same entry, one from the server getting the original query and one from the server that the 'nssr' reference points to. 5. The referral object class The referral object class is defined as follows. ( 1.2.752.17.2.10 NAME 'referral' SUP top STRUCTURAL MAY ( refer ) ) The referral object class is a subclass of top and may contain the refer attribute. The referral object class should, in general, be used in conjunction with the extensibleObject object class to support the naming attributes used in the entry's distinguished name. Servers must support the refer attributes through use of the referral object class. Any named reference must be of the referral object class and will likely also be of the extensibleObject object class to support naming and use of other attributes. 6. The manageDsaIT control A client MAY specify the following control when issuing a search, com- pare, add, delete, modify, or modifyDN request. The control type is 2.16.840.1.113730.3.4.2. The control SHOULD be marked as critical. There is no value; the controlValue field is absent. This control causes entries with the knowledge reference attributes to be treated as normal entries, allowing clients to read and modify these entries. Hedberg Expires September 30, 2000 [Page 7] Internet-Draft LDAP Knowledge references July 2000 7. Superior Reference This document defines two types of knowledge references that point to parts of the naming context that is above of beyone the part held by a server. The 'sup' option when referring to a LDAP server that holds a naming context that is closer to the root of the same naming context and 'other' when referring to a LDAP server that holds a naming context that belongs to a different naming domain then the one the server belongs to. Thus if the server receives a request for an operation where the target entry is a entry closer to the root than the naming context held the server and if the server holds a 'refer;sup' attribute in the DSE, then the server MUST return an LDAPResult with the result code field set to referral, and the referral field set to contain the value(s) of the 'refer;sub' attribute minus any optional trailing whitespace and labels that might be present. On the other hand if the server receives a request for an operation where the target entry is a entry that belongs to a other naming domain and if there is any 'refer;other' attributes in the DSE with a base entry that belongs to the same naming domain as the target entry and is closer to the root then the target entry, then the server SHOULD return an LDAPResult with the result code field set to referral, and the referral field set to contain the value(s) of the 'refer;other' attribute minus any optional trailing hitespace and labels that might be present. 8. Security Considerations This document defines mechanisms that can be used to "glue" LDAP (and other) servers together. The information used to specify this glue information should be protected from unauthorized modification. If the server topology information itself is not public information, the information should be protected from unauthorized access as well. 9. References [RFC1738] Berners-Lee, T., Masinter, L., and McCahill, M., "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994, [RFC2079] M. Smith, "Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079, January 1997. Hedberg Expires September 30, 2000 [Page 8] Internet-Draft LDAP Knowledge references July 2000 [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev- els", RFC 2119, March 1997. (Format: TXT=4723 bytes) (Also BCP0014) (Status: BEST CURRENT PRACTICE) [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. 1997. [RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December, 1997. (Format: TXT=20685 bytes) (Status: PROPOSED STANDARD) [X500] ITU-T Rec. X.501, "The Directory: Models", 1993. [X521] ITU-T Rec. X.521, "---------------------", 1993. 12. Acknowledgements This draft is heavily based on the previous drafts on knowledge references in LDAP written by Christopher Lukas, Tim Howes, Michael Roszkowski, Mark C. Smith, Mark Wahl and David Chadwick. Peter Valkenburg and Henny Bekker has also made valueable contributions. 13. Authors Address Roland Hedberg Catalogix Dalsveien 53 0775 Oslo Norway EMail: Roland@catalogix.se Hedberg Expires September 30, 2000 [Page 9] Internet-Draft LDAP Knowledge references July 2000 Appendix A Example of usage. Information stored in a server. dn: objectclass: referral refer;me: ldap://hostCAT/dc=cat,dc=se refer;sup: ldap://hostSE/dc=se refer;cross: ldap://hostNO/dc=no refer;cross: ldap://hostNL/c=nl dn: dc=cat,dc=se objectclass: domain dc: cat dn: dc=one,dc=cat,dc=se objectclass: extendedObject objectclass: referral refer;nssr: ldap://hostCAT1/dc=one,dc=cat,dc=se ou: one l: umea dc: dc=two,dc=cat,dc=se objectclass: referral objectclass: extendedObject refer;sub: ldap://hostCAT2/dc=two,dc=cat,dc=se dn: dc=three,dc=cat,dc=se objectclass: referral objectclass: extendedObject refer;cross: ldap://hostCAT3/dc=cat,dc=nl dc: dc=four,dc=cat,dc=se objectclass: domain objectclass: extendedObject ou: four l: umea Hedberg Expires September 30, 2000 [Page 10] Internet-Draft LDAP Knowledge references July 2000 ========================================== A number of descriptive cases ========================================== case 1: One-level search, target object on the server search baseobject: dc=cat,dc=se scope: onelevel filter: (objectclass=*) attributes: ou returns searchResultEntry { dn: dc=one,dc=cat,dc=se ou: one } searchResultReference { ldapurl: ldap://hostCAT2/dc=two,dc=cat,dc=se } searchResultReference { ldapurl: ldap://hostCAT3/dc=cat,dc=nl } searchResultEntry { dn: dc=four,dc=cat,dc=se ou: four } searchResultDone { resultCode: success } case 2: Subtree search, target object on the server search baseobject: dc=cat,dc=se scope: subtree filter: (objectclass=*) attributes: ou returns searchResultEntry { dn: dc=one,dc=cat,dc=se ou: one } searchResultReference { ldapurl: ldap://hostCAT1/dc=one,dc=cat,dc=se } searchResultReference { ldapurl: ldap://hostCAT2/dc=two,dc=cat,dc=se } Hedberg Expires September 30, 2000 [Page 11] Internet-Draft LDAP Knowledge references July 2000 searchResultReference { ldapurl: ldap://hostCAT3/dc=cat,dc=nl } searchResultEntry { dn: dc=four,dc=cat,dc=se ou: four } searchResultDone { resultCode: success } case 3: base search, target entry contains a 'refer;nssr' attribute search baseobject: dc=one,dc=cat,dc=se scope: base filter: (objectclass=*) attributes: ou returns searchResultEntry { dn: dc=one,dc=cat,dc=se ou: four } searchResultDone { resultCode: success } case 4: base search, target entry contains a 'refer;sub' attribute search baseobject: dc=two,dc=cat,dc=se scope: base filter: (objectclass=*) attributes: ou returns searchResultDone { resultCode: referral matchedDN: dc=two,dc=cat,dc=se referral: ldap://hostCAT2/dc=two,dc=cat,dc=se } Hedberg Expires September 30, 2000 [Page 12] Internet-Draft LDAP Knowledge references July 2000 case 5: one-level search, target entry contains a 'refer;nssr' attribute search baseobject: dc=one,dc=cat,dc=se scope: onelevel filter: (objectclass=*) attributes: ou searchResultDone { resultCode: referral matchedDN: dc=one,dc=cat,dc=se referral: ldap://hostCAT1/dc=one,dc=cat,dc=nu } case 6: Search on area above the baseobject of the server search baseobject: dc=pi,dc=se scope: subtree filter: (objectclass=*) attributes: ou returns searchResultDone { resultCode: referral matchedDN: dc=se referral: ldap://hostSE/dc=se } case 7: Search on area beyond, but not below the baseobject of the server search baseobject: o=surfnet,c=nl scope: base filter: (objectclass=*) returns searchResultDone { resultCode: referral matchedDN: c=nl referral: ldap://hostNL/c=NL } Hedberg Expires September 30, 2000 [Page 13] --==_Exmh_1135548320-- From list@netscape.com Wed Jul 12 20:50:39 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19232 for ; Wed, 12 Jul 2000 20:50:39 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6D0dug22003; Wed, 12 Jul 2000 17:39:56 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6D0mK612936; Wed, 12 Jul 2000 17:48:20 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 17:48:20 -0700 (PDT) Message-Id: <4.3.2.7.0.20000712082349.00afbab0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jul 2000 09:15:43 -0700 To: Bruce Greenblatt From: "Kurt D. Zeilenga" Subject: Re: Revised Matched Values Draft Cc: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com In-Reply-To: <4.3.1.0.20000711173837.00ad3c30@pop.walltech.com> References: <396BAF60.31957.11D7E698@localhost> <4.3.2.7.0.20000701225708.00ae3a60@infidel.boolean.net> <395E667D.20321.CB299BF@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"84cm_D.A.wJD.RHRb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 06:01 PM 7/11/00 -0700, Bruce Greenblatt wrote: >I'll voice the same reservations this time that I voiced last time. > >Use of this control solves a problem that normally exists due to poor schema and DIT design. X.500 is designed to support multiple valued attributes. In numerous cases it makes good sense for a given attribute to have many (hundreds, thousands, more?). X.500 recognized this and, to aid in clients accessing such attributes, provide a mechanism to returned only the desired values. LDAPv3 is missing this functionality. This control extends LDAP to provide functionality already available to X.500 users (via DAP). Without this control, clients have to implement the appropriate matching rules and apply it to all returned values to locate the desired values. The control will solve operational issues which exist today due to design of our current schema (X.5xx/RFC2252/RFC2256). I believe this control will be useful for both user and management applications. When used appropriately, it will reduce the burden upon the client and the network. The overhead of server computation is likely in the noise (the control may actually reduce server side computation associated with some requests). In the user application space, this control may be used obtain the specification for a particular attribute type. The subentry (or entry) which controls the entry attributeTypes attribute may have hundreds of values as the entry may be allowed to have hundreds of attribute types. This reduces the burden of client (and the network). In the management application space, this control will also be quite useful for managing (X.500) ACIs and groups (especially when used with ACIs... as you cannot nest access groups). Kurt From list@netscape.com Wed Jul 12 20:52:38 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19290 for ; Wed, 12 Jul 2000 20:52:32 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6D0gmU24028; Wed, 12 Jul 2000 17:42:49 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6D0lYo12047; Wed, 12 Jul 2000 17:47:34 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 17:47:34 -0700 (PDT) Message-Id: <4.3.2.7.0.20000712104311.00b21980@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jul 2000 10:50:35 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: password policy I-D Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"G1BVKB.A.67C.lGRb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I notice that the revised I-D, intended for publication on the Standard Track, still contains a normative reference to an Informational RFC (2307). This would have be corrected. I also note that 'Proposed Standard' appears on each page in the header. This I find this misleading and inappropriate. I suggest that the first page state: Intended Category: Standard Track and/or an appropriate statement in the Status of the Memo section. I will defer a more detailed review for another day... Kurt From list@netscape.com Wed Jul 12 22:30:20 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21856 for ; Wed, 12 Jul 2000 22:30:19 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6D2HDR00931; Wed, 12 Jul 2000 19:17:13 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6D2Pak14599; Wed, 12 Jul 2000 19:25:36 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 19:25:36 -0700 (PDT) Message-Id: <00003fad54db$00003071$0000667b@x117> To: From: HomeOwners@aaee.fsnet.co.uk Subject: Attention Homeowners: WE ARE FREE! Date: Wed, 12 Jul 2000 19:59:30 -0700 Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 1 X-Msmail-Priority: High Resent-Message-ID: <"BzhsrB.A.bjD.eiSb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: quoted-printable Attention Homeowners: = WE ARE FREE!=

Improve Your Lifestyle!

 

Dear Homeowner,

If you are in debt or need extra cash, we can help you get the money= you have been hoping for.
Our services are FREE and we have already helped thousands of hom= eowners, just like you.


Best Of All...

*Our lenders offer the Lowest Interest Rates available
*They can set you up with an incredibly low monthly payment!
*We can provide you with Lenders who will loan you ...

Up To 125% Of Your Home's Value!

Click Here To Request Yo= ur FREE Quote!

And even better, there are NO Advances= or Upfront Fees of any kind!
This means you won't pay a dime - so you have absolutely nothing to lose!


Here are just some of the ways you could put this cash to use:

-> Home Improvements
-> Credit Card Debt
-> College Tuition
-> Dream Vacation
-> A New Car
-> Start Your Own Business
...or whatever else you need - it's up to YOU.

So if you're serious about improving your current fin= ancial position, you owe it to yourself to request your FREE 
Loan Evaluation. It's FREE and you've got nothing to lose. Right n= ow, while it's fresh in your mind, visit our site.

 

Click Here To Request Your FREE Quote!

We take great pride in offering such prompt and quality service to you an= d your family.

Sincerely,
The Mortgage Guys

 

To unsubscribe from our mailing list, please click here!

From list@netscape.com Wed Jul 12 22:40:58 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22903 for ; Wed, 12 Jul 2000 22:40:57 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6D2V7R02273; Wed, 12 Jul 2000 19:31:08 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6D2dWs19081; Wed, 12 Jul 2000 19:39:32 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 19:39:32 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C576805@aspams01.cai.com> From: "Ramsay, Ron" To: Roland Hedberg Cc: ietf-ldapext@netscape.com Subject: RE: New draft on knowledge references in LDAP Date: Thu, 13 Jul 2000 12:39:27 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"ZPe5dB.A.ppE.hvSb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Roland, I was a little confused by your description of the nssr attribute. In a search result, do you actually return the attribute as part of the entry it is in? Why isn't NSSR processing invoked as part of a one-level search, or is it your intention that the client should see the nssr attribute in the result and act on it as if it were a continuation reference? The X.500 model would have the nssr attribute in the superior entry (otherwise it couldn't be non-specific) and wouldn't return it without the manageDsaIt bit. It is not clear to me how you intend it should be used. X500 compliant implementations would not return multiple entries relating to the nssr entry. Ron. -----Original Message----- From: Roland Hedberg [mailto:roland@catalogix.ac.se] Sent: Thursday, 13 July 2000 6:43 To: internet-drafts@ietf.org Cc: ietf-ldapext@netscape.com Subject: New draft on knowledge references in LDAP Could you please publish the attached draft. -- Roland ------------------------------------------------ Roland Hedberg phone : +47 23 08 29 96 Dalsveien 53 mobile(NO): +47 90 66 44 52 No-0775 Oslo mobile(SE): +46 70 520 420 3 Norway From list@netscape.com Thu Jul 13 02:51:41 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08921 for ; Thu, 13 Jul 2000 02:51:41 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6D6g1R16452; Wed, 12 Jul 2000 23:42:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6D6oPc07274; Wed, 12 Jul 2000 23:50:25 -0700 (PDT) Resent-Date: Wed, 12 Jul 2000 23:50:25 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C587D45@aspams01.cai.com> From: "Lloyd, Alan" To: "Kurt D. Zeilenga" Cc: "Miklos, Sue A." , Bruce Greenblatt , d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft Date: Thu, 13 Jul 2000 16:20:37 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"ywqtoB.A.9wB.uaWb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Kurt... This OSI complex stuff... I have always said that if the protocol stack - 130 KB of code is too complex - its best to leave the rest of the directory service alone as well... If a car door is to complex to build - then dont even attempt to make the cars...:-)) regards alan -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, July 13, 2000 3:05 AM To: Lloyd, Alan Cc: Miklos, Sue A.; Bruce Greenblatt; d.w.chadwick@salford.ac.uk; ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft At 11:38 PM 7/12/00 +1000, Lloyd, Alan wrote: >Isnt it amazing that the reason for LDAP was that DAP was too complex - and >here we are (years later) adding more complexity to LDAP beyond that of >DAP..:-) > regards alan The primary complexity of DAP that LDAP removed was need to implement the ISO protocol stack. As far as other so-called simplications made, I would argue that many of them have actually made things more complex. Note that in X.500/DAP, a client did not need to discover the syntax of attributes simply to browse a directory... now everything is a BLOB until the client reads and recognizes syntaxes of values as published in the subschema. From list@netscape.com Thu Jul 13 03:27:40 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09357 for ; Thu, 13 Jul 2000 03:27:40 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6D7LQU20327; Thu, 13 Jul 2000 00:21:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6D7QCI15311; Thu, 13 Jul 2000 00:26:12 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 00:26:12 -0700 (PDT) Message-Id: <200007130724.JAA04601@catalogix.ac.se> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Ramsay, Ron" cc: Roland Hedberg , ietf-ldapext@netscape.com, roland@catalogix.ac.se Subject: Re: New draft on knowledge references in LDAP In-Reply-To: Message from "Ramsay, Ron" of "Thu, 13 Jul 2000 12:39:27 +1000." <11981F9F5649D411BC92009027D0D18C576805@aspams01.cai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jul 2000 09:24:26 +0200 From: Roland Hedberg Resent-Message-ID: <"OGcy5D.A.4uD.T8Wb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Ron, > I was a little confused by your description of the nssr attribute. > > In a search result, do you actually return the attribute as part of the > entry it is in? No. > The X.500 model would have the nssr attribute in the superior entry > (otherwise it couldn't be non-specific) and wouldn't return it without the > manageDsaIt bit. It is not clear to me how you intend it should be used. The intention was that the 'nssr' attribute would act as it's X.500 equivalent. More specifically there are two special cases where 'refer;nssr' is needed: 1) where a organization wants to keep the authority for a entry even is all the children to that entry is managed by another organization. 2) when someone would like to support onelevel searches in a efficient way when several entries on one level resides on different servers. > X500 compliant implementations would not return multiple entries relating to > the nssr entry. I'm not sure, given that you don't have chaining and therefore can not rely on any intermediate server to remove duplicated entries, how you would go about to avoid duplicated entries. The servers involved have no idea what has happend before or what is happening after they get the query, both acts as if they where the only one asked. So only the client has the complete picture. -- Roland ------------------------------------------------ Roland Hedberg phone : +47 23 08 29 96 Dalsveien 53 mobile(NO): +47 90 66 44 52 No-0775 Oslo mobile(SE): +46 70 520 420 3 Norway From list@netscape.com Thu Jul 13 04:55:08 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10279 for ; Thu, 13 Jul 2000 04:55:04 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6D8ldU25984; Thu, 13 Jul 2000 01:47:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6D8qPE05552; Thu, 13 Jul 2000 01:52:25 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 01:52:25 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C588619@aspams01.cai.com> From: "Lloyd, Alan" Cc: ietf-ldapext@netscape.com, roland@catalogix.ac.se Subject: RE: New draft on knowledge references in LDAP Date: Thu, 13 Jul 2000 18:52:23 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"VuhkLD.A.ZWB.INYb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com All very good - but what about systems where one has to authenticate the users.. and the referred to servers have to know all the users through their directory entries. The ... Security Considerations This document defines mechanisms that can be used to "glue" LDAP (and other) servers together. The information used to specify this glue information should be protected from unauthorized modification. If the server topology information itself is not public information, the information should be protected from unauthorized access as well. These LDAP referal systems are only possible where everybody on the system is an un-authenticated user.. ie one user cannot authenticate to a server unless that user (by DN) and password can verified and ACI applied. Therefore for LDAP referrals to work at all in this type of system the knowledge of the servers must be "public" to any user of the system. And the User must face the "follow the web refs" approach to life. However, where an organisation wants a real distributed directory service with a real distributed authentication system with real ACI to provide system protection and logical views of information (through distributed searches, etc) then X.500 is still the only way to go. If you want an authenticated system - with LDAP servers - then its replicate everything to everywhere...and then one does not need referrals! I think the security considerations should say...Because distributed mutual authentication is not possible with LDAP servers - the referral knowledge must always be public. regards alan -----Original Message----- From: Roland Hedberg [mailto:roland@catalogix.ac.se] Sent: Thursday, July 13, 2000 5:24 PM To: Ramsay, Ron Cc: Roland Hedberg; ietf-ldapext@netscape.com; roland@catalogix.ac.se Subject: Re: New draft on knowledge references in LDAP Ron, > I was a little confused by your description of the nssr attribute. > > In a search result, do you actually return the attribute as part of the > entry it is in? No. > The X.500 model would have the nssr attribute in the superior entry > (otherwise it couldn't be non-specific) and wouldn't return it without the > manageDsaIt bit. It is not clear to me how you intend it should be used. The intention was that the 'nssr' attribute would act as it's X.500 equivalent. More specifically there are two special cases where 'refer;nssr' is needed: 1) where a organization wants to keep the authority for a entry even is all the children to that entry is managed by another organization. 2) when someone would like to support onelevel searches in a efficient way when several entries on one level resides on different servers. > X500 compliant implementations would not return multiple entries relating to > the nssr entry. I'm not sure, given that you don't have chaining and therefore can not rely on any intermediate server to remove duplicated entries, how you would go about to avoid duplicated entries. The servers involved have no idea what has happend before or what is happening after they get the query, both acts as if they where the only one asked. So only the client has the complete picture. -- Roland ------------------------------------------------ Roland Hedberg phone : +47 23 08 29 96 Dalsveien 53 mobile(NO): +47 90 66 44 52 No-0775 Oslo mobile(SE): +46 70 520 420 3 Norway From list@netscape.com Thu Jul 13 05:08:38 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10425 for ; Thu, 13 Jul 2000 05:08:38 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6D8wXR25304; Thu, 13 Jul 2000 01:58:33 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6D96vo09344; Thu, 13 Jul 2000 02:06:57 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 02:06:57 -0700 (PDT) Date: Thu, 13 Jul 2000 02:06:54 -0700 (PDT) Message-Id: <200007130906.e6D96rx01579@ywing.netscape.com> From: aboutlisa@SOVI.hotmail.com To: ietf-ldapext@JJKQ.netscape.com Subject: Earn $5,935 per month without spending anything -MAXI X-Reply-To: theuy@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"SrOX6B.A.rRC.waYb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hello, I just like to invite you to register for this new program. The registration is FREE and you will never have to pay anything in the future either. Your FREE registration will let you earn a stable monthly income that can ONLY GROW! Yes, you can earn $5,935 per month without spending anything. If you're interested, please reply to theuy@yahoo.com with MOREINFO in the Subject Line. Sincerely, G. Chung Please pardon the intrusion.... Under Bill s.1618 TITLE III passed by the 105th US Congress this letter can not be considered Spam as long as the sender includes contact information & a method of "removal". To be removed from future mailings just reply with REMOVE in the subject line. Thank you for your kind consideration. From list@netscape.com Thu Jul 13 06:30:20 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11568 for ; Thu, 13 Jul 2000 06:30:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DAMmU01042; Thu, 13 Jul 2000 03:22:48 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DARZc24029; Thu, 13 Jul 2000 03:27:35 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 03:27:35 -0700 (PDT) Message-Id: <200007131027.GAA11142@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldap-authpasswd-03.txt Date: Thu, 13 Jul 2000 06:27:30 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"YIeQHB.A.v2F.VmZb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP Authentication Password Attribute Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-authpasswd-03.txt Pages : 9 Date : 12-Jul-00 This document describes schema for storing information in support of user/password authentication in a LDAP [RFC2251] directory. The document defines the authPassword attribute type and related schema. The attribute type is used to store values derived from the user's password(s) (commonly using cryptographic strength one-way hash). authPassword is intended to used instead of clear text password storage mechanisms such as userPassword [RFC2256]. The values of authPassword may be used to support both LDAP 'simple' and SASL [RFC2222] password authentication mechanisms [RFC2829]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-authpasswd-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-authpasswd-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-authpasswd-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000712140255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-authpasswd-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-authpasswd-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000712140255.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Thu Jul 13 06:30:46 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11589 for ; Thu, 13 Jul 2000 06:30:46 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DAKkR00394; Thu, 13 Jul 2000 03:20:46 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DATBg24994; Thu, 13 Jul 2000 03:29:11 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 03:29:11 -0700 (PDT) Message-Id: <200007131029.GAA11411@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-ldapv3-dupent-04.txt Date: Thu, 13 Jul 2000 06:29:07 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"JKH1H.A.NGG.1nZb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : LDAP Control for a Duplicate Entry Representation of Search Results Author(s) : J. Sermersheim Filename : draft-ietf-ldapext-ldapv3-dupent-04.txt Pages : 9 Date : 12-Jul-00 This document describes a Duplicate Entry Representation control extension for the LDAP Search operation. By using the control with an LDAP search, a client requests that the server return separate entries for each value held in the specified attributes. For instance, if a specified attribute of an entry holds multiple values, the search operation will return multiple instances of that entry, each instance holding a separate single value in that attribute. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-dupent-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapext-ldapv3-dupent-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapext-ldapv3-dupent-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000712140720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-ldapv3-dupent-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-ldapv3-dupent-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000712140720.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Thu Jul 13 08:52:46 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16526 for ; Thu, 13 Jul 2000 08:52:46 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DCgpR07823; Thu, 13 Jul 2000 05:42:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DCpFE23953; Thu, 13 Jul 2000 05:51:15 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 05:51:15 -0700 (PDT) Message-ID: <81CD2C66CCA5D311ACC1009027AA4C0D08AF14@ENIGMA> From: "Hebson, Jane" To: ietf-ldapext@netscape.com Subject: Have you managed to keep track of all the latest RFCs and Interne t-drafts related to LDAP? Date: Thu, 13 Jul 2000 14:00:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"Kuohf.A.61F.Btbb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Have you managed to keep track of all the latest RFCs and Internet-drafts related to LDAP? If not, EEMA are pleased to offer the following document as a guide to the current state of play http://www.eema.org/interest/displayrecent.asp?ID=68 If you have any comments on this paper which will be maintained on a regular basis, then please contact me - thanks Jane Jane Hebson EEMA Interest and Special Project Manager Direct Line +44 1527 837596 Office +44 1386 793028 http://www.eema.org/ ISSE2000 - The second Information Security Solutions Europe Conference & Exhibition 27-29th September, Barcelona, Spain Visit our web site http://www.eema.org/isse or contact info@eema.org , Register now to secure your place Please put these dates in your diary NOW ! From list@netscape.com Thu Jul 13 09:03:28 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17006 for ; Thu, 13 Jul 2000 09:03:28 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DCvGU09993; Thu, 13 Jul 2000 05:57:16 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DD22o27366; Thu, 13 Jul 2000 06:02:02 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 06:02:02 -0700 (PDT) Message-Id: <200007131300.PAA06071@catalogix.ac.se> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Lloyd, Alan" cc: ietf-ldapext@netscape.com Subject: Re: New draft on knowledge references in LDAP In-Reply-To: Message from "Lloyd, Alan" of "Thu, 13 Jul 2000 18:52:23 +1000." <11981F9F5649D411BC92009027D0D18C588619@aspams01.cai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jul 2000 15:00:18 +0200 From: Roland Hedberg Resent-Message-ID: <"KvZhCB.A.RrG.J3bb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hi Alan, > All very good - but what about systems where one has to authenticate the > users.. and the referred to servers have to know all the users through their > directory entries. The ... Admittedly, this is a problem that the draft does not even try to solve. > Therefore for LDAP referrals to work at all in this type of system the > knowledge of the servers must be "public" to any user of the system. ..snip.. > I think the security considerations should say...Because distributed mutual > authentication is not possible with LDAP servers - the referral knowledge > must always be public. I don't agree. I can see usages where a organization would like to keep some references hidden from the anonymous user, but accessible for users that are authenticated. Worth noting in this case is that for some usages several users might be allowed to authenticate as the same entry and that therefore the amount of information that has to be replicated between cooperating servers are rather limited. -- Roland ------------------------------------------------ Roland Hedberg phone : +47 23 08 29 96 Dalsveien 53 mobile(NO): +47 90 66 44 52 No-0775 Oslo mobile(SE): +46 70 520 420 3 Norway From list@netscape.com Thu Jul 13 10:05:29 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19712 for ; Thu, 13 Jul 2000 10:05:29 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DDtTR13165; Thu, 13 Jul 2000 06:55:29 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DE3sE13065; Thu, 13 Jul 2000 07:03:54 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 07:03:54 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: ietf-ldapext@netscape.com Date: Thu, 13 Jul 2000 15:02:41 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Unique identifiers for LDAP attributes Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <396DDA11.21832.8622E56@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"-HjyuD.A.qLD.Ixcb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Folks I was at a Middleware meeting a few weeks ago where some guys from Internet 2 were talking about outstanding problems with LDAP. One of the points raised was the lack of a unique name for attribute types, and that two LDAP servers could have the same name for different attributes or different names for the same attribute. They were wanting to create a group that could standardise on the names of LDAP attribute types. When I pointed out to them that we already have unique identifiers for each attribute type in the shape of OIDs, that do not have the multilingual and character set problems that strings have, they seemed convinced that this could work. However, we have the situation that some LDAP servers do not require OIDs to be defined for attribute types, and the LDAP spec deprecates the use of OIDs in protocol in preference to strings. Given that many LDAP clients now map the attribute type strings from protocol into a user friendly language dependent display string, the string representation in protocol has about had its day and served its purpose. Isnt it about time that we altered the LDAP spec to recommend that OIDs be the preferred way of transferring attribute types in protocol, and that the OIDs become the globally unique way of identifying attribute types. (Firewalls up to protect from flames) David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Jul 13 10:05:53 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19751 for ; Thu, 13 Jul 2000 10:05:53 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DDxQU14499; Thu, 13 Jul 2000 06:59:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DE4CU13411; Thu, 13 Jul 2000 07:04:12 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 07:04:12 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: Sean Mullan , ietf-pkix@imc.org, ietf-ldapext@netscape.com Date: Thu, 13 Jul 2000 15:02:42 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt Reply-to: d.w.chadwick@salford.ac.uk CC: Boeyen@entrust.com Message-ID: <396DDA12.874.862330B@localhost> Priority: normal In-reply-to: <396CB983.81DC54B3@sun.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"F9np4C.A.jQD.Yxcb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date sent: Wed, 12 Jul 2000 19:31:31 +0100 From: Sean Mullan To: d.w.chadwick@salford.ac.uk Copies to: ietf-pkix@imc.org, ietf-ldapext@netscape.com Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt > Hi David, > > Some comments on the draft below. Sean, replies intersperced below > Section 3.2 Certificate Match > > I think the X.509 certificate matching rules are missing some > essential and important fields in the certificateAssertion structure > for filtering on certificates. We may want to consider defining a > superset. I submitted these comments to the X.509 editors but > apparently it was too late to integrate them into the 2000 update. > > * you should be able to match on more than one pathToName and on > non-X500 > name types. This is inconsistent with name constraints which allow > you to constrain to more than one name and different name types. > I agree that alternative name types should be allowed. But maybe it is not necessary to have multiple names, since you can do several Searches providing one name for each search (remember that the name presented should be allowed to have a cert path created to it) How do we want to handle this: i) issue a defect on X.509 (Sharon can you comment on this) ii) let the LDAP matching rule be a superset of the X.509 one? I would favour the former route myself. > * you should be able to match on more than the subject alt name > type. Agreed. This is a lack of clarity in the ID. It is intended that the whole name can be presented along with the type. The text is ambiguous in this respect and I will fix it. It will also be clearer when version 1 is published that contains BNF for each of the fields. Steven Legg has been doing this for me. > You > should also be able to match on the subject alt name itself, and > specify more than one subject alt name as certificates can contain > more than one. > Concerning multiple names, I think this can be solved by performing multiple searches with a single name in each search. > * you should be able to match on the subject public key as well as > the subject public > key algorithm OID. > you can match on the subject key identifier (3rd component) > * you should be able to match on the basic constraints extension, > especially the > maxPathLen value. This is useful for finding potential > certificates when building certification paths from the target to > the most-trusted CA. For ex, if a partial path has been built, any > candidate certificate must have a maxPathLen value greater than or > equal to the number of certificates in the partial path. > Interestingly this has been defined for attribute certificates and not pk certs. I actually think that the way matching for ACs has been handled is far superior than for PKcerts. ie. a separate matching rule for each extension, rather than one long complex rule for pk certs. However, there would be nothing to stop an implementation dynamically attaching the basicAttConstraintsMatch to public key certs. In fact this matching rule could be renamed the basicConstraintsMatch anyway as the syntax is the same for both ACs and PKCs. This is my preferred approach. > I think it is very important to include the Certificate pair matching > rules, as these are very useful when building certification paths and > trying to discover which of many cross certificates satisfy various > validation constraints, and eliminating those that do not. > OK, this can be done. It is just time consuming and I wanted to know if there was a demand first. > Other comments: > > * What RFC format are you using for the encoding of DNs - 1779? This > should be referenced. It should be 2253 for LDAPv3. > > Section 4.2 Certificate List Match > > There is an error in the CertificateListAssertion definition in X.509 > 2000. The authorityKeyIdentifier component should be marked OPTIONAL. > This probably doesn't affect your definition, but I just wanted to > make you aware of it. Agreed, Sharon, can you make a note of this defect David p.s. what do you think about Bruce's assertion that none of this is needed and instead we should have a bunch of simple attributes in the LDAP entry David > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Jul 13 10:07:13 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19811 for ; Thu, 13 Jul 2000 10:07:12 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DDtpR13398; Thu, 13 Jul 2000 06:55:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DE4FE13495; Thu, 13 Jul 2000 07:04:15 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 07:04:15 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" Date: Thu, 13 Jul 2000 15:02:40 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Revised Matched Values Draft Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <396DDA10.32652.8622D02@localhost> Priority: normal In-reply-to: <4.3.2.7.0.20000712082349.00afbab0@infidel.boolean.net> References: <4.3.1.0.20000711173837.00ad3c30@pop.walltech.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"j1puBC.A.eRD.bxcb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Kurt wrote > X.500 is designed to support multiple valued attributes. In numerous > cases it makes good sense for a given attribute to have many > (hundreds, thousands, more?). X.500 recognized this and, to aid in > clients accessing such attributes, provide a mechanism to returned > only the desired values. LDAPv3 is missing this functionality. This > control extends LDAP to provide functionality already available to > X.500 users (via DAP). In fact, LDAP has provided a cleaner and more effective design than X.500 originally did (if you remember we started out using the X.500 design and replaced it with the new design due to complexities and ambiguities in the X.500 design that effectively had used one field (the filter) to do two different jobs (this is always a bad design decision in the long run). You might like to know that the X.500 group is proposing to start a new work item "alignment with LDAP" and if the match values control is standardised by LDAP then X.500 will almost certainly add it to DAP in order to keep some semblance of alignment. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Jul 13 10:59:55 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22440 for ; Thu, 13 Jul 2000 10:59:54 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DErgU20618; Thu, 13 Jul 2000 07:53:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DEwSI29497; Thu, 13 Jul 2000 07:58:28 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 07:58:28 -0700 (PDT) Date: Thu, 13 Jul 2000 09:57:22 -0500 From: Mark Wahl Subject: Re: Unique identifiers for LDAP attributes In-reply-to: "Your message of Thu, 13 Jul 2000 15:02:41 BST." <396DDA11.21832.8622E56@localhost> Sender: wahl@austin.innosoft.com To: d.w.chadwick@salford.ac.uk Cc: ietf-ldapext@netscape.com Message-id: <2466.963500242@threadgill.austin.innosoft.com> Resent-Message-ID: <"e5NhUC.A.kMH.Tkdb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com FWIW there are a number of interesting problem areas for improving schema management in the directory. For example, how to support schema which changes over time, separating schema which is 'experimental' from 'recommended' in a single DIT, or publishing more hints of the DIT and schema structure to help clients. I requested a BOF at the Pittsburgh IETF on Evolving LDAP Schema Entries, and I should find out within a few days whether the Area Directors have scheduled it. Your issues might be a suitable topic for discussion at this BOF. Mark Wahl, Directory Architect, Service Provider/Infrastructure Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Thu Jul 13 11:02:50 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22663 for ; Thu, 13 Jul 2000 11:02:49 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DEubU21327; Thu, 13 Jul 2000 07:56:38 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DF1O600820; Thu, 13 Jul 2000 08:01:24 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 08:01:24 -0700 (PDT) Message-Id: <4.3.2.7.0.20000713074054.00b34e90@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Jul 2000 08:00:58 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: Unique identifiers for LDAP attributes Cc: ietf-ldapext@netscape.com In-Reply-To: <396DDA11.21832.8622E56@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"Vfmyl.A.VM.Cndb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 03:02 PM 7/13/00 +0100, David Chadwick wrote: >However, we have the situation that some LDAP servers do not >require OIDs to be defined for attribute types, Which implies they cannot properly publish schema... Which implies they must be read-only servers... >and the LDAP spec >deprecates the use of OIDs in protocol in preference to strings. RFC2251 recognizes that names are non-unique but requires servers to use them. This does seem quite odd. >Given that many LDAP clients now map the attribute type strings >from protocol into a user friendly language dependent display string, >the string representation in protocol has about had its day and >served its purpose. Isnt it about time that we altered the LDAP >spec to recommend that OIDs be the preferred way of transferring >attribute types in protocol, and that the OIDs become the globally >unique way of identifying attribute types. Maybe then clients would actually discover (and make use) of published schema... I would support lifting the MUST use short names requirement. This requirement is not needed to support interoperability and hence, per RFC2119, it shouldn't be a MUST. I would support stating that servers MUST use a non-ambiguous identifier. That is, they must either ensure that NAME of given schema elements are non-ambiguous (with a subschema subentry) or use OIDs. From list@netscape.com Thu Jul 13 11:16:30 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23402 for ; Thu, 13 Jul 2000 11:16:29 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DF6fR20161; Thu, 13 Jul 2000 08:06:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DFF6606844; Thu, 13 Jul 2000 08:15:06 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 08:15:06 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C588B1E@aspams01.cai.com> From: "Lloyd, Alan" To: d.w.chadwick@salford.ac.uk Cc: ietf-ldapext@netscape.com Subject: RE: Unique identifiers for LDAP attributes Date: Fri, 14 Jul 2000 01:15:03 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"s8LzwD.A.fqB.4zdb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David - as we know ... Thats why we had OIDs in the first place - isnt it...ownership, organised registration, unique identification and the ability to interpret for human users - eg language.. and managed under the ISO/ITU..Not to mention the use of ASN.1 compilers that automate OID based information processing code.... Mind you that is all too "complex"..eh... When are you going to let the XML world know about ASN.1 and OIDs after all, centre and center are similar but different arnt they..Now doubt the XML world will hit this issue to. Flames David - I doubt it... regards alan PS - are you sending the beer! -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] Sent: Friday, July 14, 2000 12:03 AM To: ietf-ldapext@netscape.com Subject: Unique identifiers for LDAP attributes Folks I was at a Middleware meeting a few weeks ago where some guys from Internet 2 were talking about outstanding problems with LDAP. One of the points raised was the lack of a unique name for attribute types, and that two LDAP servers could have the same name for different attributes or different names for the same attribute. They were wanting to create a group that could standardise on the names of LDAP attribute types. When I pointed out to them that we already have unique identifiers for each attribute type in the shape of OIDs, that do not have the multilingual and character set problems that strings have, they seemed convinced that this could work. However, we have the situation that some LDAP servers do not require OIDs to be defined for attribute types, and the LDAP spec deprecates the use of OIDs in protocol in preference to strings. Given that many LDAP clients now map the attribute type strings from protocol into a user friendly language dependent display string, the string representation in protocol has about had its day and served its purpose. Isnt it about time that we altered the LDAP spec to recommend that OIDs be the preferred way of transferring attribute types in protocol, and that the OIDs become the globally unique way of identifying attribute types. (Firewalls up to protect from flames) David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Jul 13 11:38:45 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24580 for ; Thu, 13 Jul 2000 11:38:45 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DFUPU26031; Thu, 13 Jul 2000 08:30:27 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DFZCc16114; Thu, 13 Jul 2000 08:35:12 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 08:35:12 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C588B2E@aspams01.cai.com> From: "Lloyd, Alan" To: Roland Hedberg Cc: ietf-ldapext@netscape.com Subject: RE: New draft on knowledge references in LDAP Date: Fri, 14 Jul 2000 01:35:10 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"cILNz.A.d7D.uGeb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com comments in line ???? -----Original Message----- From: Roland Hedberg [mailto:roland@catalogix.ac.se] Sent: Thursday, July 13, 2000 11:00 PM To: Lloyd, Alan Cc: ietf-ldapext@netscape.com Subject: Re: New draft on knowledge references in LDAP Hi Alan, > All very good - but what about systems where one has to authenticate the > users.. and the referred to servers have to know all the users through their > directory entries. The ... Admittedly, this is a problem that the draft does not even try to solve. Alan: yet below you say this is not a problem when it is??? > Therefore for LDAP referrals to work at all in this type of system the > knowledge of the servers must be "public" to any user of the system. ..snip.. > I think the security considerations should say...Because distributed mutual > authentication is not possible with LDAP servers - the referral knowledge > must always be public. I don't agree. Alan: logic error warning... I can see usages where a organization would like to keep some references hidden from the anonymous user, but accessible for users that are authenticated. alan: Therefore - the referal is not public therefore it does not exist in this context..As said for a referal to exists it needs to be public if the user needs to use it and if the user does use it - they will be public anon on the referred server - However, if the user is authenticated on this server to get a referral to anaother server, then a) he is anon on that server or they information is replicated to that server so they can be authenticated..And if they are replicated why have a referal - and one needs authentication on one server to get a referal to a pulic server where one is not authenticated - why would i do that???. Worth noting in this case is that for some usages several users might be allowed to authenticate as the same entry and that therefore the amount of information that has to be replicated between cooperating servers are rather limited. Interesting - I deal with systems targetting 300m users... we dont have this problem or even need to think about manageing that with X.500 - My belief - once you replicate - you create a security issue..and an operational cost..Its best to buy the technology that removes the problems rather than systems that create a minefield of operational problems and poor security eh! regards as always alan -- Roland ------------------------------------------------ Roland Hedberg phone : +47 23 08 29 96 Dalsveien 53 mobile(NO): +47 90 66 44 52 No-0775 Oslo mobile(SE): +46 70 520 420 3 Norway From list@netscape.com Thu Jul 13 11:40:32 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24704 for ; Thu, 13 Jul 2000 11:40:31 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DFYMU26728; Thu, 13 Jul 2000 08:34:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DFd9k17582; Thu, 13 Jul 2000 08:39:09 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 08:39:09 -0700 (PDT) Message-Id: <3.0.5.32.20000713083538.0092d8e0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 13 Jul 2000 08:35:38 -0700 To: "Miklos, Sue A." , "'Lloyd, Alan'" , d.w.chadwick@salford.ac.uk, "Kurt D. Zeilenga" From: Bruce Greenblatt Subject: RE: Revised Matched Values Draft Cc: ietf-ldapext@netscape.com In-Reply-To: <200007121220.IAA01264@roadblock.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"TbKaZ.A.XSE.aKeb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 08:31 AM 7/12/2000 -0400, Miklos, Sue A. wrote: >All, > >I can think of instances where there may be many values in an attribute, but >they are mostly related to mail lists. I have requirements to be able to >manage varying sizes of lists (AllMil which is essentially a series of >nested lists, down to smaller, 10-30 member lists). > >Can this narrow requirement be managed through superior schema design, or do >I need to be able to match on member characteristics (name?) to selectively >delete/update the information? > > From my perspective, there are many problems in using the groupOfNames object class or something similar to manage mailing lists. For example, consider attempting to implement MajorDomo using just this LDAP object class. It becomes difficult to classify mailing list members since the membership is implemented with a list of DNs. There is no easy way to attach additional information to indivual mailing list members. An approach is to begin using nested lists and containers to hold the different lists, but this can lead to additional problems (such as constant movement of list members from one sublist to another if a list member is suspended). In my opinion it would be straightforward to implement a robust mailing list program that uses LDAP that doesn't create attributes with large numbers of values. It should be easier to administer than its counterpart. So, to answer your question, this narrow requirement CAN be managed through "superior" schema design. Bruce ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html From list@netscape.com Thu Jul 13 11:45:56 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24964 for ; Thu, 13 Jul 2000 11:45:55 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DFaNR24670; Thu, 13 Jul 2000 08:36:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DFimY20639; Thu, 13 Jul 2000 08:44:48 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 08:44:48 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 13 Jul 2000 09:43:59 -0600 From: "Ed Reed" To: , Cc: , Subject: Re: LDAP subentry alignment with X.500 subentry Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e6DFii120596 Resent-Message-ID: <"0wzln.A.ECF.tPeb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit Kurt - I disagree with your proposal to replace LDAPsubentry with X.500 subentry, mainly for reasons already expressed on the list: 1) the subtree specifier is omitted because: a) it introduces what seems to be a lot of complexity to determining which entries a subentry would refer to, b) it introduces what seems to be a lot of complexity to determining which subentries apply to a particular entry, c) it introduces what seems to be a lot of complex thinking for administrators who want to understand how to tell their system to do something, and to understand what their system is trying to do d) the author (me) has not been exposed to many (any) real-world problems solved by the subtree specifier which are not or can not be as well handled in some other fashion. 2) As Steven Legg pointed out, X.500 vendors who wish to use the same mechanism to implement subentry and LDAPsubentry may treat LDAPsubentry as a limited subset (for the most part, see below) of the X.500 subentry, with an implicit subtree specification. The one place I'm aware of that the LDAP subentry is not a proper subset of the X.500 subentry is that the LDAPsubentry MAY be nested, whereas the X.500 subentry may not - but that's really just a structure rule variation, isn't it? Of those reasons, the first three of 1 are the qualitative reasons. As for the fourth - informal conversations I've had with vendors who HAVE implemented the subentry suggest that it IS complex to implement, it IS hard to use correctly in operational environments (because of a, b, and c) and it's NOT widely used. I've no objection to extending LDAPsubentry at somepoint in the future to have full X.500 semantic subentry behavior - but I'd rather let those of you who think it's worth while do the expansion and let the market place of real-world operations provide the compelling reason the make that the standard, rather than try to force it on lots of folks who don't see the need, today. Or put another way, I have no problem watching LDAPsubentry attrophy from lack of use if the X.500 subentry is over= whelmingly adopted by the LDAP community at large. Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Kurt D. Zeilenga" 07/03/00 10:25AM >>> I believe 'LDAPsubentry' should be replaced with with 'subentry' and defined such that it closely modelled after X.500. 1) subentries should have a subtree specifier such that they are more useful for specification of ACI subentries. 2) subentries should be visible based upon presence of a subentries control, not a filter components. For example: (|(&(objectclass=LDAPsubentry)(!(cn=*))(objectclass=*)) Should the subentry be visible or not? There are reasonable arguments for both yes and no. I primarily make these suggestions because I believe these changes would make subentries within LDAP more usable, in particular, when used in support of the access control model. Kurt From list@netscape.com Thu Jul 13 11:49:38 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25148 for ; Thu, 13 Jul 2000 11:49:37 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DFhOU29164; Thu, 13 Jul 2000 08:43:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DFmB622796; Thu, 13 Jul 2000 08:48:11 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 08:48:11 -0700 (PDT) Message-Id: <3.0.5.32.20000713084607.00925100@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 13 Jul 2000 08:46:07 -0700 To: "Kurt D. Zeilenga" From: Bruce Greenblatt Subject: Re: Revised Matched Values Draft Cc: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com In-Reply-To: <4.3.2.7.0.20000712082349.00afbab0@infidel.boolean.net> References: <4.3.1.0.20000711173837.00ad3c30@pop.walltech.com> <396BAF60.31957.11D7E698@localhost> <4.3.2.7.0.20000701225708.00ae3a60@infidel.boolean.net> <395E667D.20321.CB299BF@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"poKLOB.A.3jF.5Seb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 09:15 AM 7/12/2000 -0700, Kurt D. Zeilenga wrote: >At 06:01 PM 7/11/00 -0700, Bruce Greenblatt wrote: >>I'll voice the same reservations this time that I voiced last time. >> >>Use of this control solves a problem that normally exists due to poor schema and DIT design. > >X.500 is designed to support multiple valued attributes. In numerous >cases it makes good sense for a given attribute to have many >(hundreds, thousands, more?). X.500 recognized this and, to aid [snip] Kurt, I disagree (obviously). Just because an implementation allows you to do something, doesn't mean that it was designed to support it or that is even a good idea. For example, just because you can put 25 college students in a Volkswagen Beetle doesn't make it a good idea, or an indication that the car's designers had that in mind when they first designed the car. Bruce ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html From list@netscape.com Thu Jul 13 11:57:44 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25521 for ; Thu, 13 Jul 2000 11:57:43 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DFpUU00544; Thu, 13 Jul 2000 08:51:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DFuGI26558; Thu, 13 Jul 2000 08:56:16 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 08:56:16 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 13 Jul 2000 09:55:49 -0600 From: "Ed Reed" To: , Cc: , , Subject: LDAP subentry schema request for last call Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e6DFuF126510 Resent-Message-ID: <"jytau.A.eeG.faeb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit After reviewing the recent comments on LDAPsubentry (and posting my reply), and reviewing where the March 9 version of the doc (as posted on the LDUP wg web site) stands with regard to MUST/MAY (cn) and naming, I think the document, as published, should go forward for last call. With regard to naming, the doc says LDAPsubentry MAY be named by cn, which is where I think the concensus of the list now resides. With regard to MUST/MAY {cn} as an attribute, the document now says MAY, and leaves the class as a STRUCTURAL class. Of course, that means that a naming rule will need to use CN as it's naming attribute if no other attributes are defined on the class, which pretty much turns it into a MUST in those cases, but when other classes are derived from LDAPsubentry other attributes may also be defined, and then cn need not be used as a naming attribute. I think we could also make it be MUST {cn} and require cns to be populated, even if they're not being used to name the LDAPsubentry, and I'll be happy to make that change after last call if needed. I just don't see the need to bother, now. With regard to making LDAPsubentry fully compatible with the X.500 subentry, it's been pointed out that people wanting to use the X.500 subentry should feel free to do so - it's incorporated by reference in the base LDAP definitions. The purpose of this proposal is to define a subset of the X.500 functionality (and extend the structural rules by allowing nesting of LDAPsubentries) for use by certain LDAP applications which find the subset functionality a useful simplification. So - Please, put out the last call for the draft as posted on the LDUP WG IETF Charter page, document draft-ietf-ldup-subentry-02.txt, dated 9 March 2000. Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From list@netscape.com Thu Jul 13 12:11:58 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26267 for ; Thu, 13 Jul 2000 12:11:52 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DG5cU02895; Thu, 13 Jul 2000 09:05:38 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DGAOo12895; Thu, 13 Jul 2000 09:10:24 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 09:10:24 -0700 (PDT) Sender: Robert.Byrne@france.Sun.COM Message-ID: <396DE97A.CE8EA105@france.sun.com> Date: Thu, 13 Jul 2000 18:08:26 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Alan.Lloyd@ca.com, Ron.Ramsay@ca.com, ietf-ldapext@netscape.com, Albert.Langer@directory-designs.org Subject: Re: LDAP subentry alignment with X.500 subentry References: <000601bfeb02$6e45e6c0$17448490@vic.bigpond.net.au> Content-Type: multipart/alternative; boundary="------------573FFAE11C095AE83B90D79E" Resent-Message-ID: <"sBe7IC.A.wID.uneb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --------------573FFAE11C095AE83B90D79E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ron/Alan/Albert, Thanks for your responses. There were two questions: 1. why can't we have generic filters to define the scope of subentries ? 2. what is so great about subentries anyway ? For the first question, we have the following comments. [Ron] > I can so no purpose either for a general filter in a subentry of for scopes > in entry ACI. > > The problem with the former is that, if the filter relates to > telephoneNumber, for example, and the user deletes this attribute from his > entry, the ACI may now behave unpredictably. > Ron, in our LDAP server we provide this as a way to define entries to which acis apply and this feature is used. The effect is not unpredictable--the behaviour of filters is well defined. Though I agree that if the admin does not define his policy well, the effect may be unexpected. I think that the use of this feature provides flexibilty but demands good management by the admin--I guess it's a trade off. [Albert] > LDAP standards must not unnecessarily limit implementation choices. Filter > specifications on object classes work with either model, since every entry > knows its object classes and can easily calculate an arbitrary filter on > them quickly when determining visibility during searches. > Albert, doesn't an entry know the other attributes that it contains as well and so could evaluate an arbitrary filter ? > General filters > really only work with a traversal based implementation and are basically > just an attempt to substitute regexp evaluation on path names familiar to > centralized web administrators for a serious admin model that can actually > be delegated. The apparant additional flexibility is illusory since it > Don't catch this--a general filter refers to values of attributes within the entry, not the dn of the entry. As I pointed out above, users of our directory make use of this "illusion" all the time. For the second question, "what is so great about using subentries for acis?", I think Alan's response was clearest. For my own benefit I've tried to distill (quite a lot!) the main points to the points listed below. I don't dispute them, but I would say that the "aci attribute" approach also allows seperation (it's an operational attribute) and delegation (you've got rights to that attribute or not)...though not to the same extent as the subentry approach. . the principal of seperating security information from that which it protects is a good one and in particular, an aci in a subentry is "more seperate" than an aci in a user entry. . for delegation, the admin point/subentry approach offers more "levels of delegation" because there are more components to it (admin points, subentries and subEntryACI to protect subentries versus a single attribute). . for distribution, if acis are clearly identified in subentries, then it is easier to propagate this aci information to subordinate systems (if required) than if it is distributed among the user entries. Rob. --------------573FFAE11C095AE83B90D79E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Ron/Alan/Albert,

Thanks for your responses.

There were two questions:

1. why can't we have generic filters to define the scope of subentries ?
2. what is so great about subentries anyway ?

For the first question, we have the following comments.

[Ron] 

I can so no purpose either for a general filter in a subentry of for scopes
  in entry ACI.

  The problem with the former is that, if the filter relates to
  telephoneNumber, for example, and the user deletes this attribute from his
  entry, the ACI may now behave unpredictably.


Ron, in our LDAP server  we provide this as a way to define entries to which acis apply and this feature is used.  The effect is not unpredictable--the behaviour of filters is well defined.  Though I agree that if the admin does not define his policy well, the effect may be unexpected.  I think that the use of this feature provides flexibilty but demands good management by the admin--I guess it's a trade off. 

[Albert]
LDAP standards must not unnecessarily limit implementation choices. Filter
  specifications on object classes work with either model, since every entry
  knows its object classes and can easily calculate an arbitrary filter on
  them quickly when determining visibility during searches.


Albert, doesn't an entry know the other attributes that it contains as well and so could evaluate an arbitrary filter ? 

General filters
  really only work with a traversal based implementation and are basically
  just an attempt to substitute regexp evaluation on path names familiar to
  centralized web administrators for a serious admin model that can actually
  be delegated. The apparant additional flexibility is illusory since it


Don't catch this--a general filter refers to values of attributes within the entry, not the dn of the entry.  As I pointed out above, users of our directory make use of this "illusion" all the time.

For the second question, "what is so great about using subentries for acis?", I think Alan's response was clearest.  For my own benefit I've tried to distill (quite a lot!) the main points to the points listed below.  I don't dispute them, but I would say that the "aci attribute" approach also allows seperation (it's an operational attribute) and delegation (you've got rights to that attribute or not)...though not to the same extent as the subentry approach.

. the principal of seperating security information from that which it protects
is a good one and in particular, an aci in a subentry is "more seperate" than an aci in a user entry.

. for delegation, the admin point/subentry approach offers more "levels of delegation" because there are more components to it (admin points, subentries and subEntryACI to protect subentries versus a single attribute).

. for distribution, if acis are clearly identified in subentries, then it is
easier to propagate this aci information to subordinate systems (if required) than if it is distributed among the user entries.

Rob. --------------573FFAE11C095AE83B90D79E-- From list@netscape.com Thu Jul 13 13:04:39 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29366 for ; Thu, 13 Jul 2000 13:04:39 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DGvVU10877; Thu, 13 Jul 2000 09:57:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DH2Iw07362; Thu, 13 Jul 2000 10:02:18 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 10:02:18 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com Date: Thu, 13 Jul 2000 18:00:43 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Unique identifiers for LDAP attributes Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <396E03CB.11173.9053420@localhost> Priority: normal In-reply-to: <4.3.2.7.0.20000713074054.00b34e90@infidel.boolean.net> References: <396DDA11.21832.8622E56@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"60SYmD.A.gyB.XYfb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date sent: Thu, 13 Jul 2000 08:00:58 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: Unique identifiers for LDAP attributes Copies to: ietf-ldapext@netscape.com > At 03:02 PM 7/13/00 +0100, David Chadwick wrote: > >However, we have the situation that some LDAP servers do not > >require OIDs to be defined for attribute types, > > Which implies they cannot properly publish schema... Correct There is another interesting problem that you may be interested in related to the non-use of OIDs. The matching rule used to select a subschema definition is, wait for it.... objectIdentifierFirstComponentMatch Thus the client needs to know the OID of the schema definition it needs to selectively fetch it. But if LDAP never passes an OID to the client, how does the client know which subschema definition it needs? In order to solve this, it means we really need a "nonUniqueStringSecondComponentMatch" matching rule to be defined for LDAP. > Which implies they must be read-only servers... Why? Sorry, I dont follow this one. LDAP updates dont need to use OIDs. --snip-- > > I would support stating that servers MUST use a non-ambiguous > identifier. That is, they must either ensure that NAME of given > schema elements are non-ambiguous (with a subschema subentry) > or use OIDs. > Sort of agree, however making NAME only unambiguous within a subschema subentry solves the problem for one administration, but not for interworking between domains. Thus NAME needs to globally unambiguous - which brings us full circle around to the problem that the Internet 2 guys are trying to solve. To my mind, OID is the only sensible way forward. David > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Jul 13 13:05:01 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29392 for ; Thu, 13 Jul 2000 13:05:01 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DGvmU11070; Thu, 13 Jul 2000 09:57:49 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DH2ZE07713; Thu, 13 Jul 2000 10:02:35 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 10:02:35 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: Mark Wahl , ietf-ldapext@netscape.com Date: Thu, 13 Jul 2000 18:00:45 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Unique identifiers for LDAP attributes Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <396E03CD.132.9053B96@localhost> Priority: normal References: "Your message of Thu, 13 Jul 2000 15:02:41 BST." <396DDA11.21832.8622E56@localhost> In-reply-to: <2466.963500242@threadgill.austin.innosoft.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"GcFNWC.A.T3B.nYfb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date forwarded: Thu, 13 Jul 2000 07:58:29 -0700 (PDT) Date sent: Thu, 13 Jul 2000 09:57:22 -0500 From: Mark Wahl Subject: Re: Unique identifiers for LDAP attributes To: d.w.chadwick@salford.ac.uk Copies to: ietf-ldapext@netscape.com Forwarded by: ietf-ldapext@netscape.com > > FWIW there are a number of interesting problem areas for improving > schema management in the directory. For example, how to support > schema which changes over time, separating schema which is > 'experimental' from 'recommended' in a single DIT, or publishing more > hints of the DIT and schema structure to help clients. I requested a > BOF at the Pittsburgh IETF on Evolving LDAP Schema Entries, was this fortunate timing on our parts, or pre-destination, or just plain old coincidence? Lets hope the ADs agree to your request David >and I > should find out within a few days whether the Area Directors have > scheduled it. Your issues might be a suitable topic for discussion at > this BOF. > > Mark Wahl, Directory Architect, Service Provider/Infrastructure > Sun Microsystems, Inc. iPlanet Alliance > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Jul 13 13:12:14 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29896 for ; Thu, 13 Jul 2000 13:12:13 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DH61U12928; Thu, 13 Jul 2000 10:06:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DHAlg11612; Thu, 13 Jul 2000 10:10:47 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 10:10:47 -0700 (PDT) Date: Thu, 13 Jul 2000 12:09:39 -0500 From: Mark Wahl Subject: Re: Unique identifiers for LDAP attributes In-reply-to: "Your message of Thu, 13 Jul 2000 18:00:45 BST." <396E03CD.132.9053B96@localhost> Sender: wahl@austin.innosoft.com To: d.w.chadwick@salford.ac.uk Cc: ietf-ldapext@netscape.com Message-id: <27707.963508179@threadgill.austin.innosoft.com> Resent-Message-ID: <"IX9f7D.A.H1C.Wgfb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com There was a presentation at the last IETF LDAPEXT meeting on schema updating issues. Mark Wahl, Directory Architect, Service Provider/Infrastructure Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Thu Jul 13 13:15:03 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00033 for ; Thu, 13 Jul 2000 13:15:03 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DH51R06739; Thu, 13 Jul 2000 10:05:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DHDQ613124; Thu, 13 Jul 2000 10:13:26 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 10:13:26 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 13 Jul 2000 11:12:59 -0600 From: "Jim Sermersheim" To: , Cc: Subject: Re: Unique identifiers for LDAP attributes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e6DHDO113097 Resent-Message-ID: <"irVo6.A.vMD.1ifb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit >>> "David Chadwick" 7/13/00 11:02:47 AM >>> >There is another interesting problem that you may be interested in >related to the non-use of OIDs. The matching rule used to select a >subschema definition is, wait for it.... > > objectIdentifierFirstComponentMatch > >Thus the client needs to know the OID of the schema definition it >needs to selectively fetch it. But if LDAP never passes an OID to >the client, how does the client know which subschema definition it >needs? In order to solve this, it means we really need a >"nonUniqueStringSecondComponentMatch" matching rule to be >defined for LDAP. Though I agree with the general notion of moving toward the use of unique OIDs, there's a minor flaw with this statement. objectIdentifierFirstComponentMatch uses the OID syntax which can either be a numericoid (1.2.3.4) or the descr form (cn), so it's still usable with short names as it stands today. Jim From list@netscape.com Thu Jul 13 13:23:17 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00532 for ; Thu, 13 Jul 2000 13:22:52 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DHGTU15724; Thu, 13 Jul 2000 10:16:29 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DHLFk17054; Thu, 13 Jul 2000 10:21:16 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 10:21:16 -0700 (PDT) Message-ID: <396DFA36.B4551B8B@stl.es> Date: Thu, 13 Jul 2000 19:19:50 +0200 From: Julio =?iso-8859-1?Q?S=E1nchez=20Fern=E1ndez?= Organization: Poca X-Mailer: Mozilla 4.73 [en]C-STL/0.3 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: d.w.chadwick@salford.ac.uk CC: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com Subject: Re: Unique identifiers for LDAP attributes References: <396DDA11.21832.8622E56@localhost> <396E03CB.11173.9053420@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Hl8bfD.A.HKE.Kqfb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit David Chadwick wrote: > Why? Sorry, I dont follow this one. LDAP updates dont need to use > OIDs. RFC2251, section 3.2.2: > A server > which masters entries and permits clients to modify these entries > MUST implement and provide access to these subschema entries, Julio From list@netscape.com Thu Jul 13 13:32:26 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01229 for ; Thu, 13 Jul 2000 13:32:25 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DHQDU17622; Thu, 13 Jul 2000 10:26:13 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DHV0o22451; Thu, 13 Jul 2000 10:31:00 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 10:31:00 -0700 (PDT) Message-Id: <4.3.2.7.0.20000713102545.00b4d9c0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Jul 2000 10:30:35 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: Unique identifiers for LDAP attributes Cc: ietf-ldapext@netscape.com, ietf-ldapext@netscape.com In-Reply-To: <396E03CB.11173.9053420@localhost> References: <4.3.2.7.0.20000713074054.00b34e90@infidel.boolean.net> <396DDA11.21832.8622E56@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"QygUE.A.CeF.Szfb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 06:00 PM 7/13/00 +0100, David Chadwick wrote: >> Which implies they must be read-only servers... > >Why? Sorry, I dont follow this one. LDAP updates dont need to use >OIDs. RFC 2251, 3.2.2: A server which masters entries and permits clients to modify these entries MUST implement and provide access to these subschema entries, so that its clients may discover the attributes and object classes which are permitted to be present. From list@netscape.com Thu Jul 13 13:39:28 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01645 for ; Thu, 13 Jul 2000 13:39:28 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DHTJR10887; Thu, 13 Jul 2000 10:29:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DHbig27996; Thu, 13 Jul 2000 10:37:44 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 10:37:44 -0700 (PDT) Message-Id: <4.3.2.7.0.20000713103300.00b31df0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Jul 2000 10:37:33 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Unique identifiers for LDAP attributes Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"M_nmh.A.H1G.m5fb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:12 AM 7/13/00 -0600, Jim Sermersheim wrote: >Though I agree with the general notion of moving toward the use of unique OIDs, there's a minor flaw with this statement. > >objectIdentifierFirstComponentMatch uses the OID syntax which can either be a numericoid (1.2.3.4) or the descr form (cn), so it's still usable with short names as it stands today. But note a minor flaw in your statement. A matchingRule should evaluate to Undefined if the attribute value doesn't conform to the defined attribute syntax. With an OID in the attribute value, the syntax is invalid, so the matchingRule is Undefined. Kurt From list@netscape.com Thu Jul 13 13:51:21 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02180 for ; Thu, 13 Jul 2000 13:51:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DHfVR13451; Thu, 13 Jul 2000 10:41:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DHnu605871; Thu, 13 Jul 2000 10:49:56 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 10:49:56 -0700 (PDT) Message-ID: <396E00DD.75CEA0E0@software.com> Date: Thu, 13 Jul 2000 10:48:13 -0700 From: sanjay jain Organization: Software.Com X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ldapext Subject: attribute type inheritence.. Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ZjWOp.A.WbB.CFgb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Could somebody please clarify if any or all of
SINGLE-VALUE/MULT-VALUE, COLLECTIVE/
non-COLLECTIVE and NO-USER-MODIFICATION/
USER-MODIFICATION specs are inherited while defining
a new attribute type as a subtype of another attribute.
Its not clear to me either from RFC 2252 or X.501 (1993)
Section 12.4.2.

thanks
sanjay From list@netscape.com Thu Jul 13 14:00:49 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02944 for ; Thu, 13 Jul 2000 14:00:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DHsaU22706; Thu, 13 Jul 2000 10:54:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DHxMM12818; Thu, 13 Jul 2000 10:59:22 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 10:59:22 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Jim Sermersheim" , Date: Thu, 13 Jul 2000 18:57:43 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Unique identifiers for LDAP attributes Reply-to: d.w.chadwick@salford.ac.uk CC: Message-ID: <396E1127.3130.93964BE@localhost> Priority: normal In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"St-Rh.A.3HD.4Ngb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT > Though I agree with the general notion of moving toward the use of > unique OIDs, there's a minor flaw with this statement. > > objectIdentifierFirstComponentMatch uses the OID syntax which can > either be a numericoid (1.2.3.4) or the descr form (cn), so it's still > usable with short names as it stands today. You have now hit on a bit of rfc2252 which is particularly hard to understand, viz: From 8.1 If the client supplies a filter using an objectIdentifierMatch whose matchValue oid is in the "descr" form, and the oid is not recognized by the server, then the filter is Undefined. David > Jim > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Jul 13 14:15:48 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03733 for ; Thu, 13 Jul 2000 14:15:47 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DI5sR18357; Thu, 13 Jul 2000 11:05:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DIEJI21383; Thu, 13 Jul 2000 11:14:19 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 11:14:19 -0700 (PDT) Message-Id: <4.3.2.7.0.20000713105943.00b2beb0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Jul 2000 11:14:12 -0700 To: sanjay jain From: "Kurt D. Zeilenga" Subject: Re: attribute type inheritence.. Cc: ldapext In-Reply-To: <396E00DD.75CEA0E0@software.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"1-UtED.A.yNF.5bgb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 10:48 AM 7/13/00 -0700, sanjay jain wrote: >Could somebody please clarify if any or all of >SINGLE-VALUE/MULT-VALUE, COLLECTIVE/ >non-COLLECTIVE and NO-USER-MODIFICATION/ >USER-MODIFICATION specs are inherited while defining >a new attribute type as a subtype of another attribute. >Its not clear to me either from RFC 2252 or X.501 (1993) >Section 12.4.2. X.501 could be clarified a bit in this area. I would think they should be inherited if not explicitly specified. foo;lang-en should be X if foo is X (where X is any of the above characteristics) I would also think some restrictions upon changes are likely appropriate. I don't think it makes much sense to have a non-collective subtype of a collective attribute. From list@netscape.com Thu Jul 13 14:42:12 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04888 for ; Thu, 13 Jul 2000 14:42:12 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DIWNR22756; Thu, 13 Jul 2000 11:32:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DIenQ03081; Thu, 13 Jul 2000 11:40:49 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 11:40:49 -0700 (PDT) Message-ID: From: "Salter, Thomas A" To: "Kurt D. Zeilenga" , sanjay jain Cc: ldapext Subject: RE: attribute type inheritence.. Date: Thu, 13 Jul 2000 14:41:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"7je19.A.xv.v0gb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Actually X.501 is pretty clear that only syntax and matching rules are inherited. 12.4.2 explicitly discusses inheriting syntax and matching rules. The ASN.1 definition of ATTRIBUTE defines default values for single-valued, collective, no-user-modification, and usage, so there is no possibility of inheriting them. Derivation, Type and the matching rules are all optional, with the note about one of Type or derivation being required. The only inheritance restriction (that I could find) is that user attributes and operational attributes can not inherit from each other. From X.501, 12.4.6 Attribute definition Attributes may be defined as values of the ATTRIBUTE information object class: ATTRIBUTE ::= CLASS { &derivation ATTRIBUTE OPTIONAL, &Type OPTIONAL, -- either &Type or &derivation required -- &equality-match MATCHING-RULE OPTIONAL, &ordering-match MATCHING-RULE OPTIONAL, &substrings-match MATCHING-RULE OPTIONAL, &single-valued BOOLEAN DEFAULT FALSE, &collective BOOLEAN DEFAULT FALSE, -- operational extensions -- &no-user-modification BOOLEAN DEFAULT FALSE, &usage AttributeUsage DEFAULT userApplications, &id OBJECT IDENTIFIER UNIQUE } WITH SYNTAX { [ SUBTYPE OF &derivation ] [ WITH SYNTAX &Type ] [ EQUALITY MATCHING RULE &equality-match ] [ ORDERING MATCHING RULE &ordering-match ] [ SUBSTRINGS MATCHING RULE &substrings-match ] [ SINGLE VALUE &single-valued ] [ COLLECTIVE &collective ] [ NO USER MODIFICATION &no-user-modification ] [ USAGE &usage ] ID &id } > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, July 13, 2000 2:14 PM > To: sanjay jain > Cc: ldapext > Subject: Re: attribute type inheritence.. > > > At 10:48 AM 7/13/00 -0700, sanjay jain wrote: > >Could somebody please clarify if any or all of > >SINGLE-VALUE/MULT-VALUE, COLLECTIVE/ > >non-COLLECTIVE and NO-USER-MODIFICATION/ > >USER-MODIFICATION specs are inherited while defining > >a new attribute type as a subtype of another attribute. > >Its not clear to me either from RFC 2252 or X.501 (1993) > >Section 12.4.2. > > X.501 could be clarified a bit in this area. > > I would think they should be inherited if not explicitly > specified. > > foo;lang-en should be X if foo is X > > (where X is any of the above characteristics) > > I would also think some restrictions upon changes are likely > appropriate. I don't think it makes much sense to have a > non-collective subtype of a collective attribute. > > From list@netscape.com Thu Jul 13 14:47:32 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05114 for ; Thu, 13 Jul 2000 14:47:31 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DIbhR23730; Thu, 13 Jul 2000 11:37:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DIk8I06160; Thu, 13 Jul 2000 11:46:08 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 11:46:08 -0700 (PDT) Message-ID: <396E0E09.5314BADE@software.com> Date: Thu, 13 Jul 2000 11:44:25 -0700 From: sanjay jain Organization: Software.Com X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Salter, Thomas A" CC: "Kurt D. Zeilenga" , ldapext Subject: Re: attribute type inheritence.. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"-aDpaC.A.0fB.u5gb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Salter, Thomas A" wrote: > Actually X.501 is pretty clear that only syntax and matching rules are > inherited. > > 12.4.2 explicitly discusses inheriting syntax and matching rules. > The ASN.1 definition of ATTRIBUTE defines default values for single-valued, > collective, no-user-modification, and usage, so there is no possibility of > inheriting them. That's what I thought too ... > Derivation, Type and the matching rules are all optional, > with the note about one of Type or derivation being required. > > The only inheritance restriction (that I could find) is that user attributes > and operational attributes can not inherit from each other. > > >From X.501, > 12.4.6 Attribute definition > Attributes may be defined as values of the ATTRIBUTE information object > class: > ATTRIBUTE ::= CLASS { > &derivation ATTRIBUTE OPTIONAL, > &Type OPTIONAL, -- either &Type or &derivation required -- > &equality-match MATCHING-RULE OPTIONAL, > &ordering-match MATCHING-RULE OPTIONAL, > &substrings-match MATCHING-RULE OPTIONAL, > &single-valued BOOLEAN DEFAULT FALSE, > &collective BOOLEAN DEFAULT FALSE, > -- operational extensions -- > &no-user-modification BOOLEAN DEFAULT FALSE, > &usage AttributeUsage DEFAULT userApplications, > &id OBJECT IDENTIFIER UNIQUE } > WITH SYNTAX { > [ SUBTYPE OF &derivation ] > [ WITH SYNTAX &Type ] > [ EQUALITY MATCHING RULE &equality-match ] > [ ORDERING MATCHING RULE &ordering-match ] > [ SUBSTRINGS MATCHING RULE &substrings-match ] > [ SINGLE VALUE &single-valued ] > [ COLLECTIVE &collective ] > [ NO USER MODIFICATION &no-user-modification ] > [ USAGE &usage ] > ID &id } > > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > Sent: Thursday, July 13, 2000 2:14 PM > > To: sanjay jain > > Cc: ldapext > > Subject: Re: attribute type inheritence.. > > > > > > At 10:48 AM 7/13/00 -0700, sanjay jain wrote: > > >Could somebody please clarify if any or all of > > >SINGLE-VALUE/MULT-VALUE, COLLECTIVE/ > > >non-COLLECTIVE and NO-USER-MODIFICATION/ > > >USER-MODIFICATION specs are inherited while defining > > >a new attribute type as a subtype of another attribute. > > >Its not clear to me either from RFC 2252 or X.501 (1993) > > >Section 12.4.2. > > > > X.501 could be clarified a bit in this area. > > > > I would think they should be inherited if not explicitly > > specified. > > > > foo;lang-en should be X if foo is X > > > > (where X is any of the above characteristics) > > > > I would also think some restrictions upon changes are likely > > appropriate. I don't think it makes much sense to have a > > non-collective subtype of a collective attribute. > > > > From list@netscape.com Thu Jul 13 14:53:43 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05311 for ; Thu, 13 Jul 2000 14:53:43 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DIlWU02201; Thu, 13 Jul 2000 11:47:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DIqJg09370; Thu, 13 Jul 2000 11:52:19 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 11:52:19 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 13 Jul 2000 12:51:47 -0600 From: "Ed Reed" To: , , , "Kurt D. Zeilenga" , Cc: , , Subject: Re: LDAP subentry schema request for last call - Further Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e6DIqH109341 Resent-Message-ID: <"eYWQ4B.A.DSC.h_gb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit After further reviewing the minutes from Australia, the LDUP meeting minutes called for a discussion on use of Auxilliary classes with LDAPsubentry in favor of deriving new classes from LDAPsubentry, as a general rule, and the LDUP minutes asked that the document be revised to include that advisory direction to readers. However, it was noted there that naming is an issue again, when AUX classes don't resolve. The draft on the web site doesn't address this. Section 3.1 begins with the following statement: "The class ldapSubEntry is intended to be used as a super class when defining other structural classes to be used as LDAP Subentries. The presence of ldapSubEntry in the list of super-classes of an entry in the directory makes that entry an LDAP Subentry. Object classes derived from ldapSubEntry are themselves considered ldapSubEntry classes, for the purpose of this discussion." We could elaborate on the request, here, such as... "The class ldapSubEntry is intended to be used as a super- class when defining other structural classes to be used as LDAP Subentries, and as the structural class to which Auxilliary classes may be added for application specific subentry information. Where possible, the use of Auxilliary classes to extend ldapSubEntries is strongly preferred. The presence of ldapSubEntry in the list..." I think that would leave the naming issue (not using cn to name the subentry) as an excersize for the Auxilliary class definer, which might be a cruel booby-prize...but if Kurt and others find it acceptible, fine. I'm sorry I found this note in the minutes after I'd already said the doc was ready to go to last call. I'll make the change, as described here in the version that goes to the RFC editor. Does that work? Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Ed Reed" 07/13/00 09:55AM >>> After reviewing the recent comments on LDAPsubentry (and posting my reply), and reviewing where the March 9 version of the doc (as posted on the LDUP wg web site) stands with regard to MUST/MAY (cn) and naming, I think the document, as published, should go forward for last call. With regard to naming, the doc says LDAPsubentry MAY be named by cn, which is where I think the concensus of the list now resides. With regard to MUST/MAY {cn} as an attribute, the document now says MAY, and leaves the class as a STRUCTURAL class. Of course, that means that a naming rule will need to use CN as it's naming attribute if no other attributes are defined on the class, which pretty much turns it into a MUST in those cases, but when other classes are derived from LDAPsubentry other attributes may also be defined, and then cn need not be used as a naming attribute. I think we could also make it be MUST {cn} and require cns to be populated, even if they're not being used to name the LDAPsubentry, and I'll be happy to make that change after last call if needed. I just don't see the need to bother, now. With regard to making LDAPsubentry fully compatible with the X.500 subentry, it's been pointed out that people wanting to use the X.500 subentry should feel free to do so - it's incorporated by reference in the base LDAP definitions. The purpose of this proposal is to define a subset of the X.500 functionality (and extend the structural rules by allowing nesting of LDAPsubentries) for use by certain LDAP applications which find the subset functionality a useful simplification. So - Please, put out the last call for the draft as posted on the LDUP WG IETF Charter page, document draft-ietf-ldup-subentry-02.txt, dated 9 March 2000. Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From list@netscape.com Thu Jul 13 15:00:03 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05537 for ; Thu, 13 Jul 2000 15:00:02 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DIrpU03455; Thu, 13 Jul 2000 11:53:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DIwbg12106; Thu, 13 Jul 2000 11:58:37 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 11:58:37 -0700 (PDT) Date: Thu, 13 Jul 2000 13:57:49 -0500 From: Mark Wahl Subject: Re: LDAP subentry schema request for last call - Further In-reply-to: "Your message of Thu, 13 Jul 2000 12:51:47 MDT." Sender: wahl@austin.innosoft.com To: Ed Reed Cc: kurt@boolean.net, johns@cisco.com, capple@control.att.com, ietf-ldup@imc.org, ietf-ldapext@netscape.com, Kurt@openldap.org Message-id: <9615.963514669@threadgill.austin.innosoft.com> Resent-Message-ID: <"_S8hK.A.t8C.aFhb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > I'm sorry I found this note in the minutes after I'd already > said the doc was ready to go to last call. I'll make the change, > as described here in the version that goes to the RFC editor. > Does that work? Not that way. After review by the Working groups, the document is reviewed by the IETF as a whole and the IESG. The IETF as a whole and the IESG read the doc as presented in the I-D archive. Therefore if you want to make a technical change, you should make it before the document completes Working Group last call, so that it will be there before it enters IETF-wide last call. Since the WG chairs have not sent out the last call announcement, I'd recommend you make your change now. Mark Wahl, Directory Architect, Service Provider/Infrastructure Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Thu Jul 13 15:02:28 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05648 for ; Thu, 13 Jul 2000 15:02:27 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DIqVR27188; Thu, 13 Jul 2000 11:52:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DJ0vo13920; Thu, 13 Jul 2000 12:00:57 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 12:00:57 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 13 Jul 2000 13:00:10 -0600 From: "Ed Reed" To: Cc: , , , , , Subject: Re: LDAP subentry schema request for last call - Further Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e6DJ0r113853 Resent-Message-ID: <"0xSHwD.A.nYD.mHhb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit Thanks for the direction - will do. ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> Mark Wahl 07/13/00 12:58PM >>> > I'm sorry I found this note in the minutes after I'd already > said the doc was ready to go to last call. I'll make the change, > as described here in the version that goes to the RFC editor. > Does that work? Not that way. After review by the Working groups, the document is reviewed by the IETF as a whole and the IESG. The IETF as a whole and the IESG read the doc as presented in the I-D archive. Therefore if you want to make a technical change, you should make it before the document completes Working Group last call, so that it will be there before it enters IETF-wide last call. Since the WG chairs have not sent out the last call announcement, I'd recommend you make your change now. Mark Wahl, Directory Architect, Service Provider/Infrastructure Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Thu Jul 13 15:09:27 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05882 for ; Thu, 13 Jul 2000 15:09:27 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DJ3FU05287; Thu, 13 Jul 2000 12:03:15 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DJ81w18394; Thu, 13 Jul 2000 12:08:01 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 12:08:01 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 13 Jul 2000 13:07:06 -0600 From: "Ed Reed" To: Cc: , , , , Subject: Please publish draft-ietf-ldup-subentry-03.txt (true sequence number) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_441C1E68.D7B6DAC5" Resent-Message-ID: <"8Dldh.A.seE.QOhb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=_441C1E68.D7B6DAC5 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This document is going out for a joint last call to both the LDAPEXT and = LDUP working groups. Abstract: This document describes an object class called ldapSubEntry=20 which MAY be used to indicate operations and management=20 related entries in the directory, called LDAP Subentries. =20 This version of this document is updated with an assigned=20 OID for the ldapSubEntry object class. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_441C1E68.D7B6DAC5 Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-subentry-03.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQoNCg0KSU5URVJORVQtRFJBRlQgDQpkcmFmdC1pZXRmLWxkdXAtc3ViZW50cnktMDMu dHh0IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEVkIFJlZWQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVlZC1N YXR0aGV3cywgSW5jLiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBKdWx5IDEzLCAyMDAwIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQpMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KDQoxLiBT dGF0dXMgb2YgdGhpcyBNZW1vIA0KDQpUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0 IGFuZCBpcyBpbiBmdWxsIA0KY29uZm9ybWFuY2Ugd2l0aCBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0 aW9uIDEwIG9mIFJGQzIwMjYuIA0KIA0KSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3Vt ZW50cyBvZiB0aGUgSW50ZXJuZXQgDQpFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRz IGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgDQpncm91cHMuIE5vdGUgdGhhdCBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIA0KZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0 cy4gIA0KIA0KSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiANCnNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Ig b2Jzb2xldGVkIGJ5IA0Kb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBpbmFwcHJv cHJpYXRlIHRvIHVzZSANCkludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3Ig dG8gY2l0ZSB0aGVtIG90aGVyIA0KdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iICANCiANClRo ZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4gIA0KIA0KVGhlIGxpc3Qg b2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSANCmFjY2Vzc2VkIGF0 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0KIA0KVGhpcyBJbnRlcm5ldC1EcmFm dCBleHBpcmVzIG9uIFNlcHRlbWJlciA5LCAyMDAwLiANCg0KDQoyLiBBYnN0cmFjdCANCg0KVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgYW4gb2JqZWN0IGNsYXNzIGNhbGxlZCBsZGFwU3ViRW50cnkg DQp3aGljaCBNQVkgYmUgdXNlZCB0byBpbmRpY2F0ZSBvcGVyYXRpb25zIGFuZCBtYW5hZ2VtZW50 IA0KcmVsYXRlZCBlbnRyaWVzIGluIHRoZSBkaXJlY3RvcnksIGNhbGxlZCBMREFQIFN1YmVudHJp ZXMuICANClRoaXMgdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50IGlzIHVwZGF0ZWQgd2l0aCBhbiBh c3NpZ25lZCANCk9JRCBmb3IgdGhlIGxkYXBTdWJFbnRyeSBvYmplY3QgY2xhc3MuIA0KDQpUaGUg a2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgDQoiU0hB TEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIA0K YW5kICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFz IA0KZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4gVGhlIHNlY3Rpb25zIGJlbG93IA0K cmVpdGVyYXRlIHRoZXNlIGRlZmluaXRpb25zIGFuZCBpbmNsdWRlIHNvbWUgYWRkaXRpb25hbCAN Cm9uZXMuIA0KDQoNClJlZWQNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDFdIA0KICAgICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDksIDIwMDAgDQwNCg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA5IE1hcmNoIDIwMDAgDQogICAgICAgICAg ICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hlbWEgDQoNCjMuIERlZmluaXRpb24gDQoNCg0KMy4x IGxkYXBTdWJFbnRyeSBDbGFzcyANCg0KKCAyLjE2Ljg0MC4xLjExMzcxOS4yLjE0Mi42LjEuMSBO QU1FICdsZGFwU3ViRW50cnknICANCiAgIERFU0MgJ0xEQVAgU3ViZW50cnkgY2xhc3MsIHZlcnNp b24gMScgIA0KICAgICBTVVAgdG9wIFNUUlVDVFVSQUwgIA0KICAgICBNQVkgKCBjbiApICkgIA0K DQpUaGUgY2xhc3MgbGRhcFN1YkVudHJ5IGlzIGludGVuZGVkIHRvIGJlIHVzZWQgYXMgYSBzdXBl ci0gDQpjbGFzcyB3aGVuIGRlZmluaW5nIG90aGVyIHN0cnVjdHVyYWwgY2xhc3NlcyB0byBiZSB1 c2VkIA0KYXMgTERBUCBTdWJlbnRyaWVzLCBhbmQgYXMgdGhlIHN0cnVjdHVyYWwgY2xhc3MgdG8g d2hpY2ggDQpBdXhpbGlhcnkgY2xhc3NlcyBtYXkgYmUgYWRkZWQgZm9yIGFwcGxpY2F0aW9uIHNw ZWNpZmljIA0Kc3ViZW50cnkgaW5mb3JtYXRpb24uICBXaGVyZSBwb3NzaWJsZSwgdGhlIHVzZSBv ZiBBdXhpbGlhcnkgDQpjbGFzc2VzIHRvIGV4dGVuZCBsZGFwU3ViRW50cmllcyBpcyBzdHJvbmds eSBwcmVmZXJyZWQuIA0KIA0KVGhlIHByZXNlbmNlIG9mIGxkYXBTdWJFbnRyeSBpbiB0aGUgbGlz dCBvZiBzdXBlci1jbGFzc2VzIA0Kb2YgYW4gZW50cnkgaW4gdGhlIGRpcmVjdG9yeSBtYWtlcyB0 aGF0IGVudHJ5IGFuIExEQVAgDQpTdWJlbnRyeS4gIE9iamVjdCBjbGFzc2VzIGRlcml2ZWQgZnJv bSBsZGFwU3ViRW50cnkgYXJlIA0KdGhlbXNlbHZlcyBjb25zaWRlcmVkIGxkYXBTdWJFbnRyeSBj bGFzc2VzLCBmb3IgdGhlIHB1cnBvc2UgDQpvZiB0aGlzIGRpc2N1c3Npb24uIA0KDQpMREFQIFN1 YmVudHJpZXMgTUFZIGJlIG5hbWVkIGJ5IHRoZWlyIGNvbW1vbk5hbWUgYXR0cmlidXRlIA0KW0xE QVB2M10uICBPdGhlciBuYW1pbmcgYXR0cmlidXRlcyBhcmUgYWxzbyBwZXJtaXR0ZWQuIA0KDQpM REFQIFN1YmVudHJpZXMgTUFZIGJlIGNvbnRhaW5lcnMsIHVubGlrZSB0aGVpciBbWC41MDFdIA0K Y291bnRlcnBhcnRzLiANCg0KTERBUCBTdWJlbnRyaWVzIE1BWSBiZSBjb250YWluZWQgYnksIGFu ZCB3aWxsIHVzdWFsbHkgYmUgDQpsb2NhdGVkIGluIHRoZSBkaXJlY3RvcnkgaW5mb3JtYXRpb24g dHJlZSBpbW1lZGlhdGVseSANCnN1Ym9yZGluYXRlIHRvLCBhZG1pbmlzdHJhdGl2ZSBwb2ludHMg YW5kL29yIG5hbWluZyANCmNvbnRleHRzLiAgRnVydGhlciAodW5saWtlIFguNTAwIHN1YmVudHJp ZXMpLCBMREFQIA0KU3ViZW50cmllcyBNQVkgYmUgY29udGFpbmVkIGJ5IG90aGVyIExEQVAgU3Vi ZW50cmllcyAodGhlIA0Kd2F5IG9yZ2FuaXphdGlvbmFsIHVuaXRzIG1heSBiZSBjb250YWluZWQg Ynkgb3RoZXIgDQpvcmdhbml6YXRpb25hbCB1bml0cykuICBEZWVwIG5lc3RpbmdzIG9mIExEQVAg U3ViZW50cmllcyANCmFyZSBkaXNjb3VyYWdlZCwgYnV0IG5vdCBwcm9oaWJpdGVkLiANCg0KTERB UCBTdWJlbnRyaWVzIFNIT1VMRCBiZSB0cmVhdGVkIGFzICJvcGVyYXRpb25hbCBvYmplY3RzIiAN CmluIG11Y2ggdGhlIHNhbWUgd2F5IHRoYXQgIm9wZXJhdGlvbmFsIGF0dHJpYnV0ZXMiIGFyZSBu b3QgDQpyZWd1bGFybHkgcHJvdmlkZWQgaW4gc2VhcmNoIHJlc3VsdHMgYW5kIHJlYWQgb3BlcmF0 aW9ucyANCndoZW4gb25seSB1c2VyIGF0dHJpYnV0ZXMgYXJlIHJlcXVlc3RlZCkuICAgIA0KDQpM REFQIHNlcnZlcnMgU0hPVUxEIGltcGxlbWVudCB0aGUgZm9sbG93aW5nIHNwZWNpYWwgDQpoYW5k bGluZyBvZiBsZGFwU3ViRW50cnkgZW50cmllczogDQoNCmEpIHNlYXJjaCBvcGVyYXRpb25zIHdo aWNoIGluY2x1ZGUgYSBtYXRjaGluZyBjcml0ZXJpYSANCiJvYmplY3RjbGFzcz1sZGFwU3ViRW50 cnkiIE1VU1QgaW5jbHVkZSBlbnRyaWVzIGRlcml2ZWQgDQoNClJlZWQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXSANCiAgICAgICAg ICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDAwIA0KIA0MDQoNCg0KSU5URVJO RVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOSBNYXJj aCAyMDAwIA0KICAgICAgICAgICAgICAgICAgIExEQVAgU3ViZW50cnkgU2NoZW1hIA0KDQpmcm9t IHRoZSBsZGFwU3ViRW50cnkgY2xhc3MgaW4gdGhlIHNjb3BlIG9mIHRoZWlyIA0Kb3BlcmF0aW9u czsgICANCg0KYikgc2VhcmNoIG9wZXJhdGlvbnMgd2hpY2ggZG8gbm90IGluY2x1ZGUgYSBtYXRj aGluZyANCmNyaXRlcmlhICJvYmplY3RjbGFzcz1sZGFwU3ViRW50cnkiIE1VU1QgSUdOT1JFIGVu dHJpZXMgDQpkZXJpdmVkIGZyb20gdGhlIGxkYXBTdWJFbnRyeSBjbGFzcywgYW5kIGV4Y2x1ZGUg dGhlbSBmcm9tIA0KdGhlIHNjb3BlIG9mIHRoZWlyIG9wZXJhdGlvbnMuIA0KDQpUaGUgY29tYmlu YXRpb24gb2YgU0hPVUxEIGFuZCBNVVNUIGluIHRoZSBzcGVjaWFsIGhhbmRsaW5nIA0KaW5zdHJ1 Y3Rpb25zLCBhYm92ZSwgYXJlIG1lYW50IHRvIGNvbnZleSB0aGlzOiAgU2VydmVycyANClNIT1VM RCBzdXBwb3J0IHRoaXMgc3BlY2lhbCBoYW5kbGluZywgYW5kIGlmIHRoZXkgZG8gdGhleSANCk1V U1QgZG8gaXQgYXMgZGVzY3JpYmVkLCBhbmQgbm90IHNvbWUgb3RoZXIgd2F5LiANCg0KDQoNCjQu IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIA0KDQpMREFQIFN1YmVudHJpZXMgd2lsbCBmcmVxdWVu dGx5IGJlIHVzZWQgdG8gaG9sZCBkYXRhIHdoaWNoIA0KcmVmbGVjdHMgZWl0aGVyIHRoZSBhY3R1 YWwgb3IgaW50ZW5kZWQgYmVoYXZpb3Igb2YgdGhlIA0KZGlyZWN0b3J5IHNlcnZpY2UuICBBcyBz dWNoLCBwZXJtaXNzaW9uIHRvIHJlYWQgc3VjaCANCmVudHJpZXMgTUFZIG5lZWQgdG8gYmUgcmVz dHJpY3RlZCB0byBhdXRob3JpemVkIHVzZXJzLiAgDQpNb3JlIGltcG9ydGFudGx5LCBJRiBhIGRp cmVjdG9yeSBzZXJ2aWNlIHRyZWF0cyB0aGUgDQppbmZvcm1hdGlvbiBpbiBhbiBMREFQIFN1YmVu dHJ5IGFzIHRoZSBhdXRob3JpdGF0aXZlIHNvdXJjZSANCm9mIHBvbGljeSB0byBiZSB1c2VkIHRv IGNvbnRyb2wgdGhlIGJlaGF2aW9yIG9mIHRoZSANCmRpcmVjdG9yeSwgdGhlbiBwZXJtaXNzaW9u IHRvIGNyZWF0ZSwgbW9kaWZ5LCBvciBkZWxldGUgDQpzdWNoIGVudHJpZXMgTVVTVCBiZSBjYXJl ZnVsbHkgcmVzdHJpY3RlZCB0byBhdXRob3JpemVkIA0KYWRtaW5pc3RyYXRvcnMuIA0KDQoNCg0K NS4gUmVmZXJlbmNlcyANCg0KW0xEQVB2M10gUy4gS2lsbGUsIE0uIFdhaGwsIGFuZCBULiBIb3dl cywgIkxpZ2h0d2VpZ2h0IA0KRGlyZWN0b3J5IEFjY2VzcyBQcm90b2NvbCAodjMpIiwgUkZDIDIy NTEsIERlY2VtYmVyIDE5OTcgDQoNCltYLjUwMV0gSVRVLVQgUmVjLiBYLjUwMSwgIlRoZSBEaXJl Y3Rvcnk6IE1vZGVscyIsIDE5OTMgDQoNCg0KDQo2LiBDb3B5cmlnaHQgTm90aWNlIA0KDQpDb3B5 cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgxOTk5KS4gQWxsIFJpZ2h0cyANClJlc2Vy dmVkLiAgDQogDQpUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNv cGllZCBhbmQgDQpmdXJuaXNoZWQgdG8gb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0 IGNvbW1lbnQgb24gDQpvciBvdGhlcndpc2UgZXhwbGFpbiBpdCBvciBhc3Npc3QgaW4gaXRzIGlt cGxlbWVudGF0aW9uIG1heSANCmJlIHByZXBhcmVkLCBjb3BpZWQsIHB1Ymxpc2hlZCBhbmQgZGlz dHJpYnV0ZWQsIGluIHdob2xlIG9yIA0KDQpSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10gDQogICAgICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAwMCANCiANDA0KDQoNCklOVEVSTkVULURSQUZUICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDkgTWFyY2ggMjAwMCANCiAg ICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KaW4gcGFydCwgd2l0aG91 dCByZXN0cmljdGlvbiBvZiBhbnkga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgDQphYm92ZSBjb3B5 cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCBhcmUgaW5jbHVkZWQgb24gDQphbGwgc3Vj aCBjb3BpZXMgYW5kIGRlcml2YXRpdmUgd29ya3MuIEhvd2V2ZXIsIHRoaXMgDQpkb2N1bWVudCBp dHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IA0KcmVtb3Zp bmcgdGhlIGNvcHlyaWdodCBub3RpY2Ugb3IgcmVmZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQgDQpT b2NpZXR5IG9yIG90aGVyIEludGVybmV0IG9yZ2FuaXphdGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQg DQpmb3IgdGhlIHB1cnBvc2Ugb2YgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hp Y2ggDQpjYXNlIHRoZSBwcm9jZWR1cmVzIGZvciBjb3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIElu dGVybmV0IA0KU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZSBmb2xsb3dlZCwgb3IgYXMgcmVxdWly ZWQgdG8gDQp0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLiAN CiANClRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBh bmQgDQp3aWxsIG5vdCBiZSByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyAN CnN1Y2Nlc3NvcnMgb3IgYXNzaWducy4gDQogDQpUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyANCnByb3ZpZGVkIG9uIGFuICJBUyBJUyIgYmFzaXMg YW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCANClRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBU QVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgDQpXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQs IElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgDQpUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNF IE9GIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCANCk5PVCBJTkZSSU5HRSBBTlkgUklHSFRT IE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgDQpNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIiANCg0KDQo3LiBBY2tub3dsZWRnZW1lbnRzIA0K DQpUaGUgdXNlIG9mIHN1YkVudHJ5IG9iamVjdCBjbGFzcyB0byBzdG9yZSBSZXBsaWNhIGFuZCAN ClJlcGxpY2F0aW9uIEFncmVlbWVudCBpbmZvcm1hdGlvbiBpcyBkdWUgcHJpbWFyaWx5IHRvIHRo ZSANCmx1Y2lkIGV4cGxhbmF0aW9uIGJ5IE1hcmsgV2FobCwgSW5ub3NvZnQsIG9mIGhvdyB0aGV5 IGNvdWxkIA0KYmUgdXNlZCBhbmQgZXh0ZW5kZWQuIA0KIA0KVGhlIElFVEYgdGFrZXMgbm8gcG9z aXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSANCm9mIGFueSBpbnRlbGxlY3R1 YWwgcHJvcGVydHkgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgDQpjbGFpbWVkIHRvIHBl cnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgDQp0ZWNobm9sb2d5IGRl c2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gDQp3aGljaCBhbnkgbGlj ZW5zZSB1bmRlciBzdWNoIHJpZ2h0cyBtaWdodCBvciBtaWdodCBub3QgYmUgDQphdmFpbGFibGU7 IG5laXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMgbWFkZSBhbnkgDQplZmZvcnQg dG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiBJbmZvcm1hdGlvbiBvbiB0aGUgDQpJRVRGJ3Mg cHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIHN0YW5kYXJkcy10cmFjayANCmFu ZCBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBiZSBmb3VuZCBpbiBCQ1AtMTEu IA0KQ29waWVzIG9mIGNsYWltcyBvZiByaWdodHMgbWFkZSBhdmFpbGFibGUgZm9yIHB1YmxpY2F0 aW9uIA0KYW5kIGFueSBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxl LCBvciB0aGUgDQpyZXN1bHQgb2YgYW4gYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwg bGljZW5zZSBvciANCnBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2Ygc3VjaCBwcm9wcmlldGFyeSBy aWdodHMgYnkgDQppbXBsZW1lbnRvcnMgb3IgdXNlcnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGNh biBiZSBvYnRhaW5lZCANCmZyb20gdGhlIElFVEYgU2VjcmV0YXJpYXQuIA0KIA0KDQoNClJlZWQg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSA0XSANCiAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDAwIA0K IA0MDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgOSBNYXJjaCAyMDAwIA0KICAgICAgICAgICAgICAgICAgIExEQVAgU3ViZW50cnkg U2NoZW1hIA0KDQpUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5n IHRvIGl0cyANCmF0dGVudGlvbiBhbnkgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBw bGljYXRpb25zLCANCm9yIG90aGVyIHByb3ByaWV0YXJ5IHJpZ2h0cyB3aGljaCBtYXkgY292ZXIg dGVjaG5vbG9neSB0aGF0IA0KbWF5IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlIHRoaXMgc3RhbmRh cmQuIFBsZWFzZSBhZGRyZXNzIA0KdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIEV4ZWN1dGl2 ZSBEaXJlY3Rvci4gDQoNCg0KOC4gQXV0aG9yJ3MgQWRkcmVzcyANCg0KICAgICBFZHdhcmRzIEUu IFJlZWQgDQogICAgIFJlZWQtTWF0dGhld3MsIEluYy4gDQogICAgIDEwNjQgRSAxNDAgTm9ydGgg DQogICAgIExpbmRvbiwgVVQgIDg0MDQyIA0KICAgICBVU0EgDQogICAgIEUtbWFpbDogZWVyQG9u Y2FsbGRiYS5jb20gIA0KICAgICAgDQogICAgIExEVVAgTWFpbGluZyBMaXN0OiBpZXRmLWxkdXBA aW1jLm9yZyAgDQogICAgIExEQVBFWFQgTWFpbGluZyBMaXN0OiBpZXRmLWxkYXBleHRAbmV0c2Nh cGUuY29tIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgNV0gDQogICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBT ZXB0ZW1iZXIgOSwgMjAwMCANCiANDA0K --=_441C1E68.D7B6DAC5-- From list@netscape.com Thu Jul 13 15:14:32 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06061 for ; Thu, 13 Jul 2000 15:14:31 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DJ4aR29416; Thu, 13 Jul 2000 12:04:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DJD2620599; Thu, 13 Jul 2000 12:13:02 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 12:13:02 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 13 Jul 2000 13:12:29 -0600 From: "Ed Reed" To: Cc: , , , , Subject: Please publish draft-ietf-ldup-subentry-03.txt - correct dates in headers and footers Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_9DC5C7B6.DEBFD3CC" Resent-Message-ID: <"peVw9C.A.ZBF.8Shb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=_9DC5C7B6.DEBFD3CC Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This document is going out for a joint last call to both the LDAPEXT and = LDUP working groups. Abstract: This document describes an object class called ldapSubEntry=20 which MAY be used to indicate operations and management=20 related entries in the directory, called LDAP Subentries. =20 This version of this document is updated with an assigned=20 OID for the ldapSubEntry object class. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_9DC5C7B6.DEBFD3CC Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-subentry-03.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQoNCg0KSU5URVJORVQtRFJBRlQgDQpkcmFmdC1pZXRmLWxkdXAtc3ViZW50cnktMDMu dHh0IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEVkIFJlZWQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVlZC1N YXR0aGV3cywgSW5jLiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBKdWx5IDEzLCAyMDAwIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQpMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KDQoxLiBT dGF0dXMgb2YgdGhpcyBNZW1vIA0KDQpUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0 IGFuZCBpcyBpbiBmdWxsIA0KY29uZm9ybWFuY2Ugd2l0aCBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0 aW9uIDEwIG9mIFJGQzIwMjYuIA0KIA0KSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3Vt ZW50cyBvZiB0aGUgSW50ZXJuZXQgDQpFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRz IGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgDQpncm91cHMuIE5vdGUgdGhhdCBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIA0KZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0 cy4gIA0KIA0KSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiANCnNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Ig b2Jzb2xldGVkIGJ5IA0Kb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBpbmFwcHJv cHJpYXRlIHRvIHVzZSANCkludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3Ig dG8gY2l0ZSB0aGVtIG90aGVyIA0KdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iICANCiANClRo ZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4gIA0KIA0KVGhlIGxpc3Qg b2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSANCmFjY2Vzc2VkIGF0 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0KIA0KVGhpcyBJbnRlcm5ldC1EcmFm dCBleHBpcmVzIG9uIFNlcHRlbWJlciA5LCAyMDAwLiANCg0KDQoyLiBBYnN0cmFjdCANCg0KVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgYW4gb2JqZWN0IGNsYXNzIGNhbGxlZCBsZGFwU3ViRW50cnkg DQp3aGljaCBNQVkgYmUgdXNlZCB0byBpbmRpY2F0ZSBvcGVyYXRpb25zIGFuZCBtYW5hZ2VtZW50 IA0KcmVsYXRlZCBlbnRyaWVzIGluIHRoZSBkaXJlY3RvcnksIGNhbGxlZCBMREFQIFN1YmVudHJp ZXMuICANClRoaXMgdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50IGlzIHVwZGF0ZWQgd2l0aCBhbiBh c3NpZ25lZCANCk9JRCBmb3IgdGhlIGxkYXBTdWJFbnRyeSBvYmplY3QgY2xhc3MuIA0KDQpUaGUg a2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgDQoiU0hB TEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIA0K YW5kICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFz IA0KZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4gVGhlIHNlY3Rpb25zIGJlbG93IA0K cmVpdGVyYXRlIHRoZXNlIGRlZmluaXRpb25zIGFuZCBpbmNsdWRlIHNvbWUgYWRkaXRpb25hbCAN Cm9uZXMuIA0KDQoNClJlZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0gDQogICAgICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSAxNywgMjAwMSANDA0KDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE3IEp1bHkgMjAwMCANCiAgICAgICAgICAg ICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KMy4gRGVmaW5pdGlvbiANCg0KDQozLjEg bGRhcFN1YkVudHJ5IENsYXNzIA0KDQooIDIuMTYuODQwLjEuMTEzNzE5LjIuMTQyLjYuMS4xIE5B TUUgJ2xkYXBTdWJFbnRyeScgIA0KICAgREVTQyAnTERBUCBTdWJlbnRyeSBjbGFzcywgdmVyc2lv biAxJyAgDQogICAgIFNVUCB0b3AgU1RSVUNUVVJBTCAgDQogICAgIE1BWSAoIGNuICkgKSAgDQoN ClRoZSBjbGFzcyBsZGFwU3ViRW50cnkgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBhcyBhIHN1cGVy LSANCmNsYXNzIHdoZW4gZGVmaW5pbmcgb3RoZXIgc3RydWN0dXJhbCBjbGFzc2VzIHRvIGJlIHVz ZWQgDQphcyBMREFQIFN1YmVudHJpZXMsIGFuZCBhcyB0aGUgc3RydWN0dXJhbCBjbGFzcyB0byB3 aGljaCANCkF1eGlsaWFyeSBjbGFzc2VzIG1heSBiZSBhZGRlZCBmb3IgYXBwbGljYXRpb24gc3Bl Y2lmaWMgDQpzdWJlbnRyeSBpbmZvcm1hdGlvbi4gIFdoZXJlIHBvc3NpYmxlLCB0aGUgdXNlIG9m IEF1eGlsaWFyeSANCmNsYXNzZXMgdG8gZXh0ZW5kIGxkYXBTdWJFbnRyaWVzIGlzIHN0cm9uZ2x5 IHByZWZlcnJlZC4gDQogDQpUaGUgcHJlc2VuY2Ugb2YgbGRhcFN1YkVudHJ5IGluIHRoZSBsaXN0 IG9mIHN1cGVyLWNsYXNzZXMgDQpvZiBhbiBlbnRyeSBpbiB0aGUgZGlyZWN0b3J5IG1ha2VzIHRo YXQgZW50cnkgYW4gTERBUCANClN1YmVudHJ5LiAgT2JqZWN0IGNsYXNzZXMgZGVyaXZlZCBmcm9t IGxkYXBTdWJFbnRyeSBhcmUgDQp0aGVtc2VsdmVzIGNvbnNpZGVyZWQgbGRhcFN1YkVudHJ5IGNs YXNzZXMsIGZvciB0aGUgcHVycG9zZSANCm9mIHRoaXMgZGlzY3Vzc2lvbi4gDQoNCkxEQVAgU3Vi ZW50cmllcyBNQVkgYmUgbmFtZWQgYnkgdGhlaXIgY29tbW9uTmFtZSBhdHRyaWJ1dGUgDQpbTERB UHYzXS4gIE90aGVyIG5hbWluZyBhdHRyaWJ1dGVzIGFyZSBhbHNvIHBlcm1pdHRlZC4gDQoNCkxE QVAgU3ViZW50cmllcyBNQVkgYmUgY29udGFpbmVycywgdW5saWtlIHRoZWlyIFtYLjUwMV0gDQpj b3VudGVycGFydHMuIA0KDQpMREFQIFN1YmVudHJpZXMgTUFZIGJlIGNvbnRhaW5lZCBieSwgYW5k IHdpbGwgdXN1YWxseSBiZSANCmxvY2F0ZWQgaW4gdGhlIGRpcmVjdG9yeSBpbmZvcm1hdGlvbiB0 cmVlIGltbWVkaWF0ZWx5IA0Kc3Vib3JkaW5hdGUgdG8sIGFkbWluaXN0cmF0aXZlIHBvaW50cyBh bmQvb3IgbmFtaW5nIA0KY29udGV4dHMuICBGdXJ0aGVyICh1bmxpa2UgWC41MDAgc3ViZW50cmll cyksIExEQVAgDQpTdWJlbnRyaWVzIE1BWSBiZSBjb250YWluZWQgYnkgb3RoZXIgTERBUCBTdWJl bnRyaWVzICh0aGUgDQp3YXkgb3JnYW5pemF0aW9uYWwgdW5pdHMgbWF5IGJlIGNvbnRhaW5lZCBi eSBvdGhlciANCm9yZ2FuaXphdGlvbmFsIHVuaXRzKS4gIERlZXAgbmVzdGluZ3Mgb2YgTERBUCBT dWJlbnRyaWVzIA0KYXJlIGRpc2NvdXJhZ2VkLCBidXQgbm90IHByb2hpYml0ZWQuIA0KDQpMREFQ IFN1YmVudHJpZXMgU0hPVUxEIGJlIHRyZWF0ZWQgYXMgIm9wZXJhdGlvbmFsIG9iamVjdHMiIA0K aW4gbXVjaCB0aGUgc2FtZSB3YXkgdGhhdCAib3BlcmF0aW9uYWwgYXR0cmlidXRlcyIgYXJlIG5v dCANCnJlZ3VsYXJseSBwcm92aWRlZCBpbiBzZWFyY2ggcmVzdWx0cyBhbmQgcmVhZCBvcGVyYXRp b25zIA0Kd2hlbiBvbmx5IHVzZXIgYXR0cmlidXRlcyBhcmUgcmVxdWVzdGVkKS4gICAgDQoNCkxE QVAgc2VydmVycyBTSE9VTEQgaW1wbGVtZW50IHRoZSBmb2xsb3dpbmcgc3BlY2lhbCANCmhhbmRs aW5nIG9mIGxkYXBTdWJFbnRyeSBlbnRyaWVzOiANCg0KYSkgc2VhcmNoIG9wZXJhdGlvbnMgd2hp Y2ggaW5jbHVkZSBhIG1hdGNoaW5nIGNyaXRlcmlhIA0KIm9iamVjdGNsYXNzPWxkYXBTdWJFbnRy eSIgTVVTVCBpbmNsdWRlIGVudHJpZXMgZGVyaXZlZCANCg0KUmVlZCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0gDQogICAgICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxNywgMjAwMSANCiANDA0KDQoNCklOVEVSTkVU LURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE3IEp1bHkg MjAwMCANCiAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KZnJvbSB0 aGUgbGRhcFN1YkVudHJ5IGNsYXNzIGluIHRoZSBzY29wZSBvZiB0aGVpciANCm9wZXJhdGlvbnM7 ICAgDQoNCmIpIHNlYXJjaCBvcGVyYXRpb25zIHdoaWNoIGRvIG5vdCBpbmNsdWRlIGEgbWF0Y2hp bmcgDQpjcml0ZXJpYSAib2JqZWN0Y2xhc3M9bGRhcFN1YkVudHJ5IiBNVVNUIElHTk9SRSBlbnRy aWVzIA0KZGVyaXZlZCBmcm9tIHRoZSBsZGFwU3ViRW50cnkgY2xhc3MsIGFuZCBleGNsdWRlIHRo ZW0gZnJvbSANCnRoZSBzY29wZSBvZiB0aGVpciBvcGVyYXRpb25zLiANCg0KVGhlIGNvbWJpbmF0 aW9uIG9mIFNIT1VMRCBhbmQgTVVTVCBpbiB0aGUgc3BlY2lhbCBoYW5kbGluZyANCmluc3RydWN0 aW9ucywgYWJvdmUsIGFyZSBtZWFudCB0byBjb252ZXkgdGhpczogIFNlcnZlcnMgDQpTSE9VTEQg c3VwcG9ydCB0aGlzIHNwZWNpYWwgaGFuZGxpbmcsIGFuZCBpZiB0aGV5IGRvIHRoZXkgDQpNVVNU IGRvIGl0IGFzIGRlc2NyaWJlZCwgYW5kIG5vdCBzb21lIG90aGVyIHdheS4gDQoNCg0KDQo0LiBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyANCg0KTERBUCBTdWJlbnRyaWVzIHdpbGwgZnJlcXVlbnRs eSBiZSB1c2VkIHRvIGhvbGQgZGF0YSB3aGljaCANCnJlZmxlY3RzIGVpdGhlciB0aGUgYWN0dWFs IG9yIGludGVuZGVkIGJlaGF2aW9yIG9mIHRoZSANCmRpcmVjdG9yeSBzZXJ2aWNlLiAgQXMgc3Vj aCwgcGVybWlzc2lvbiB0byByZWFkIHN1Y2ggDQplbnRyaWVzIE1BWSBuZWVkIHRvIGJlIHJlc3Ry aWN0ZWQgdG8gYXV0aG9yaXplZCB1c2Vycy4gIA0KTW9yZSBpbXBvcnRhbnRseSwgSUYgYSBkaXJl Y3Rvcnkgc2VydmljZSB0cmVhdHMgdGhlIA0KaW5mb3JtYXRpb24gaW4gYW4gTERBUCBTdWJlbnRy eSBhcyB0aGUgYXV0aG9yaXRhdGl2ZSBzb3VyY2UgDQpvZiBwb2xpY3kgdG8gYmUgdXNlZCB0byBj b250cm9sIHRoZSBiZWhhdmlvciBvZiB0aGUgDQpkaXJlY3RvcnksIHRoZW4gcGVybWlzc2lvbiB0 byBjcmVhdGUsIG1vZGlmeSwgb3IgZGVsZXRlIA0Kc3VjaCBlbnRyaWVzIE1VU1QgYmUgY2FyZWZ1 bGx5IHJlc3RyaWN0ZWQgdG8gYXV0aG9yaXplZCANCmFkbWluaXN0cmF0b3JzLiANCg0KDQoNCjUu IFJlZmVyZW5jZXMgDQoNCltMREFQdjNdIFMuIEtpbGxlLCBNLiBXYWhsLCBhbmQgVC4gSG93ZXMs ICJMaWdodHdlaWdodCANCkRpcmVjdG9yeSBBY2Nlc3MgUHJvdG9jb2wgKHYzKSIsIFJGQyAyMjUx LCBEZWNlbWJlciAxOTk3IA0KDQpbWC41MDFdIElUVS1UIFJlYy4gWC41MDEsICJUaGUgRGlyZWN0 b3J5OiBNb2RlbHMiLCAxOTkzIA0KDQoNCg0KNi4gQ29weXJpZ2h0IE5vdGljZSANCg0KQ29weXJp Z2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMTk5OSkuIEFsbCBSaWdodHMgDQpSZXNlcnZl ZC4gIA0KIA0KVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3Bp ZWQgYW5kIA0KZnVybmlzaGVkIHRvIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBj b21tZW50IG9uIA0Kb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQgb3IgYXNzaXN0IGluIGl0cyBpbXBs ZW1lbnRhdGlvbiBtYXkgDQpiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQgYW5kIGRpc3Ry aWJ1dGVkLCBpbiB3aG9sZSBvciANCg0KUmVlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10gDQogICAgICAgICAgICAgICAgICAgICAg IEV4cGlyZXMgSmFudWFyeSAxNywgMjAwMSANCiANDA0KDQoNCklOVEVSTkVULURSQUZUICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE3IEp1bHkgMjAwMCANCiAgICAg ICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KaW4gcGFydCwgd2l0aG91dCBy ZXN0cmljdGlvbiBvZiBhbnkga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgDQphYm92ZSBjb3B5cmln aHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCBhcmUgaW5jbHVkZWQgb24gDQphbGwgc3VjaCBj b3BpZXMgYW5kIGRlcml2YXRpdmUgd29ya3MuIEhvd2V2ZXIsIHRoaXMgDQpkb2N1bWVudCBpdHNl bGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IA0KcmVtb3Zpbmcg dGhlIGNvcHlyaWdodCBub3RpY2Ugb3IgcmVmZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQgDQpTb2Np ZXR5IG9yIG90aGVyIEludGVybmV0IG9yZ2FuaXphdGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQgDQpm b3IgdGhlIHB1cnBvc2Ugb2YgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2gg DQpjYXNlIHRoZSBwcm9jZWR1cmVzIGZvciBjb3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIEludGVy bmV0IA0KU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZSBmb2xsb3dlZCwgb3IgYXMgcmVxdWlyZWQg dG8gDQp0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLiANCiAN ClRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBhbmQg DQp3aWxsIG5vdCBiZSByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyANCnN1 Y2Nlc3NvcnMgb3IgYXNzaWducy4gDQogDQpUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGhlcmVpbiBpcyANCnByb3ZpZGVkIG9uIGFuICJBUyBJUyIgYmFzaXMgYW5k IFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCANClRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBUQVNL IEZPUkNFIERJU0NMQUlNUyBBTEwgDQpXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElO Q0xVRElORyBCVVQgTk9UIExJTUlURUQgDQpUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9G IFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCANCk5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9S IEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgDQpNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBG T1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIiANCg0KDQo3LiBBY2tub3dsZWRnZW1lbnRzIA0KDQpU aGUgdXNlIG9mIHN1YkVudHJ5IG9iamVjdCBjbGFzcyB0byBzdG9yZSBSZXBsaWNhIGFuZCANClJl cGxpY2F0aW9uIEFncmVlbWVudCBpbmZvcm1hdGlvbiBpcyBkdWUgcHJpbWFyaWx5IHRvIHRoZSAN Cmx1Y2lkIGV4cGxhbmF0aW9uIGJ5IE1hcmsgV2FobCwgSW5ub3NvZnQsIG9mIGhvdyB0aGV5IGNv dWxkIA0KYmUgdXNlZCBhbmQgZXh0ZW5kZWQuIA0KIA0KVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRp b24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSANCm9mIGFueSBpbnRlbGxlY3R1YWwg cHJvcGVydHkgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgDQpjbGFpbWVkIHRvIHBlcnRh aW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgDQp0ZWNobm9sb2d5IGRlc2Ny aWJlZCBpbiB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gDQp3aGljaCBhbnkgbGljZW5z ZSB1bmRlciBzdWNoIHJpZ2h0cyBtaWdodCBvciBtaWdodCBub3QgYmUgDQphdmFpbGFibGU7IG5l aXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMgbWFkZSBhbnkgDQplZmZvcnQgdG8g aWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiBJbmZvcm1hdGlvbiBvbiB0aGUgDQpJRVRGJ3MgcHJv Y2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIHN0YW5kYXJkcy10cmFjayANCmFuZCBz dGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBiZSBmb3VuZCBpbiBCQ1AtMTEuIA0K Q29waWVzIG9mIGNsYWltcyBvZiByaWdodHMgbWFkZSBhdmFpbGFibGUgZm9yIHB1YmxpY2F0aW9u IA0KYW5kIGFueSBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBv ciB0aGUgDQpyZXN1bHQgb2YgYW4gYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGlj ZW5zZSBvciANCnBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2Ygc3VjaCBwcm9wcmlldGFyeSByaWdo dHMgYnkgDQppbXBsZW1lbnRvcnMgb3IgdXNlcnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGNhbiBi ZSBvYnRhaW5lZCANCmZyb20gdGhlIElFVEYgU2VjcmV0YXJpYXQuIA0KIA0KDQoNClJlZWQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDRd IA0KICAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTcsIDIwMDEgDQogDQwN Cg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAxNyBKdWx5IDIwMDAgDQogICAgICAgICAgICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hl bWEgDQoNClRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8g aXRzIA0KYXR0ZW50aW9uIGFueSBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNh dGlvbnMsIA0Kb3Igb3RoZXIgcHJvcHJpZXRhcnkgcmlnaHRzIHdoaWNoIG1heSBjb3ZlciB0ZWNo bm9sb2d5IHRoYXQgDQptYXkgYmUgcmVxdWlyZWQgdG8gcHJhY3RpY2UgdGhpcyBzdGFuZGFyZC4g UGxlYXNlIGFkZHJlc3MgDQp0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgRXhlY3V0aXZlIERp cmVjdG9yLiANCg0KDQo4LiBBdXRob3IncyBBZGRyZXNzIA0KDQogICAgIEVkd2FyZHMgRS4gUmVl ZCANCiAgICAgUmVlZC1NYXR0aGV3cywgSW5jLiANCiAgICAgMTA2NCBFIDE0MCBOb3J0aCANCiAg ICAgTGluZG9uLCBVVCAgODQwNDIgDQogICAgIFVTQSANCiAgICAgRS1tYWlsOiBlZXJAb25jYWxs ZGJhLmNvbSAgDQogICAgICANCiAgICAgTERVUCBNYWlsaW5nIExpc3Q6IGlldGYtbGR1cEBpbWMu b3JnICANCiAgICAgTERBUEVYVCBNYWlsaW5nIExpc3Q6IGlldGYtbGRhcGV4dEBuZXRzY2FwZS5j b20gDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNClJlZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDVdIA0KICAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVh cnkgMTcsIDIwMDEgDQogDQwNCg== --=_9DC5C7B6.DEBFD3CC-- From list@netscape.com Thu Jul 13 15:34:56 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06854 for ; Thu, 13 Jul 2000 15:34:53 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DJSfU09074; Thu, 13 Jul 2000 12:28:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DJXSU28178; Thu, 13 Jul 2000 12:33:28 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 12:33:28 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , , Date: Thu, 13 Jul 2000 20:31:19 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Unique identifiers for LDAP attributes Reply-to: d.w.chadwick@salford.ac.uk CC: , Message-ID: <396E2717.18099.98F1B68@localhost> Priority: normal In-reply-to: <4.3.2.7.0.20000713103300.00b31df0@infidel.boolean.net> References: X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"ngQbNC.A.m3G.Fmhb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date sent: Thu, 13 Jul 2000 10:37:33 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Unique identifiers for LDAP attributes Copies to: , > At 11:12 AM 7/13/00 -0600, Jim Sermersheim wrote: > >Though I agree with the general notion of moving toward the use of > >unique OIDs, there's a minor flaw with this statement. > > > >objectIdentifierFirstComponentMatch uses the OID syntax which can > >either be a numericoid (1.2.3.4) or the descr form (cn), so it's > >still usable with short names as it stands today. > > But note a minor flaw in your statement. A matchingRule should > evaluate to Undefined if the attribute value doesn't conform > to the defined attribute syntax. With an OID in the attribute > value, the syntax is invalid, so the matchingRule is Undefined. Now this could be the true meaning of the text that I said was particularly hard to understand in 8.4. At least I can understand what you have written and I agree with it David > > Kurt > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Jul 13 15:35:09 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06864 for ; Thu, 13 Jul 2000 15:34:57 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DJOxR02494; Thu, 13 Jul 2000 12:24:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6DJXOI28107; Thu, 13 Jul 2000 12:33:24 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 12:33:24 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com, ietf-ldapext@netscape.com Date: Thu, 13 Jul 2000 20:31:21 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Unique identifiers for LDAP attributes Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com, ietf-ldapext@netscape.com Message-ID: <396E2719.10594.98F2090@localhost> Priority: normal In-reply-to: <4.3.2.7.0.20000713102545.00b4d9c0@infidel.boolean.net> References: <396E03CB.11173.9053420@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"q3B1d.A.22G.Cmhb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date sent: Thu, 13 Jul 2000 10:30:35 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: Unique identifiers for LDAP attributes Copies to: ietf-ldapext@netscape.com, ietf-ldapext@netscape.com > At 06:00 PM 7/13/00 +0100, David Chadwick wrote: > >> Which implies they must be read-only servers... > > > >Why? Sorry, I dont follow this one. LDAP updates dont need to use > >OIDs. > > RFC 2251, 3.2.2: > A server which masters entries and permits clients to modify these > entries MUST implement and provide access to these subschema > entries, so that its clients may discover the attributes and object > classes which are permitted to be present. thanks, missed that bit David > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Fri Jul 14 00:44:04 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13917 for ; Fri, 14 Jul 2000 00:44:04 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6E4boU10819; Thu, 13 Jul 2000 21:37:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6E4gco07712; Thu, 13 Jul 2000 21:42:38 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 21:42:38 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C5B7CF9@aspams01.cai.com> From: "Ramsay, Ron" To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com Subject: RE: Unique identifiers for LDAP attributes Date: Fri, 14 Jul 2000 14:42:36 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"xvhIkC.A.J4B.9opb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David, I agree with the philosophy. However, there may be a middle course. Where the attribute has been standardised by appearing in an IETF standard, the name used in the standard could be considered standardised. For all other attributes, an OID is required. There may be other publication methods which can standardise attribute names, eg informational RFCs. Ron. -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] Sent: Friday, 14 July 2000 0:03 To: ietf-ldapext@netscape.com Subject: Unique identifiers for LDAP attributes Folks I was at a Middleware meeting a few weeks ago where some guys from Internet 2 were talking about outstanding problems with LDAP. One of the points raised was the lack of a unique name for attribute types, and that two LDAP servers could have the same name for different attributes or different names for the same attribute. They were wanting to create a group that could standardise on the names of LDAP attribute types. When I pointed out to them that we already have unique identifiers for each attribute type in the shape of OIDs, that do not have the multilingual and character set problems that strings have, they seemed convinced that this could work. However, we have the situation that some LDAP servers do not require OIDs to be defined for attribute types, and the LDAP spec deprecates the use of OIDs in protocol in preference to strings. Given that many LDAP clients now map the attribute type strings from protocol into a user friendly language dependent display string, the string representation in protocol has about had its day and served its purpose. Isnt it about time that we altered the LDAP spec to recommend that OIDs be the preferred way of transferring attribute types in protocol, and that the OIDs become the globally unique way of identifying attribute types. (Firewalls up to protect from flames) David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Fri Jul 14 00:54:13 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16110 for ; Fri, 14 Jul 2000 00:54:12 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6E4ltU11751; Thu, 13 Jul 2000 21:47:55 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6E4qg610481; Thu, 13 Jul 2000 21:52:42 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 21:52:42 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C5B7DC3@aspams01.cai.com> From: "Ramsay, Ron" To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com Subject: RE: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt Date: Fri, 14 Jul 2000 14:52:30 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"t3-xvB.A.cjC.Yypb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David, RE: Bruce's suggestion. This requires using his version of the family of entries. If you do, and you accept the maintenance issue of keeping all attribute values in sync, there is no reason why it can't work. However, I seem to sense some opposition to the concept and this is where we have a real problem. If an entry holds two certificates, there is no way of setting other attributes in the entry so that each of their values are associated with the appropriate certificate. I think the matching rule approach is the only solution. You may be able to have 'magic' attributes that have order-dependent values, but this is in conflict with the X.500 standard. One may always, of course, pregenerate the values of magic and invisible attributes that are only accessed with the application of specific matching rules. Ron. -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] Sent: Friday, 14 July 2000 0:03 To: Sean Mullan; ietf-pkix@imc.org; ietf-ldapext@netscape.com Cc: Boeyen@entrust.com Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt Date sent: Wed, 12 Jul 2000 19:31:31 +0100 From: Sean Mullan To: d.w.chadwick@salford.ac.uk Copies to: ietf-pkix@imc.org, ietf-ldapext@netscape.com Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt > Hi David, > > Some comments on the draft below. Sean, replies intersperced below > Section 3.2 Certificate Match > > I think the X.509 certificate matching rules are missing some > essential and important fields in the certificateAssertion structure > for filtering on certificates. We may want to consider defining a > superset. I submitted these comments to the X.509 editors but > apparently it was too late to integrate them into the 2000 update. > > * you should be able to match on more than one pathToName and on > non-X500 > name types. This is inconsistent with name constraints which allow > you to constrain to more than one name and different name types. > I agree that alternative name types should be allowed. But maybe it is not necessary to have multiple names, since you can do several Searches providing one name for each search (remember that the name presented should be allowed to have a cert path created to it) How do we want to handle this: i) issue a defect on X.509 (Sharon can you comment on this) ii) let the LDAP matching rule be a superset of the X.509 one? I would favour the former route myself. > * you should be able to match on more than the subject alt name > type. Agreed. This is a lack of clarity in the ID. It is intended that the whole name can be presented along with the type. The text is ambiguous in this respect and I will fix it. It will also be clearer when version 1 is published that contains BNF for each of the fields. Steven Legg has been doing this for me. > You > should also be able to match on the subject alt name itself, and > specify more than one subject alt name as certificates can contain > more than one. > Concerning multiple names, I think this can be solved by performing multiple searches with a single name in each search. > * you should be able to match on the subject public key as well as > the subject public > key algorithm OID. > you can match on the subject key identifier (3rd component) > * you should be able to match on the basic constraints extension, > especially the > maxPathLen value. This is useful for finding potential > certificates when building certification paths from the target to > the most-trusted CA. For ex, if a partial path has been built, any > candidate certificate must have a maxPathLen value greater than or > equal to the number of certificates in the partial path. > Interestingly this has been defined for attribute certificates and not pk certs. I actually think that the way matching for ACs has been handled is far superior than for PKcerts. ie. a separate matching rule for each extension, rather than one long complex rule for pk certs. However, there would be nothing to stop an implementation dynamically attaching the basicAttConstraintsMatch to public key certs. In fact this matching rule could be renamed the basicConstraintsMatch anyway as the syntax is the same for both ACs and PKCs. This is my preferred approach. > I think it is very important to include the Certificate pair matching > rules, as these are very useful when building certification paths and > trying to discover which of many cross certificates satisfy various > validation constraints, and eliminating those that do not. > OK, this can be done. It is just time consuming and I wanted to know if there was a demand first. > Other comments: > > * What RFC format are you using for the encoding of DNs - 1779? This > should be referenced. It should be 2253 for LDAPv3. > > Section 4.2 Certificate List Match > > There is an error in the CertificateListAssertion definition in X.509 > 2000. The authorityKeyIdentifier component should be marked OPTIONAL. > This probably doesn't affect your definition, but I just wanted to > make you aware of it. Agreed, Sharon, can you make a note of this defect David p.s. what do you think about Bruce's assertion that none of this is needed and instead we should have a bunch of simple attributes in the LDAP entry David > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Fri Jul 14 01:01:07 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17629 for ; Fri, 14 Jul 2000 01:01:06 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6E4p9R03856; Thu, 13 Jul 2000 21:51:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6E4xZw13108; Thu, 13 Jul 2000 21:59:35 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 21:59:35 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C5B7E64@aspams01.cai.com> From: "Ramsay, Ron" To: Rob Byrne - Sun Microsystems , "Lloyd, Alan" , ietf-ldapext@netscape.com, Albert.Langer@directory-designs.org Subject: RE: LDAP subentry alignment with X.500 subentry Date: Fri, 14 Jul 2000 14:59:32 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"UfE3TD.A.TMD.14pb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Rob, I wasn't try to say that filters are not unpredictable, or that the scheme you propose is unworkable. My point is simply that, if Joe Average, Sytem Administrator, defines a filter (eq employees with manager X cannot access payroll files) and if user's actually have access to that attribute, there may be security implications (eg user deletes manager attribute). Note that filters have syntax (easy), semantics (harder) and exception (very hard). One exception is the tri-valued nature of the filter ('unknown'). Ron. -----Original Message----- From: Rob Byrne - Sun Microsystems [mailto:Robert.Byrne@france.sun.com] Sent: Friday, 14 July 2000 2:08 To: Lloyd, Alan; Ramsay, Ron; ietf-ldapext@netscape.com; Albert.Langer@directory-designs.org Subject: Re: LDAP subentry alignment with X.500 subentry Ron/Alan/Albert, Thanks for your responses. [Ron] I can so no purpose either for a general filter in a subentry of for scopes in entry ACI. The problem with the former is that, if the filter relates to telephoneNumber, for example, and the user deletes this attribute from his entry, the ACI may now behave unpredictably. Ron, in our LDAP server we provide this as a way to define entries to which acis apply and this feature is used. The effect is not unpredictable--the behaviour of filters is well defined. Though I agree that if the admin does not define his policy well, the effect may be unexpected. I think that the use of this feature provides flexibilty but demands good management by the admin--I guess it's a trade off. From list@netscape.com Fri Jul 14 02:31:43 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03700 for ; Fri, 14 Jul 2000 02:31:42 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6E6LpR09203; Thu, 13 Jul 2000 23:21:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6E6UHM03962; Thu, 13 Jul 2000 23:30:17 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 23:30:17 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: Revised Matched Values Draft Date: Fri, 14 Jul 2000 16:32:49 +1000 Message-ID: <001601bfed5d$551d0590$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <4.3.2.7.0.20000712095723.00aedef0@infidel.boolean.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Resent-Message-ID: <"AFTc6D.A.Y9.3Nrb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, 13 July 2000 3:05 > To: Lloyd, Alan > Cc: Miklos, Sue A.; Bruce Greenblatt; d.w.chadwick@salford.ac.uk; > ietf-ldapext@netscape.com > Subject: RE: Revised Matched Values Draft > > > At 11:38 PM 7/12/00 +1000, Lloyd, Alan wrote: > >Isnt it amazing that the reason for LDAP was that DAP was > too complex - and > >here we are (years later) adding more complexity to LDAP > beyond that of > >DAP..:-) > > regards alan > > The primary complexity of DAP that LDAP removed was need to implement > the ISO protocol stack. Even the OSI stack can be avoided now. The 2000 edition of X.500 contains the provisions for mapping the protocols directly onto TCP/IP. Regards, Steven From list@netscape.com Fri Jul 14 02:53:14 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11720 for ; Fri, 14 Jul 2000 02:53:14 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6E6h7R10434; Thu, 13 Jul 2000 23:43:07 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6E6pWc08140; Thu, 13 Jul 2000 23:51:32 -0700 (PDT) Resent-Date: Thu, 13 Jul 2000 23:51:32 -0700 (PDT) Reply-To: From: "Steven Legg" To: Cc: Subject: RE: Revised Matched Values Draft Date: Fri, 14 Jul 2000 16:54:07 +1000 Message-ID: <001701bfed60$4f391e90$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <396BAF5F.18224.11D7E459@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Resent-Message-ID: <"zcMQBC.A.u-B.yhrb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit David, > -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] > Sent: Wednesday, 12 July 2000 8:36 > To: Kurt D. Zeilenga > Cc: ietf-ldapext@netscape.com > Subject: Re: Revised Matched Values Draft > > > Kurt > [snip] > > >An LDAP search operation is specified with a baseObject > set to the DN > > >of the entry, a subtree scope, a filter set to > > > >"(|(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk))", and > > > the list of attributes to be returned set to "mail > telephoneNumber". > > > In addition, a ValuesReturnFilter control is set to > > >"mail=sean.mullan@sun.com, mail=d.w.chadwick@salford.ac.uk, > > >telephoneNumber=*" > > > > Please use parentheses. In fact, you may want to define a string > > format for ValuesReturnFilter. I suggest something like: > > > > > (:(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk)(teleph > > oneNumber=*)) > > > > or if that looks too much like a search filter: > > > > > {(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk)(telepho > > neNumber=*)} > > I think it would be a good idea for the LDAP group to settle on a > character that can represent the ASN.1 type SEQUENCE, and > another that can represent a SET. I think it would be a good idea for the LDAP group to settle on a uniform predictable way of encoding any ASN.1 type (I volunteer to write an I-D on it if there's any support) but that is another story. > I need this also for my PKI and > PMI schema document. Steven Legg is working on this at the > moment, but lets assume for now that comma , represents > SEQUENCE and + represents SET. Unfortunately we have not > been too consistent in this in the past, as comma has represented > both, and + has also represented SET (e.g. as in DNs) I don't see any need to distinguished between SET and SEQUENCE in a string encoding. They can just as well use the same separator, or if the components of the SET/SEQUENCE are self-contained as in Kurt's suggestion above then no separators are necessary. ASN.1 value notation also treats SET & SEQUENCE the same, and I suspect the comma separators there are cosmetic anyway. [snip] Regards, Steven > *************************************************** > > David Chadwick > IS Institute, University of Salford, Salford M5 4WT > Tel +44 161 295 5351 Fax +44 161 745 8169 > Mobile +44 790 167 0359 > Email D.W.Chadwick@salford.ac.uk > Home Page http://www.salford.ac.uk/its024/chadwick.htm > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string MLJ9-DU5T-HV8J > > *************************************************** > > From list@netscape.com Fri Jul 14 03:15:54 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18025 for ; Fri, 14 Jul 2000 03:15:52 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6E78DU20654; Fri, 14 Jul 2000 00:08:16 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6E7D0U13773; Fri, 14 Jul 2000 00:13:00 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 00:13:00 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C5C82FC@aspams01.cai.com> From: "Ramsay, Ron" To: steven.legg@adacel.com.au, "'Kurt D. Zeilenga'" Cc: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft Date: Fri, 14 Jul 2000 17:12:58 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"_gFhu.A.4WD.71rb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com You got your proposal through? -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Friday, 14 July 2000 16:33 To: 'Kurt D. Zeilenga' Cc: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, 13 July 2000 3:05 > To: Lloyd, Alan > Cc: Miklos, Sue A.; Bruce Greenblatt; d.w.chadwick@salford.ac.uk; > ietf-ldapext@netscape.com > Subject: RE: Revised Matched Values Draft > > > At 11:38 PM 7/12/00 +1000, Lloyd, Alan wrote: > >Isnt it amazing that the reason for LDAP was that DAP was > too complex - and > >here we are (years later) adding more complexity to LDAP > beyond that of > >DAP..:-) > > regards alan > > The primary complexity of DAP that LDAP removed was need to implement > the ISO protocol stack. Even the OSI stack can be avoided now. The 2000 edition of X.500 contains the provisions for mapping the protocols directly onto TCP/IP. Regards, Steven From list@netscape.com Fri Jul 14 04:25:23 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03168 for ; Fri, 14 Jul 2000 04:25:23 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6E8FCR16812; Fri, 14 Jul 2000 01:15:13 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6E8Ndo03223; Fri, 14 Jul 2000 01:23:39 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 01:23:39 -0700 (PDT) X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: , , , Cc: Subject: RE: LDAP subentry alignment with X.500 subentry Date: Fri, 14 Jul 2000 18:23:16 +1000 Message-ID: <001701bfed6c$c3a0a800$17448490@vic.bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <396DE97A.CE8EA105@france.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Resent-Message-ID: <"UN4RN.A.Ay.J4sb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit [Albert] LDAP standards must not unnecessarily limit implementation choices. Filter specifications on object classes work with either model, since every entry knows its object classes and can easily calculate an arbitrary filter on them quickly when determining visibility during searches. [Robert] Albert, doesn't an entry know the other attributes that it contains as well and so could evaluate an arbitrary filter ? [Albert] Sorry, I should have said "the (structural) object class of an entry is fixed and therefore the set of applicable subentries does not need to be recalculated on every search". With general filters such a calculation would be needed on every search, for every subentry that has a parent within the base of the search applied to every entry within the scope of the search. This is multiplying the cost of a search by the number of potentially applicable subentries (not just the number of actually applicable subentries). [Albert] General filters really only work with a traversal based implementation and are basically just an attempt to substitute regexp evaluation on path names familiar to centralized web administrators for a serious admin model that can actually be delegated. The apparant additional flexibility is illusory since it [Robert] Don't catch this--a general filter refers to values of attributes within the entry, not the dn of the entry. As I pointed out above, users of our directory make use of this "illusion" all the time. [Albert] Whoops, I was arguing against the use of regexp path based ACIs as used in UMich derived implementations. As you say, this is irrelevant to your suggestion for (entry) attribute based filters (assuming that a "generic" filter does not treat dn as an attribute). That's what comes from responding from "off the top of my head". My other argument above still stands. [Robert] For the second question, "what is so great about using subentries for acis?", I think Alan's response was clearest. For my own benefit I've tried to distill (quite a lot!) the main points to the points listed below. I don't dispute them, but I would say that the "aci attribute" approach also allows seperation (it's an operational attribute) and delegation (you've got rights to that attribute or not)...though not to the same extent as the subentry approach. [...] [Albert] I've just realised this topic is across ldap-ext as well as ldup. I'm not subscribed to ldap-ext and don't have time to be at the moment, so I'm not plannning to comment further. For the record though, I believe that: 1. The LDAP subentry proposal is adequate for current LDUP needs. It may be more than adequate because allowing nested families of subentries may not be strictly necessary since the replication agreements children of subentries contain the dn of the replica they apply to. It also appears to still rely on special case semantics for the meaning of a child subentry of replica entry. Changing the structure rules is not a minor variant and if done I would prefer to see it done more fully as in: Chadwick, D.W., "Compound (Families of) Entries", Internet-Draft, draft-chadwick-families-00.txt, (expired) 5 December 1999. Ed's argument for a subset of X.500 rather than a superset is convincing. Its application to a final call for endorsement of a superset by varying structure rules is not convincing. But somebody has to either object now or hold their peace. I'm sticking to my objection to the replication requirements but holding my peace on subentries. If you want a different superset you need to object now. 2. There will be future LDUP needs for subtree specifications related to management of the creation of new replication areas. However this is beyond the current scope. 3. LDAP-EXT ACI ought to have requirements for Directory Access Control Domains, which need subentry specifications with object class filters. Not having them severely complicates simple things like delegating management of printers to printer operators across organizational unit boundaries as well as across both distribution and replication boundaries. I pointed this out at the Melbourne IETF but I don't have time to pursue it. 4. Issues like LDAP subentries are quite naturally across both WGs. In my view there is a vital need for coordination of issues like transactions and ACI across both groups. The current replication proposals from LDUP will impede if not prevent any deployment of transactions. This however may not matter as they will also not meet any reasonable requirements for ACI and therefore are unworkable anyway. This is independent of whether ACI should include DACDs. Any workable ACI MUST be replicated atomically and the current LDUP proposals fail to achieve that, so discussion of attempts to standardize subentries for ACI as well as for replication within LDUP are rather pointless. 5. LDAP-EXT has, and should therefore state, a clear requirement for atomic replication of ACI attributes so that LDUP could stop trying to avoid the issue. Despite the overlap of authorship of the two requirements documents there is no indication of any understanding of the impact of non-atomicity on ACI. Anyone in LDAP-EXT interested in this should look at my objection and alternative to the current LDUP proposals: http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt Please send or CC any comments to LDUP as I won't see them in LDAP-EXT. Seeya, Albert From list@netscape.com Fri Jul 14 06:24:43 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01706 for ; Fri, 14 Jul 2000 06:24:43 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6EAIUU01625; Fri, 14 Jul 2000 03:18:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6EANIs27556; Fri, 14 Jul 2000 03:23:18 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 03:23:18 -0700 (PDT) Sender: Sean.Mullan@ireland.Sun.COM Message-ID: <396EEA0E.3B40642B@sun.com> Date: Fri, 14 Jul 2000 11:23:10 +0100 From: Sean Mullan X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: d.w.chadwick@salford.ac.uk CC: ietf-pkix@imc.org, ietf-ldapext@netscape.com, Boeyen@entrust.com Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt References: <396DDA12.874.862330B@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"DufrGC.A.PuG.Voub5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit David, David Chadwick wrote: > > Date sent: Wed, 12 Jul 2000 19:31:31 +0100 > From: Sean Mullan > To: d.w.chadwick@salford.ac.uk > Copies to: ietf-pkix@imc.org, ietf-ldapext@netscape.com > Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt > > > Hi David, > > > > Some comments on the draft below. > > Sean, replies intersperced below > > > Section 3.2 Certificate Match > > > > I think the X.509 certificate matching rules are missing some > > essential and important fields in the certificateAssertion structure > > for filtering on certificates. We may want to consider defining a > > superset. I submitted these comments to the X.509 editors but > > apparently it was too late to integrate them into the 2000 update. > > > > * you should be able to match on more than one pathToName and on > > non-X500 > > name types. This is inconsistent with name constraints which allow > > you to constrain to more than one name and different name types. > > > > I agree that alternative name types should be allowed. But maybe it > is not necessary to have multiple names, since you can do several > Searches providing one name for each search (remember that the > name presented should be allowed to have a cert path created to it) Yes, but I think this is a bit more complex. I think ideally you should be able to define in one matching rule all the selection criteria for a certificate. So if a certificate contains more than one alt name, the matching rule should allow you to match on more than one alt name. For ex, in one search I would like to get all the certs issued by some DN that allow a path to be built to the subject altnames of "cn=mullan,o=sun,c=us" and "sean.mullan@sun.com". If I break this into 2 searches, I am likely to get duplicate certs or certs that allows paths to be built to one of the names but not both. Specifying 2 matching rules in one search would have similar problems. > How do we want to handle this: > i) issue a defect on X.509 (Sharon can you comment on this) > ii) let the LDAP matching rule be a superset of the X.509 one? > > I would favour the former route myself. I agree - if it doesn't take too long. > > * you should be able to match on more than the subject alt name > > type. > > Agreed. This is a lack of clarity in the ID. It is intended that the > whole name can be presented along with the type. The text is > ambiguous in this respect and I will fix it. It will also be clearer when > version 1 is published that contains BNF for each of the fields. > Steven Legg has been doing this for me. The X.509 certificateAssertion only allows you to match on the alt name type - that's the problem I was referring to - that should be fixed. > > You > > should also be able to match on the subject alt name itself, and > > specify more than one subject alt name as certificates can contain > > more than one. > > > > Concerning multiple names, I think this can be solved by performing > multiple searches with a single name in each search. See comment above why I think this is more complex. > > * you should be able to match on the subject public key as well as > > the subject public > > key algorithm OID. > > > > you can match on the subject key identifier (3rd component) but not the subject public key itself. > > * you should be able to match on the basic constraints extension, > > especially the > > maxPathLen value. This is useful for finding potential > > certificates when building certification paths from the target to > > the most-trusted CA. For ex, if a partial path has been built, any > > candidate certificate must have a maxPathLen value greater than or > > equal to the number of certificates in the partial path. > > > > Interestingly this has been defined for attribute certificates and not > pk certs. I actually think that the way matching for ACs has been > handled is far superior than for PKcerts. ie. a separate matching > rule for each extension, rather than one long complex rule for pk > certs. However, there would be nothing to stop an implementation > dynamically attaching the basicAttConstraintsMatch to public key certs. In > fact this matching rule could be renamed the basicConstraintsMatch > anyway as the syntax is the same for both ACs and PKCs. This is > my preferred approach. Sounds good but I think there might be an issue. What happens if you want to define a matching rule to only retrieve certs that contain a specific basic constraints value AND a certain issuer name? In this case, you would define 2 matching rules and specify both of them in the valuesReturnFilter control. But then you would get all certs with the requested issuer name and any basic constraints value and all certs with any issuer name and the requested basic constraints value. That's not what you wanted. I think we may want to enhance the valuesReturnFilter control (through a flag, perhaps) to allow the user to apply all of the elements of the filter to each attribute value. Let's discuss this more offline, if you like. > > I think it is very important to include the Certificate pair matching > > rules, as these are very useful when building certification paths and > > trying to discover which of many cross certificates satisfy various > > validation constraints, and eliminating those that do not. > > > > OK, this can be done. It is just time consuming and I wanted to > know if there was a demand first. > > > Other comments: > > > > * What RFC format are you using for the encoding of DNs - 1779? This > > should be referenced. > > It should be 2253 for LDAPv3. > > > > > Section 4.2 Certificate List Match > > > > There is an error in the CertificateListAssertion definition in X.509 > > 2000. The authorityKeyIdentifier component should be marked OPTIONAL. > > This probably doesn't affect your definition, but I just wanted to > > make you aware of it. > > Agreed, Sharon, can you make a note of this defect > > David > p.s. what do you think about Bruce's assertion that none of this is > needed and instead we should have a bunch of simple attributes in > the LDAP entry I'll have to go back and read Bruce's draft but I agree with your responses to Bruce in an earlier message. Comments later ... Thanks, Sean From list@netscape.com Fri Jul 14 06:57:57 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11179 for ; Fri, 14 Jul 2000 06:57:56 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6EAm4R25471; Fri, 14 Jul 2000 03:48:04 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6EAuUY04535; Fri, 14 Jul 2000 03:56:30 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 03:56:30 -0700 (PDT) Message-Id: <200007141056.GAA10686@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-refer-00.txt Date: Fri, 14 Jul 2000 06:56:25 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"3VEEyD.A.iGB.dHvb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : Referrals in LDAP Directories Author(s) : R. Hedberg Filename : draft-ietf-ldapext-refer-00.txt Pages : 13 Date : 13-Jul-00 This document defines two reference attributes and associated 'referral' object class for representing generic knowledge information in LDAP directories [RFC2251]. The attribute uses URIs [RFC1738] to represent knowledge, enabling LDAP and non-LDAP services alike to be referenced. The object class can be used to construct entries in an LDAP directory containing references to other directories or services. This document also defines procedures directory servers should follow when supporting these schema elements and when responding to requests for which the directory server does not contain the requested object but may contain some knowledge of the location of the requested object. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-refer-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapext-refer-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapext-refer-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000713145804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-refer-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-refer-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145804.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Fri Jul 14 08:18:25 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07085 for ; Fri, 14 Jul 2000 08:18:24 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6ECC8U07745; Fri, 14 Jul 2000 05:12:08 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6ECGuE21957; Fri, 14 Jul 2000 05:16:56 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 05:16:56 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: ietf-ldapext@netscape.com, "Ramsay, Ron" Date: Fri, 14 Jul 2000 13:15:39 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: Unique identifiers for LDAP attributes Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <396F127B.31809.D26A106@localhost> Priority: normal In-reply-to: <11981F9F5649D411BC92009027D0D18C5B7CF9@aspams01.cai.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"87aBJC.A.sWF.2Swb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date forwarded: Thu, 13 Jul 2000 21:42:39 -0700 (PDT) From: "Ramsay, Ron" To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com Subject: RE: Unique identifiers for LDAP attributes Date sent: Fri, 14 Jul 2000 14:42:36 +1000 Forwarded by: ietf-ldapext@netscape.com > David, > > I agree with the philosophy. However, there may be a middle course. true > Where the attribute has been standardised by appearing in an IETF > standard, or other recognised standard (e.g. ITU-T or EN etc) > the name used in the standard could be considered > standardised. For all other attributes, an OID is required. There may > be other publication methods which can standardise attribute names, eg > informational RFCs. not informational, I think they would need to be standards track, but minor point David > > Ron. > > -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] > Sent: Friday, 14 July 2000 0:03 > To: ietf-ldapext@netscape.com > Subject: Unique identifiers for LDAP attributes > > > Folks > > I was at a Middleware meeting a few weeks ago where some guys > from Internet 2 were talking about outstanding problems with LDAP. One > of the points raised was the lack of a unique name for attribute > types, and that two LDAP servers could have the same name for > different attributes or different names for the same attribute. They > were wanting to create a group that could standardise on the names of > LDAP attribute types. When I pointed out to them that we already have > unique identifiers for each attribute type in the shape of OIDs, that > do not have the multilingual and character set problems that strings > have, they seemed convinced that this could work. > > However, we have the situation that some LDAP servers do not > require OIDs to be defined for attribute types, and the LDAP spec > deprecates the use of OIDs in protocol in preference to strings. > > Given that many LDAP clients now map the attribute type strings > from protocol into a user friendly language dependent display string, > the string representation in protocol has about had its day and served > its purpose. Isnt it about time that we altered the LDAP spec to > recommend that OIDs be the preferred way of transferring attribute > types in protocol, and that the OIDs become the globally unique way of > identifying attribute types. > > (Firewalls up to protect from flames) > > David > > *************************************************** > > David Chadwick > IS Institute, University of Salford, Salford M5 4WT > Tel +44 161 295 5351 Fax +44 161 745 8169 > Mobile +44 790 167 0359 > Email D.W.Chadwick@salford.ac.uk > Home Page http://www.salford.ac.uk/its024/chadwick.htm > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string MLJ9-DU5T-HV8J > > *************************************************** > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Fri Jul 14 08:18:37 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07138 for ; Fri, 14 Jul 2000 08:18:36 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6ECCNU07883; Fri, 14 Jul 2000 05:12:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6ECHBg22194; Fri, 14 Jul 2000 05:17:11 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 05:17:11 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: ietf-ldapext@netscape.com, "Ramsay, Ron" Date: Fri, 14 Jul 2000 13:15:41 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <396F127D.15718.D26A7B4@localhost> Priority: normal In-reply-to: <11981F9F5649D411BC92009027D0D18C5B7DC3@aspams01.cai.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"29Rid.A.8ZF.DTwb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT > However, I seem to sense some opposition to the concept and this is > where we have a real problem. If an entry holds two certificates, > there is no way of setting other attributes in the entry so that each > of their values are associated with the appropriate certificate. I > think the matching rule approach is the only solution. I agree. >You may be able > to have 'magic' attributes that have order-dependent values, but this > is in conflict with the X.500 standard. Actually X.500(97) has a potential solution for this in the concept of attribute value contexts. But no-one to my knowledge has implemented contexts, and you would still have the management overhead of keeping the contexts on the whole package of attributes in sync. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Fri Jul 14 09:23:21 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23379 for ; Fri, 14 Jul 2000 09:23:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6EDDSR04805; Fri, 14 Jul 2000 06:13:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6EDLtU11863; Fri, 14 Jul 2000 06:21:55 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 06:21:55 -0700 (PDT) Message-ID: <010001bfed95$afee4000$02171ec7@steve> From: "Steve Fisher" To: , "ietf ldapext" , "Ramsay, Ron" References: <396F127D.15718.D26A7B4@localhost> Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt Date: Fri, 14 Jul 2000 14:15:40 +0100 Organization: Mine MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Resent-Message-ID: <"G_UHQC.A.C5C.xPxb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "David Chadwick" To: ; "Ramsay, Ron" Sent: 14 July 2000 13:15 Subject: RE: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt > > >You may be able > > to have 'magic' attributes that have order-dependent values, but this > > is in conflict with the X.500 standard. > > Actually X.500(97) has a potential solution for this in the concept of > attribute value contexts. But no-one to my knowledge has > implemented contexts, and you would still have the management > overhead of keeping the contexts on the whole package of > attributes in sync. Does anybody know whether there are any plans for any X.500/LDAP supplier to implement contexts? Steve Fisher Steve Fisher BT Syncordia Solutions T&I 0771 310 7125 0118 975 0560 s.a.fisher@btinternet.com From list@netscape.com Fri Jul 14 11:23:47 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29583 for ; Fri, 14 Jul 2000 11:23:46 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6EFHXU22438; Fri, 14 Jul 2000 08:17:33 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6EFMLE16330; Fri, 14 Jul 2000 08:22:21 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 08:22:21 -0700 (PDT) Sender: rsalz@ywing.netscape.com Message-ID: <396F2FC1.DE77FFDB@caveosystems.com> Date: Fri, 14 Jul 2000 11:20:33 -0400 From: Rich Salz X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com Subject: Re: I-D ACTION:draft-zeilenga-ldap-authpasswd-03.txt References: <200007131027.GAA11142@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Resent-Message-ID: <"6drE1B.A.L-D.qAzb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "It is recommended that the value of (SHA-1 hashes) be protected as if they were plaintext. (Sec 5.2)" Why? From list@netscape.com Fri Jul 14 11:33:45 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03009 for ; Fri, 14 Jul 2000 11:33:44 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6EFNmR15293; Fri, 14 Jul 2000 08:23:49 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6EFWFg19233; Fri, 14 Jul 2000 08:32:15 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 08:32:15 -0700 (PDT) Date: Fri, 14 Jul 2000 10:31:06 -0500 From: Mark Wahl Subject: Re: Unique identifiers for LDAP attributes In-reply-to: "Your message of Fri, 14 Jul 2000 13:15:39 BST." <396F127B.31809.D26A106@localhost> Sender: wahl@austin.innosoft.com To: d.w.chadwick@salford.ac.uk Cc: ietf-ldapext@netscape.com, "Ramsay, Ron" Message-id: <29562.963588666@threadgill.austin.innosoft.com> Resent-Message-ID: <"zhp8RD.A.BsE.9Jzb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Its RFC 2252 section 4.2: > Schema developers MUST NOT create attribute definitions whose names > conflict with attributes defined for use with LDAP in existing > standards-track RFCs. Mark Wahl, Directory Architect, Service Provider/Infrastructure Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Fri Jul 14 12:08:03 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14512 for ; Fri, 14 Jul 2000 12:08:02 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6EFvnR19343; Fri, 14 Jul 2000 08:57:49 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6EG6FE11424; Fri, 14 Jul 2000 09:06:15 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 09:06:15 -0700 (PDT) Message-Id: <4.3.2.7.0.20000714084856.00b3f9f0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 09:05:45 -0700 To: Rich Salz From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-zeilenga-ldap-authpasswd-03.txt Cc: ietf-ldapext@netscape.com In-Reply-To: <396F2FC1.DE77FFDB@caveosystems.com> References: <200007131027.GAA11142@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"rShpNC.A.uxC.1pzb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:20 AM 7/14/00 -0400, Rich Salz wrote: >"It is recommended that the value of (SHA-1 hashes) be protected as if >they were plaintext. (Sec 5.2)" > >Why? Because if a flaw is found in the SHA-1 algorithm, your directory would be vulnerable to attack if you exposed SHA-1 values. The use of SHA-1 (or other algorithms) offers an additional layer of protection such that if one layer fails (access controls upon the values), other layers will offer some protection against immediate access to the directory. Reliance upon a single layer of security is unwise. I will add some text to the next revision discussing this security consideration. Kurt From list@netscape.com Fri Jul 14 12:10:42 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15576 for ; Fri, 14 Jul 2000 12:10:40 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6EG0lR20131; Fri, 14 Jul 2000 09:00:47 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6EG9Do16356; Fri, 14 Jul 2000 09:09:14 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 09:09:14 -0700 (PDT) Message-Id: <4.2.2.20000714110201.00a2c740@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 14 Jul 2000 11:08:40 -0500 To: internet-drafts@ietf.org From: Ellen Stokes Subject: draft-ietf-ldapext-acl-model-06.txt - please publish Cc: ietf-ldapext@netscape.com, ietf-ldapext-acm@openldap.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_56377510==_" Resent-Message-ID: <"ThyI0.A.2-D.nszb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=====================_56377510==_ Content-Type: text/plain; charset="us-ascii"; format=flowed I-D editor, Please publish this draft as an update to draft-ietf-ldapext-acl model-05.txt. This is a document of the ldapext working group. Thanks. LDAPEXTers, This draft has been reworked based on the access control model meetings held in Adelaide and subsequent telephone conferences and email from participants in those meetings. We used the principles of simplicity and usability to guide us as well as X.500 where applicable. There are items in X.500 that were desirable to incorporate, such as prescriptive ACIs, but did not at this time given the state of flux around ldap subentry. We also felt that ldap subentry shouldn't be required to implement ldapv3 access control to get acceptance and timely implementations/vendor products that incorporate the access control model. However, we did incorporate the concept of scope into the ACI definitions. Likewise, as you read the document, you'll see the decisions (and why) we made with respect to controlling access to ACI, alias de-referencing, referrals, and more. Here's a short summary of the changes: - BNF per RFC 2234 - Added back multiple list of attributes; removed collections - updated/expanded set of permissions and their descriptions - Clarification of interactions of precedences and evaluations - added access decision algorithm so nothing intuited from examples - Added strength of authentication option into aci syntax based on ldap bind - Versioning ldapACI: concluded that a different attribute would be used in subsequent RFCs on ldap access control - Incorporated authmeth id format into subject component of ldapaci (removed kerberos format) - ipAddress format expanded to include domain names and wildcards - added ability to control access to ACI; removed policy owner - removed terminology section - defined ldapACISubEntry to allow specification of any access control mechanism anywhere in the tree - addressed how alias de-referencing and referrals work with respect to access control - updated the examples to reflect the BNF - updated the security considerations sections - updated/expanded description of the access control model - Misc cleanup of text Comments welcome, as always... Thanks. Ellen --=====================_56377510==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: attachment; filename="draft-ietf-ldapext-acl-model-06.txt" Content-Transfer-Encoding: quoted-printable Internet-Draft E. Stokes LDAP Extensions WG B. Blakley Intended Category: Standards Track Tivoli Systems Expires: 14 January 2001 D. Rinkevich IBM R. Byrne Sun Microsystems 14 July 2000 Access Control Model for LDAPv3 STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the LDAPEXT working group discussion list: ietf-ldapext@netscape.com COPYRIGHT NOTICE Copyright (C) The Internet Society (2000). All Rights Reserved. ABSTRACT This document describes the access control model for the Lightweight Directory Application Protocol V3 (LDAPv3) directory service. It includes a description of the model, the LDAP controls, and the extended operations to the LDAP protocol. The current LDAP APIs are sufficient for most Stokes, et al Expires 14 January 2001 [Page 1] =0C Internet-Draft Access Control Model 14 July 2000 access control operations. An API (in a separate document) is needed for the extended operation getEffectiveAccess. A separate requirements document for access control exists [REQTS]. The access control model used the requirements documents as a guideline for the development of this specification and are reflected in this specification to the extent that the working group could agree on an access control model. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" used in this document are to be interpreted as described in [Bradner97]. 1. Introduction The ability to securely access (replicate and distribute) directory information throughout the network is necessary for successful deployment. LDAP's acceptance as an access protocol for directory information is driving the need to provide an access control model definition for LDAP directory content among servers within an enterprise and the Internet. Currently LDAP does not define an access control model, but one is needed to ensure consistent secure access, replication, and management across heterogeneous LDAP implementations. The major objective is to provide a simple, usable, and implementable, but secure and efficient access control model for LDAP while also providing the appropriate flexibility to meet the needs of both the Internet and enterprise environments and policies. This document defines the model and the protocol extensions (controls and extended operations). This draft does not (and cannot) fully specify the behavior of the Access Control Model in a distributed environment (e.g. propagating access control information across servers and ACI administration) because there is no LDAP standard defining how to distribute directory data between LDAP servers. The behavior of the Access Control Model in distributed environments is beyond the scope of this draft. 2. The LDAPv3 Access Control Model Access Control mechanisms evaluate requests for access to protected resources and make decisions about whether those requests should be granted or denied. In order to make a Stokes, et al Expires 14 January 2001 [Page 2] =0C Internet-Draft Access Control Model 14 July 2000 grant/deny decision about a request for access to a protected resource, an access control mechanism needs to evaluate policy data. This policy data describes security- relevant characteristics of the requesting subject and the rules which govern the use of the target object. No mechanism is defined in this document for storage of access control information at the server beyond indicating that the attribute holding access control information is an operational attribute. The access control mechanisms specified in this document are neutral with respect to policy inheritance mechanisms, explicit vs. implicit denial, and group nesting. The access control model defines - What flows on the wire for interoperability The existing LDAP protocol flows for ldap operations are used to manipulate access control information. A set of permissions and their semantics with respect to ldap operations is defined. The permissions parallel the types of ldap operations defined. What is transmitted is exactly what is read back. Encoding of access control information on the wire is per the LDAPv3 specifications. There is an additional LDAP control and extended protocol operation defined, getEffectiveRights. LDAP clients use the control and extended operation to manage and administer access control policy enforced by LDAP servers. Servers may store access control information in any way they choose. In particular, servers may use the access control mechanisms of their datastores to store and enforce LDAP access control, or they may implement access control managers external to their datastores. Datastores and external access control managers MAY implement any access control rule syntax and semantics they choose, but the semantics MUST be compatible with those defined in the section titled "Operational Semantics of Access Control Operations". - Attributes and classes for application portability of access control information An access control information attribute (ldapACI) for application portability: This attribute is used as input to the LDAP APIs so access control information Stokes, et al Expires 14 January 2001 [Page 3] =0C Internet-Draft Access Control Model 14 July 2000 can be addressed uniformly independent of how that information is addressed and stored at the server. This same attribute appears in LDIF output for interchange of access control information. An access control information subentry class (ldapACISubEntry) and a set of attributes (supportedAccessControlSchemes which is used in the rootDSE and accessControlSchemes which is used in the subentry ldapACISubEntry) to identity the access control mechanisms supported by a server and in a given part of the namespace, respectively. - An attribute in the rootDSE, discloseOnError, to control whether it is permissible for the server to return the name of an entry or attribute in an error (or empty set) operation result. This closes a hole on the ability to discover information you are not authorized to discover. - A mechanism to control access to access control information: The access control information attribute, ldapACI, is used to control access to access control information (controls access to itself). How to get an initial ldapACI in the directory is server specific and beyond the scope of this model. Servers can support multiple access control mechanisms, but MUST be capable of supporting the LDAP Mechanism in the DIT scoped by the rootDSE (entire server's DIT) for that server and SHOULD be capable of supporting the LDAP mechanism in an arbitrary part (subtree) of the DIT. The accessControlSchemes attribute in the ldapACISubEntry indicates which access control mechanism is in effect for the scope of that ldapACISubEntry. The supportedAccessControlSchemes attribute in the rootDSE indicates which acess control mechanisms are supported by the server; those mechanisms are in effect in that server's DIT unless overridden by a mechanism defined in a ldapACISubEntry elsewhere in that DIT. Changing the value(s) of either the supportedAccessControlSchemes or accessControlSchemes attributes changes the mechanism(s) in effect for the scope of those attributes (where scope is either that of the rootDSE or ldapACISubEntry). Through the use of the mechanism rootDSE attribute and ldapACI subentry, it is possible to run multiple mechanisms in either the same subtree or separate subtrees. If two Stokes, et al Expires 14 January 2001 [Page 4] =0C Internet-Draft Access Control Model 14 July 2000 mechanisms are run in the same subtree, it is desirable that the result be the same independent of mechanism, but definition and discussion of this is beyond the scope of this model. 3. Access Control Mechanism Attributes Two attributes are defined to identify which access control mechanisms are supported by a given server and by a given subtree: supportedAccessControlSchemes and accessControlSchemes. (We chose these names based on the X.500 attribute, AccessControlScheme which is single-valued and defined in X.501). 3.1 Root DSE Attribute for Access Control Mechanism The server advertises which access control mechanisms it supports by inclusion of the 'supportedAccessControlSchemes' attribute in the root DSE. This attribute is a list of OIDs, each of which identify an access control mechanism supported by the server. By default, these are also the mechanisms in effect in subtrees beneath the root in that server unless overridden by a ldapACISubEntry (see section "Subentry Class Access Control Mechanism"). ( NAME 'supportedAccessControlSchemes' DESC list of access control mechanisms supported by this directory server SYNTAX LDAPOID USAGE dSAOperation ) The access control mechanism defined is: LDAPv3 Other vendor access control mechanisms MAY be defined (by OID) and are the responsibility of those vendors to provide the definition and OID. 3.2 Root DSE Attribute for Control of Disclosing Errors The server specifies whether it is permissible for the name of an entry or attribute to be disclosed in an error (or empty) operation result. This rootDSE attribute is discloseOnError. The default for discloseOnError is false (0) or not to disclose on error. The lack of this attribute Stokes, et al Expires 14 January 2001 [Page 5] =0C Internet-Draft Access Control Model 14 July 2000 in the rootDSE is interpreted as the default. ( NAME 'discloseOnError' DESC specify whether to return the name of an entry or attribute in an error (or empty) operation result; 0=3Ddo not disclose (default); 1=3Ddisclose SYNTAX LDAPString USAGE dSAOperation 3.3 Subentry Class Access Control Mechanism A given naming context MUST provide information about which access control mechanisms are in effect for that portion of the namespace. This information is contained in a subentry (ldapACISubEntry class), derived from [SUBENTRY]. ldapACISubEntry MAY be used to define the scope of an access control mechanism. The value(s) held in the rootDSE attribute, supportedAccessControlSchemes, are the mechanisms in effect in subtrees beneath the root in that server unless overridden in a ldapACISubEntry further down the tree held by that server. The scope of that ldapACISubEntry is to the end of the subtree held by that server or until another ldapACISubEntry is encountered in that subtree held by that server. The ldapACISubEntry class is defined as: ( NAME 'ldapACISubEntry' DESC 'LDAP ACI Subentry class' SUP ldapSubEntry STRUCTURAL MUST ( accessControlSchemes ) ) The accessControlSchemes attribute MUST be in each ldap access control subentry entry associated with a naming context whose access control mechanism is different from adjacent naming contexts supported by that directory server. accessControlSchemes lists the values (list of OIDs) that define the access control mechanisms in effect for the scope of that ldap access control subentry. Although, in general, this attribute will define only a single mechanism (single value), more than one mechanism MAY be in effect for the scope of that subentry. ( NAME 'accessControlSchemes' DESC list of access control mechanisms supported in this subtree Stokes, et al Expires 14 January 2001 [Page 6] =0C Internet-Draft Access Control Model 14 July 2000 SYNTAX LDAPOID USAGE dSAOperation ) 4. The Access Control Information Attribute (ldapACI) The access control information attribute, ldapACI, is defined as: ( NAME 'ldapACI' DESC 'ldap access control information' EQUALITY caseIgnoreMatch SYNTAX directoryString USAGE directoryOperation ) The intent of the attribute definition is to design a common interchange format. Any given LDAP server should be able to translate the below defined attribute into meaningful operation requests. Each server should be able to understand the attribute; there should not be any ambiguity into what any part of the syntax means. While the end goal is to have a common behavior model between different LDAP server implementations, the attribute definition alone will not ensure identical ACL processing behavior between servers. The semantics of how a server interprets the ACI syntax are defined in the "Operational Semantics of Access Control" section of this document. Additionally, while the server must recognize and act on the attribute when received over the wire, there are no requirements for the server to physically store this attribute. The attribute definition maintains an assumption that the receiving server supports inheritance within the security model. If the server does not support inheritance, the receiving server must expand any inherited information based on the scope flag. If the server does not support partial inheritance and both the entry and subtree scope are used, then entry is the prevailing scope. (It is possible for two values in the ldapACI attribute to have different scopes given the syntax of ldapACI; one might contain 'entry' and another might contain 'subtree'. This implies that some ldapACI values inherit down the DIT and othersdo not - hence partial inheritance of the ldapACI attribute.) The attribute is defined so access control information (ACI) Stokes, et al Expires 14 January 2001 [Page 7] =0C Internet-Draft Access Control Model 14 July 2000 can be addressed in a server independent of server implementation. This attribute is used in typical LDAP APIs and in LDIF output of ACI. This attribute may be queried or set on all directory objects. The BNF and definitions are given below. 4.1 The BNF 4.1.1 ACI String Representation Values of this syntax are encoded according to the following BNF which follows the BNF encoding conventions described in [ABNF]: ldapACI =3D scope "#" rights "#" attr "#" subject scope =3D "entry" / "subtree" rights =3D (("grant:" / "deny:") permissions) / ("grant:" permissions ";deny:" permissions) permissions =3D [permission *("," permission)] permission =3D "a" / ; add "d" / ; delete "e" / ; export "i" / ; import "n" / ; renameDN "b" / ; browseDN "t" / ; returnDN "r" / ; read "s" / ; search "w" / ; write (mod-add) "o" / ; obliterate (mod-del) "c" / ; compare "m" / ; make attr =3D "[all]" / "[entry]" / (attribute *("," attribute)) attribute =3D ; OID syntax (1.3.6.1.4.1.1466.115.121.1.38) ; from [ATTR] subject =3D ["authnLevel:" authnLevel ":"] (("authzID-" authzID) / ("role:" dn) / ("group:" dn) / ("subtree:" dn) / ("ipAddress:" ipAddress) / "public:" / Stokes, et al Expires 14 January 2001 [Page 8] =0C Internet-Draft Access Control Model 14 July 2000 "this:") authnLevel =3D "any" / "simple" / sasl sasl =3D "sasl:" ("any" / mechanism) mechanism =3D ; sasl mechanism from 4.2 of [LDAPv3] authzID =3D ; authzID from [AuthMeth] repeated below ; for convenience authzId =3D dnAuthzId / uAuthzId ; distinguished-name-based authz id. dnAuthzId =3D "dn:" dn dn =3D utf8string ; with syntax defined in [UTF] ; unspecified userid, UTF-8 encoded. uAuthzId =3D "u:" userid userid =3D utf8string ; syntax unspecified ipAddress =3D printableString ; dotted decimal form (e.g. 10.0.0.6) ; or use wildcards such as 12.3.45.* to ; specify a specific subnetwork ; or 123.45.6.*+255.255.255.115 to ; specify a subnetmask ; or use a wildcard domain name such as ; *.airius.com to specify a specific ; DNS domain printableString ; printableString syntax from [ATTR] Note that the colon following the "public" and "this" subject options exist only to simplify string parsing. Note also that per [AuthMeth], authzID may be expanded in the future. See section titled 'ACI Examples' for examples of the string representation. Stokes, et al Expires 14 January 2001 [Page 9] =0C Internet-Draft Access Control Model 14 July 2000 4.1.2 ACI Binary Representation The following ASN.1 data type is used to represent this syntax when transferred in binary form: ldapACI ::=3D SEQUENCE { scope ENUMERATED { entry (0), subtree (1) }, rights SEQUENCE OF CHOICE { grant [0] Permissions, deny [1] Permissions }, attr CHOICE { all [0] NULL, entry [1] NULL, attributes [2] SEQUENCE OF Attribute }, subject SEQUENCE { authnLevel CHOICE { any [0] NULL, simple [1] NULL, sasl [2] CHOICE { any [0] NULL, mechanism [1] LDAPString -- from [LDAPv3] } }, subject CHOICE { dn [0] DN, user [1] utf8String role [1] DN, group [2] DN, subtree [3] DN, ipAddress [4] IPAddress, public [6] NULL, this [7] NULL }, } -- may be expanded per [AuthMeth] Permissions ::=3D SEQUENCE OF ENUMERATED { add (0), delete (1), export (2), import (3), renameDN (4), browseDN (5), returnDN (6), read (7), search (8), write (9), obliterate (10), compare (11), make (12) } Stokes, et al Expires 14 January 2001 [Page 10] =0C Internet-Draft Access Control Model 14 July 2000 Attribute ::=3D AttributeType -- from [LDAPv3] IPAddress ::=3D PrintableString -- (e.g. 10.0.0.6) 4.2 The Components of ldapACI Attribute This section defines components that comprise the access control information attribute, ldapACI. 4.2.1 Scope Two scopes for access control information are defined: - entry - the access control information in the ldapACI attribute applies only to the entry in which it is contained - subtree - the access control information in the ldapACI attribute applies to each entry down the subtree unless it is overridden by an entry-specific ldapACI whose values are more specific. Use of prescriptive ACIs and scoping via use of a ldapACISubEntry is outside the scope of this document. 4.2.2 Access Rights and Permissions Access rights can apply to an entire object or to attributes of the object. Access can be granted or denied. Either or both of the actions "grant" | "deny" may be used when creating or updating ldapACI. Each of the LDAP access permissions are discrete. One permission does not imply another permission. The permissions which apply to attributes and the entry parallel the type of ldap operations that can be performed. Permissions which apply to attributes: r Read Read attribute values w Write Modify-add values o Obliterate Modify-delete values s Search Search entries with specified attributes c Compare Compare attributes m Make Make attributes on a new entry below this entry Stokes, et al Expires 14 January 2001 [Page 11] =0C Internet-Draft Access Control Model 14 July 2000 1. r Read If granted, permits attributes and values to be returned in a read or search operation. 2. w Write If granted, permits attributes and values to be added in a modify operation. 3. o Obliterate If granted, permits attributes and values to be deleted in a modify operation. 4. s Search If granted, permits attributes and values to be included in a search operation. 5. c Compare If granted, permites attributes and value to be used in a compare operation. 6. m Make The attribute permission "m" is required for all attributes that are placed on an object when it is created. Just as the "w" and "o" permissions are used in the Modify operation, the "m" permission is used in the Add operation. Additionally, note that "w" and "o" have no bearing on the Add operation and "m" has no bearing on the Modify operation. Since a new object does not yet exist, the "a" and "m" permissions needed to create it must be granted on the new object's parent. This differs from "w" and "o" which must be granted on the object being modified. The "m" permission is distinct and separate from the "w" and "o" permissions so that there is no conflict between the permissions needed to add new children to an entry and the permissions needed to modify existing children of the same entry. Note: Modify-replace values of an attribute requires "w" and "o" permission. Permissions that apply to an entire entry: a Add Add an entry below this entry Stokes, et al Expires 14 January 2001 [Page 12] =0C Internet-Draft Access Control Model 14 July 2000 d Delete Delete this entry e Export Export entry & subordinates to new location i Import Import entry & subordinates from some location n RenameDN Rename an entry's DN b BrowseDN Browse an entry's DN t ReturnDN Allows DN of entry to be disclosed in an operation result 1. a Add If granted, permits creation of an entry in the DIT subject to control on all attributes and values to be placed in the new entry at time of creation. In order to add an entry, permission must also be granted to add at least the mandatory attributes. 2. d Delete If granted, permits the entry to be removed from the DIT regardless of controls on attributes within the entry. 3. e Export If granted, permits an entry and its subordinates (if any) to be exported; that is, removed from the current location and placed in a new location subject to the granting of suitable permission at the destination. If the last RDN is changed, Rename is also required at the current location. In order to export an entry or its subordinates, there are no prerequisite permissions to contained attributed, including the RDN attributes; this is true even when the operation causes new attribute values to be added or removed as the result of the changes of RDN. 4. i Import If granted, permits an entry and its suordinates (if any) to be imported; that is, removed from some other location and placed a t the location to which the permission applies subject to the granting of suitable permissions at the source location. In order to import an entry or its subordinates, there are no prerequisite permissions to contained attributed, including the RDN attributes; this is true even when the operation causes new attribute values to be added or removed as the result of the changes of RDN. Stokes, et al Expires 14 January 2001 [Page 13] =0C Internet-Draft Access Control Model 14 July 2000 5. n RenameDN Granting Rename is necessary for an entry to be renamed with a new RDN, taking into account consequential changes to the distinguished names of subordinate entries, if any; if the name of the superior is unchanged, the grant is sufficient. In order to rename an entry, there are no prerequisite permissions to contained attributed, including the RDN attributes; this is true even when the operation causes new attribute values to be added or removed as the result of the changes of RDN. 6. b BrowseDN If granted, permits entries to be accessed using directory operations which do not explicitly provide the name of the entry. 7. t ReturnDN If granted, allows the distinguished name of the entry to be disclosed in the operation result. All permissions (for grant and deny) for an attribute/entry and a given subject MUST be contained within one ldapACI value, i.e. (in abbreviated form) ldapACI: ...grant OID.attr1 subjectA ldapACI: ...deny OID.attr1 subjectA must be ldapACI: ...grant ... deny... OID.attr1 subjectA Using the defined BNF it is possible for the permission string to be empty. The ACI ldapACI: subtree#grant#OID.attr1#group:cn=3DDept XYZ,c=3DUS ldapACI: subtree#grant:r,s#[all]#group:cn=3DDept XYZ,c=3DUS means that this group (Dept XYZ) is granted permission to read and search all attributes except OID.attr1 because OID.attr1 is more specific than "[all]". 4.2.3 Attributes Attribute describes an attribute name in the form of a dotted decimal OID for that . If the string (OID) refers to an attribute not defined in the given server's schema, the server SHOULD report an error. "[entry]" means Stokes, et al Expires 14 January 2001 [Page 14] =0C Internet-Draft Access Control Model 14 July 2000 the permissions apply to the entire object. This could mean actions such as delete the object, or add a child object. "[all]" means the permission set apply to all attributes of the entry. If the keyword "[all]" and another attribute are both specified within an ACI, the more specific permission set for the attribute overrides the less specific permission set for "[all]". 4.2.4 Subjects and Associated Authentication The following subjects are defined and MUST be supported: - authzID, defined per [authmeth] - group, defined as the distinguished name of a groupOfNames or groupOfUniqueNames entry - role - subtree, defined as the distinguished name of a non- leaf node in the DIT - ipAddress, - public, defined as public access - this, defined as the user whose name matches that of the entry being accessed Other parties MAY define other subjects. It is the responsibility of those parties to provide the definition. A subject may be qualified by the type of authentication required for access to a given attribute(s) or entry. If no authnLevel is present, then no specific type of authentication is additionally required for access. If authnLevel is specified, then that type of authentication is additionally required for access. The authnLevels parallel the authentication mechanisms specified for LDAPv3: simple, SASL (any type of SASL mechanism), and a SASL-specific mechanism. The authnLevel of is not an acceptable mechanism for this case) as part of obtaining access. 4.3 Grant/Deny Evaluation Rules The decision whether to grant or deny a client access to a particular piece of information is based on several pieces Stokes, et al Expires 14 January 2001 [Page 15] =0C Internet-Draft Access Control Model 14 July 2000 of information found within the ldapaci value. Throughout the decision making process, there are guiding principals. - Specificity: More specific policies MUST override less specific ones (e.g. individual user entry in ACI takes precedence over group entry). - Deny takes precedence over Grant. - When there are conflicting ACI values, deny takes precedence over grant. - Deny is the default when there is no access control information. Precendence of Scope Types (highest to lowest) - entry - subtree Precedence of Subjects within a Scope (highest to lowest): - ipAddress - authzID, this - group, role, this, public - subtree, public Although other types MAY be defined given the BNF, use of the well-known types aids in interoperability and operational consistency. Access Decision algorithm: 1. Determine all the ldapACI values which could apply to the target DN which is being accessed. This is the DN of the entry which is being queried in a search, modified, deleted, etc. When determining all the ldapACI values, the scope field should be used. All ldapACI values with a scope of 'entry' take precedence over ldapACI values with a scope of 'subtree'. 2. Determine which ldapACI (of the set determined in step 1) apply to the bound DN. This is determined by looking at the subject (combination of subject type and subject value) and bind type. If no bind is in effect (this is possible in ldapv3), then treat this lack of bind as if bound as anonymous. Start with the Stokes, et al Expires 14 January 2001 [Page 16] =0C Internet-Draft Access Control Model 14 July 2000 most specific subject type. If at any time, at least one ldapACI value exists for a specificity level, then processing stops; the exception here is 'this' because this may also be combined with group to use power of 'this'. Evaluation should take place on set of ldapACI values which are all of the same specificity level. Subjects of the same precedence are combined using union semantics. 3. Evaluate the remaining ldapACI values and determine a grant/deny decision. If conflicting ldapACI value exists for the same attribute, or attributes (i.e. one ldapACI grants permission and another denies permission), then deny takes precedence over grant. For example, if one is granted permission to "objectclass" in one ldapACI value by being a member of group cn=3DAdmin, and denied permission by being a member of cn =3D NontrustedAdmins, then the bound user would not receive permission to objectclass. The rule of specificity also applies to the attributes. If one is denied permission to "[ all ]" attributes, but granted permission to "objectclass" then the more specific value of "objectclass" takes precedence over the less specific value of "[ all ] ". In this case the user would be granted permission to "objectclass" but denied permission to all other attributes. 5. Required Permissions for each LDAP Operation This section defines the required permissions for each LDAP operation but even if these requirements are satisfied the server MAY refuse to carry out the operation due to other implementation specific security considerations. For example, a server may refuse to modify an entry because the database where that entry resides is in read only mode. Another example might be that although the access control is available to the userPassword attribute a server may refuse modifications due to some server specific policy governing access to passwords. Here, we specify the rights required by a user when performing an LDAP operation in terms of the LDAP permissions specified in section 6.1. Recall that "a, d, e, i, n, b,t" are permissions that apply to entries as a whole while permissions "r, s, w, o, c, m" apply to attributes within entries. Stokes, et al Expires 14 January 2001 [Page 17] =0C Internet-Draft Access Control Model 14 July 2000 Required permissions for LDAP extended operations and LDAP controls are beyond the scope of this draft. There is a requirement that a user should not be able to infer the existence of data in the Directory, if the user does not have the required access rights to that data. An example of this requirement would be in a hosting environment where you would not want any users from the coke subtree to be able to even discover that the pepsi tree was hosted on the same server. This "discloseOnError" feature will be set once for server in the rootDSE advertised by the attribute discloseOnError. The default for discloseOnError is false (0). The lack of this attribute in the rootDSE is interpreted as the default. The details of its effects are addressed below, operation by operation. For the following, assume that the authorization identity of the user doing the operation is authzID. 5.1 Bind Operation This draft does not require any permissions to allow a bind operation to proceed. 5.2 Search Operation Recall that the parameters of the Search operation per RFC 2251 [LDAPv3] Section 4.5 are: SearchRequest ::=3D [APPLICATION 3] SEQUENCE { baseObject LDAPDN, scope ENUMERATED { baseObject (0), singleLevel (1), wholeSubtree (2) }, derefAliases ENUMERATED { neverDerefAliases (0), derefInSearching (1), derefFindingBaseObj (2), derefAlways (3) }, sizeLimit INTEGER (0 .. maxInt), timeLimit INTEGER (0 .. maxInt), typesOnly BOOLEAN, filter Filter, attributes AttributeDescriptionList } Suppose a server is processing a search request from user authzID with parameters as above and is processing the entry with dn candidateDN to decide if it may be returned or not. Stokes, et al Expires 14 January 2001 [Page 18] =0C Internet-Draft Access Control Model 14 July 2000 Then the permissions required by authzID that need to be evaluated are as follows: 1. permission "b" to the entry candidateDN If this permission is not granted then the dn candidateDN MUST not be returned nor any attribute type nor attribute value from this entry. If this permission is granted then the dn candidateDN MAY be returned. Note: The idea of the "b" permission is to say "a user has discovery rights" at a certain entry in the directory. Assuming that the further required permissions below are satisfied then having "b" right is enough to allow the server to return candidateDN. Of course candidateDN contains in it's components, attributes and attribute values for all the ancestors of candidateDN. This can lead to the slightly odd situation that we can discover the naming attribute of an entry and that attribute's value by virtue of having the required searching permissions to it's child but not by searching the entry directly. 2. permission "s" to each attribute appearing in a presence test during the evaluation of the search filter. permission "r" to each attribute appearing in non-presence tests (see rfc1960, section 3: equalityMatch, substrings, greaterOrEquial, lessOrEqual, present, approxMatch, extensibleMatch) during the evaluation of the search filter. The above statement covers the case where the attributes are being evaluated as part of an extensibleMatch (RFC 2251 section 4.5.1) which appears in the filter. In the case where the dnAttributes field of the extensibleMatch is true then we do not require any access checks to the attributes of the dn candidateDN as access to these is taken to be granted by the "b" permission, which has already been required above. If there is an attribute in a filter element to which the required permission is not granted then that filter element evaluates to "Undefined" of the three- valued-logic of X.511(93). Note A: Although both "r" and "s" permissions will typically be granted to attributes we keep both Stokes, et al Expires 14 January 2001 [Page 19] =0C Internet-Draft Access Control Model 14 July 2000 permissions as there are cases where the distinction is useful. For example, the ability to grant the right to discover that a user entry contains a userPassword attribute, but not to read it's value ("s" but not "r"). The converse, granting "r" but not "s" permission is less easy to motivate. Note B: There is an unusual behaviour with respect to naming attributes illustrated in the following example: Suppose I have "b" rights to cn=3Dfred,o=3Dsun.com and "r" rights to attribute objectclass but not "r" rights to cn then with search filter (objectclass=3D*) I get back the dn and objectclass (and so can see the value of cn), but with a search filter of (cn=3Dfred) I do not get anything. 3. permission "r" to each attribute in the attribute list AttributeDescriptionList (or all attributes in the entry candidateDN if AttributeDescriptionList is *) whose type and/or value will be returned. Note: The presence of an attribute in an entry is only ever volunteered by the server if "r" permission is granted to it, though a user may infer the presence of an attribute with "s" permission by using a presence test on that attribute in the search filter. 4. permission "t" to the entry candidateDN If this permission is not granted then the dn candidateDN MUST NOT be returned. If the server knows of an alias for the entry, this alias may be returned instead. If no alias name is available then the entry candidateDN MUST be omitted from the search results. 5. Disclose on error for the Search operation If every entry in the scope of the search fails to satisfy item 1 (browse right on the candidate entry) or item 2 (right to use the filter on that entry) and if discloseOnError is not granted to the baseObject entry then the operation MUST fail with a "no such object error" and the matchedDN of the LDAPResult MUST be set to "". If every entry in the scope of the search fails to satisfy items 1 or 2 above and discloseOnError is granted to the baseObject then the empty set of results is returned. Stokes, et al Expires 14 January 2001 [Page 20] =0C Internet-Draft Access Control Model 14 July 2000 5.3 Modify Operation Recall that the parameters of the Modify operation per RFC2251 [LDAPv3] Section 4.6 are: ModifyRequest ::=3D [APPLICATION 6] SEQUENCE { object LDAPDN, modification SEQUENCE OF SEQUENCE { operation ENUMERATED { add (0), delete (1), replace (2) }, modification AttributeTypeAndValues } } AttributeTypeAndValues ::=3D SEQUENCE { type AttributeDescription, vals SET OF AttributeValue } Then the permissions required by authzID that need to be evaluated are as follows: 1. permission "w" to each attribute being added to object If this permission is not granted to such an attribute, then the operation MUST fail. In this case, if discloseOnError is not granted to the entry then "no such object" error is returned; if discloseOnError is granted to the entry and a duplicate attribute value is being added then "attribute value already exists" error is returned; if discloseOnError is granted to the entry and no duplicate value is being added then an "insufficient access" error is returned. 2. permission "o" to each attribute for which a value is being deleted from object If this permission is not granted to such an attribute then the operation MUST fail. In this case, if discloseOnError is not granted to the entry then "no such object" error is returned; if discloseOnError is granted to the entry and the attribute or one of the values to be deleted does not exist then a "no such attribute or value" error is returned; if discloseOnError is granted to the entry and the attribute and all values specified to be deleted exist then an "insufficient access" error is returned. Stokes, et al Expires 14 January 2001 [Page 21] =0C Internet-Draft Access Control Model 14 July 2000 3. permissions "o" and "w" to each attribute being replaced in object If one of these these permissions is not granted to such an attribute then the operation MUST fail. In this case, if discloseOnError is not granted to the entry then a "no such object" error is returned; if discloseOnError is granted to the entry then "insufficient access" error is returned. 5.4 Add Operation Recall that the parameters of the Add operation per RFC2251 [LDAPv3] Section 4.7 are: AddRequest ::=3D [APPLICATION 8] SEQUENCE { entry LDAPDN, attributes AttributeList } AttributeList ::=3D SEQUENCE OF SEQUENCE { type AttributeDescription, vals SET OF AttributeValue } Then the permissions required by authzID that need to be evaluated are as follows: permission "a" to the parent of entry The access rights required for the creation of a root entry in the Directory are beyond the scope of this document. They will be vendor specific. 1. permission "m" to the parent of entry for each attribute being added to entry If any of these permissions are not granted then the operation MUST fail. In this case if discloseOnError is on and the entry to be added does not already exist then "insufficient access" is returned. If it does exist then "Entry already exists" is returned. If discloseOnError is off then "No such object" is returned (meaning the parent object). If they are all granted then the operation MAY proceed. Note: We require "m" permission to each attribute to prevent an entry from aquiring "unintended" rights (via group or role membership), to stop a "rogue" ACI being added that would prevent even admins deleting the entry and general Stokes, et al Expires 14 January 2001 [Page 22] =0C Internet-Draft Access Control Model 14 July 2000 consistency with the MODIFY operation. Note: The access rights required for the creation of the first entry in the directory are beyond the scope of this document. 5.5 Delete Operation Recall that the parameters of the Delete operation per RFC2251 [LDAPv3] Section 4.10 are: DelRequest ::=3D [APPLICATION 10] LDAPDN Then the permissions required by authzID that need to be evaluated are as follows: 1. permission "d" to the entry in the Delete request If this permission is not granted, then the operation MUST fail. In this case if discloseOnError is on and the entry to be deleted exists then "insufficient access" is returned. If it does not exist then "No such Object" is returned. If discloseOnError is off then "No such object" is returned (meaning the parent object). If this permission is granted, then the operation MAY proceed. Note: One could also require the "o" permission to be granted to allow the operation to proceed, but customer experience has shown that the requirement of the additional permission is not useful nor expected, and X.500 requires only the "d" permission. 5.6 Modify DN Operation Recall that the parameters of the Modify DN operation per RFC2251 [LDAPv3] Section 4.6 are: ModifyDNRequest ::=3D [APPLICATION 12] SEQUENCE { entry LDAPDN, newrdn RelativeLDAPDN, deleteoldrdn BOOLEAN, newSuperior [0] LDAPDN OPTIONAL } Then the permissions required by authzID that need to be evaluated are as follows: Stokes, et al Expires 14 January 2001 [Page 23] =0C Internet-Draft Access Control Model 14 July 2000 1. If newSuperior is not present (ie. only the RDN is being renamed) then permission "n" to entry is required. 2. If newSuperior is present then permission "e" to entry and permission "i" to newSuperior are required. If any of these permissions are not granted then the operation MUST fail. In this case, if discloseOnError is on then an "insufficient access error" is returned. Otherwise, "No such object" is returned. If they are all granted then the operation MAY proceed. Note A: We do not require any additional permissions in the case where deleteoldrdn is TRUE. Note B: These permissions allow the naming attribute of an entry (or entries) to be changed even though "o" and "w" permissions are not available on the entry. Distinguishing the permissions like this allows us to grant permissions for the ModifyDN operation, but not the Modify operation and vice versa. 5.7 Compare Operation Recall that the parameters of the Compare operation per RFC2251 [LDAPv3] Section 4.10 are: CompareRequest ::=3D [APPLICATION 14] SEQUENCE { entry LDAPDN, ava AttributeValueAssertion } Then the permissions required by authzID that need to be evaluated are as follows: 1. permission "c" to the attribute in entry on which the comparison is being made. If any of these permissions are not granted then the operation MUST fail. In this case, if discloseOnError is on then an "insufficient access error" is returned. Otherwise, "No such object" is returned. If they are all granted then the operation MAY proceed. Stokes, et al Expires 14 January 2001 [Page 24] =0C Internet-Draft Access Control Model 14 July 2000 5.8 Abandon Operation Recall that the parameters of the Abandon operation per RFC2251 [LDAPv3] Section 4.6 are: AbandonRequest ::=3D [APPLICATION 16] MessageID authzID always has the right to send an Abandon Operation for an operation he previously initiated. 5.9 Extended Operation Recall that the parameters of the Extended operation per RFC2251 [LDA{v3] Section 4.12 are: ExtendedRequest ::=3D [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL } The access required for an Extended Operation is beyond the scope of this document. The required access will normally be defined by the implementor of the extended request. 6. Required Permissions for Handling Aliases and References Use of aliases and referrals are part of LDAPv3. However, neither is particularly well-defined. Alias objects/attributes are defined in RFC 2256 as derived from X.500, but LDAPv3 does not explicitly define its semantics or behavior. X.500 does define alias semantics and behavior with respect to access control; we define its behavior in LDAPv3 based on the X.511, section 7.11.1. Referrals and knowledge information are still under design in LDAPv3; they are defined in X.500, however, X.500 punts on their semantics and behavior with respect to access control. We define their semantics and behavior in LDAPv3 in terms that should be independent of the future LDAPv3 definition of referrals and knowledge information. 6.1 ACI Distribution Currently there is no LDAP standard defining how to distribute directory data between LDAP servers. Consequently this draft cannot fully specify the behavior of the Access Control Model in a distributed environment. The case of distribution via referrals is treated in the "Referrals" Stokes, et al Expires 14 January 2001 [Page 25] =0C Internet-Draft Access Control Model 14 July 2000 section below. In the case of chaining (where one LDAP server forwards a request to another on behalf of a client) then it is server specific how the access control model behaves in this environment. Similarly it is server specific how the server determines whether the chaining of an operation is permitted in the first place. For example, the implementation may choose to regard the local naming context and the remote subordinate naming context as seperate Access Control Specific Areas, or it may regard the DIT as one Access Control Specific Area and implement mechanisms to propagate access control information between the two servers. The behavior of the Access Control Model in distributed environments such as these is beyond the scope of this draft. 6.2 Aliases There are two things to protect with respect to aliases: the real name of the aliased object and the location of the server holding it. If alias de-referencing is required in the process of locating a target entry, no specifc permissions are necessary for alias de-referencing to take place. Access control is enforced at the object pointed to by the alias. If alias de-referencing would result in a continuationReference (e.g. from a search operation), then browse permission is required to the alias entry and read permission is required to the 'aliasedObjectName' attribute. Requiring these permission closes the hole of discovery. 6.3 Referrals If a referral is to be followed, no specifc permissions are necessary for the ldap client to follow the referral. Access control is enforced at the referenced object. If a referral is returned, then browse is required on the entry and read permission is required to the attribute containing the referral (we cannot name this attribute exactly today because there are no RFCs on this - only drafts). If the server implements a default referral, then no special permissions are required to read and return that referral. Requiring these permissions closes the hole of discovery. In the default case, it is assumed that a default referral is public. Stokes, et al Expires 14 January 2001 [Page 26] =0C Internet-Draft Access Control Model 14 July 2000 7. Controlling Access to Access Control Information The ldapACI attribute is used to specify control for who has permission to set/change access control information (ldapACI). The ldapACI attribute/OID is just another attribute described with a scope, set of rights and permissions, and subject as a value of the ldapACI attribute. (See the example in the "ACI Examples" section). If the policy for controlling the ldapACI attribute is not specified for any object in the tree, behavior is implementation defined. For instance, if no object anywhere in the tree defines the access for ldapACI within the ldapACI attribute, then the server could simply assert that the 'root DN' is considered the policy owner (controller for controlling access control) for all objects. 8. ACI Examples Note that in the examples, the form "OID." refers to the OID in dotted decimal form for the attribute . This shorthand notation is used only for the examples. In implementation, the dotted decimal form of the OID is used. 8.1 Attribute Definition The following examples show the access required to control access to the ldapACI attribute. The first example shows controlling the access control on an individual entry and its attributes. The second example shows controlling the access control on a subtree. ldapACI: entry#grant:r,w# OID.ldapACI#authnLevel:any:role:cn=3DaciAdmin ldapACI: subtree#grant:r,w# OID.ldapACI#authnLevel:any:role:cn=3DaciAdmin The next example shows a ldapACI attribute where a group "cn=3DDept XYZ, c=3DUS" is being given permissions to read, search, and compare attribute attr1. The permission applies to the entire subtree below the node containing this ACI. Authentication of a specified type is not required. ldapACI:subtree#grant;r,s,c# OID.attr1#group:cn=3DDept XYZ,c=3DUS Stokes, et al Expires 14 January 2001 [Page 27] =0C Internet-Draft Access Control Model 14 July 2000 The next example shows an ACI attribute where a role "cn=3DSysAdmins,o=3DCompany" is being given permissions to add objects below this node and read, search, and compare attributes attr2 and attr3. The permission applies to the entire subtree below the node containing this ACI. ldapACI: subtree#grant:a# [entry]#role:cn=3DSysAdmins,o=3DCompany ldapACI: subtree#grant:r,s,c# OID.attr2#role:cn=3DSysAdmins,o=3DCompany ldapACI: subtree#grant:r,s,c# OID.attr3#role:cn=3DSysAdmins,o=3DCompany 8.2 Modifying the ldapACI Values Modify-Replace works as defined in the ldap operation modify. If the attribute value does not exist, create the value. If the attribute does exist, replace the value. If the ldapACI value is replaced, all ldapACI values are replaced. A given ldapACI for an entry: ldapACI: subtree#deny:r,w#[all]#group:cn=3DDept ABC ldapACI: subtree#grant:r#OID.attr1#group:cn=3DDept XYZ perform the following change: dn: cn=3DsomeEntry changetype: modify replace: ldapACI ldapACI: subtree#grant:r,w#[all]#group:cn=3DDept LMN The resulting ACI is: ldapACI: subtree#grant:r,w#[all]#group:cn=3DDept LMN ( ldapACI values for Dept XYZ and ABC are lost through the replace ) During an ldapmodify-add, if the ACI does not exist, the create the ACI with the specific ldapACI value(s). If the ACI does exist, then add the specified values to the given ldapACI. For example a given ACI: ldapACI: subtree#grant:r,w#[all]#group:cn=3DDept XYZ Stokes, et al Expires 14 January 2001 [Page 28] =0C Internet-Draft Access Control Model 14 July 2000 with a modification: dn: cn=3DsomeEntry changetype: modify add: ldapACI ldapACI: subtree#grant:r#OID.attr1#group:cn=3DDept XYZ would yield an multi-valued ACI of: ldapACI: subtree#grant:r,w#[all]#group:cn=3DDept XYZ ldapACI: subtree#grant:r#OID.attr1#group:cn=3DDept XYZ To delete a particular ACI value, use the regular ldapmodify - delete syntax Given an ACI of: ldapACI: subtree#grant:r,w#[all]#group:cn=3DDept XYZ ldapACI: subtree#grant:r#OID.attr1#group:cn=3DDept XYZ dn: cn =3D some Entry changetype: modify delete: ldapACI ldapACI: subtree#grant:r#OID.attr1#group:cn=3DDept XYZ would yield a remaining ACI on the server of ldapACI: subtree#grant:r,w#[all]#group:cn=3DDept XYZ The attributes which are defined for access control interchange may be used in all LDAP operations. Within the ldapmodify-delete operation, the entire acl may be deleted by specifying dn: cn =3D some Entry changetype: modify delete: ldapACI In this case, the entry would then inherit its ACI from some other node in the tree depending on the server inheritance model. Similarly, if all values of ldapACI are deleted, then the access control information for that entry is defined by that implementation's inheritance model. Stokes, et al Expires 14 January 2001 [Page 29] =0C Internet-Draft Access Control Model 14 July 2000 8.3 Evaluation These examples assume that the ldapACI entries listed in each example are the only ACI which applies to the entry in question; if backing-store ACI also exists, the effective policy may be different from that listed in each example. See section 10 for a discussion of the semantics of ldapACI entries when backing-store ACI administration is also used. Assume cn=3Djsmith is a member of group cn=3DG1. Assume cn=3Djsmith is a member of group cn=3DG2. Example #1 dn: o=3DXYZ, c=3DUS ldapACI: subtree#grant:r#attr1 #authzID-dn:cn=3Djsmith,ou=3DABC,o=3DXYZ,c=3DUS ldapACI: subtree#grant:w#attr1 #group:cn=3DG1,ou=3DABC,o=3DXYZ,c=3DUS What rights does cn=3Djsmith have to attr1 of o=3DXYZ,c=3DUS? Read (r) access; authzID is higher precedence than group. Example #2 dn: o=3DXYZ, c=3DUS ldapACI: subtree#grant:r#attr2 #group:cn=3DG1,ou=3DABC,o=3DXYZ,c=3DUS ldapACI: subtree#grant:w#attr2 #group:cn=3DG2,ou=3DABC,o=3DXYZ,c=3DUS What rights does cn=3Djsmith have to attr2 of o=3DXYZ,c=3DUS? Read-write (r,w) access; ACI is combined because both subjects (group) have same precedence. Example #3 dn: o=3DXYZ, c=3DUS ldapACI: subtree#grant:r,w#attr3 #group:cn=3DG1,ou=3DABC,o=3DXYZ,c=3DUS ldapACI: subtree#deny:w#attr3#group:cn=3DG2,ou=3DABC,o=3DXYZ,c=3DUS What rights does cn=3Djsmith have to attr3 of o=3DXYZ, c=3DUS? Read access; write is denied (deny has precedence over grant). Example #4 dn: o=3DXYZ, c=3DUS ldapACI: subtree#grant:w#attr4 #authzID-dn:cn=3Djsmith,ou=3DABC,o=3DXYZ,c=3DUS Stokes, et al Expires 14 January 2001 [Page 30] =0C Internet-Draft Access Control Model 14 July 2000 ldapACI: subtree#grant:r#attr4#subtree:ou=3DABC,ou=3DXYZ,c=3DUS What rights does cn=3Djsmith have to attr4 of o=3DXYZ, c=3DUS? Write (w); rights given to an authzID take precedence over those given to a subtree. Example #5 dn: o=3DXYZ, c=3DUS ldapACI: subtree#grant:m#OID.attr5 #authzID-dn:cn=3Djsmith,o=3DABC,c=3DUS ldapACI: subtree#grant:m#OID.cn #authzID-dn:cn=3Djsmith,o=3DABC,c=3DUS ldapACI: subtree#grant:m#OID.sn #authzID-dn:cn=3Djsmith,o=3DABC,c=3DUS ldapACI: subtree#grant:a#[entry] #authzID-dn:#cn=3Djsmith,o=3DABC,c=3DUS What rights does cn=3Djsmith have to o=3DXYZ, c=3DUS? Make(m) on attributes attr5, cn, and sn and Add(a) on the entry. These are the minimal yet sufficient permissions to create a new object, cn=3DNew, o=3DXYZ, c=3DUS with values for the attr5, cn, and sn attributes. This example illustrates how the "m" permission can be used to limit the attributes that can be created on a new entry. Example #6 dn: c=3DUS ldapACI: subtree#grant:m#[all]#subtree:c=3DUS dn: o=3DXYZ, c=3DUS ldapACI: subtree#grant:a#[entry]# authzID-dn:cn=3Djsmith,o=3DABC,c=3DUS What rights does cn=3Djsmith have to o=3DXYZ, c=3DUS? Make(m) on attributes all attributes and Add(a) on the entry. These are sufficient permissions to create a new object, cn=3DNew, o=3DXYZ, c=3DUS with values any desired attributes. For administrators who do not wish to limit the attributes that can be created on new entries, this example shows how a single ldapACI at the top of the domain solves the problem. 9. Operational Semantics of Access Control Operations The semantics of access control operations described in this document are defined operationally in terms of "histories". A history is a sequence of actions (x1, x2, ..., xN). Stokes, et al Expires 14 January 2001 [Page 31] =0C Internet-Draft Access Control Model 14 July 2000 9.1 Types of actions We consider five types of actions: - LDAP Access Control Policy Update actions: invocations of ldap modify when used to add, delete, or replace the aci attribute; invocations of ldap add when used to add an entry with an aci attribute. A LDAP Access Control Policy Update action may replace the policy (by completely replacing the aci attribute with new policy information) or it may grant or deny specific rights while leaving others unaffected. - LDAP Access Control Policy Query operations: invocations of ldap search when used to retrieve the aci attribute; invocations of ldap search with the getEffectiveRightsRequest control; invocations of the ldapGetEffectiveRightsRequest extended operation. - Datastore Access Control Policy Update Actions: any operation implemented by the server which LDAP is using as its datastore which changes the access policy enforced with respect to attempts to access LDAP directory entries and their attributes. - LDAP Access Request operations: invocations of LDAP entry or attribute access operations (Read, Update, Search, Compare, etc...). - Other operations: anything else, including Datastore operations which do not change the access policy enforced by the server. 9.2 Semantics of Histories The semantics of histories are defined as follows: - LDAP Update (Replace), LDAP Query The Query will show that the subject has all rights granted by the Update operation, and no rights not granted by the Update operation. - LDAP Update (Grant), LDAP Query The Query will show that the subject has all rights granted by the Update operation. The Query may show that the subject also has other rights not granted by the Update operation, depending on the policy in force before the Update operation. Stokes, et al Expires 14 January 2001 [Page 32] =0C Internet-Draft Access Control Model 14 July 2000 - LDAP Update (Deny), LDAP Query The Query will show that the subject does not have any right denied by the Update operation. The Query may show that the subject has rights not denied by the Update operation, depending on the policy in force before the Update operation. - LDAP Update (Replace), LDAP Access Request The Request will succeed if it requires only rights granted to the requesting subject by the Update operation. The Request will fail if it requires any right not granted by the Update operation. - LDAP Update (Grant), LDAP Access Request The Request will succeed if it requires only rights granted to the requesting subject by the Update operation. The Request may succeed if it requires rights not granted by the Update operation, depending on the policy in force before the Update operation. - LDAP Update (Deny), LDAP Access Request The Request will fail if it requires any right denied to the requesting subject by the Update operation. If the Request requires only rights which were not denied by the Update operation, it may succeed, depending on the policy in force before the Update operation. - LDAP Update (Replace), Other, LDAP Query The Query will show that the subject has all rights granted by the Update operation, and no rights not granted by the Update operation. - LDAP Update (Grant), Other, LDAP Query The Query will show that the subject has all rights granted by the Update operation. The Query may show that the subject also has other rights not granted by the Update operation, depending on the policy in force before the Update operation. - LDAP Update (Deny), Other, LDAP Query The Query will show that the subject does not have any right denied by the Update operation. The Query may show that the subject has rights not denied by the Update operation, depending on the policy in force Stokes, et al Expires 14 January 2001 [Page 33] =0C Internet-Draft Access Control Model 14 July 2000 before the Update operation. - LDAP Update (Replace), Other, LDAP Access Request The Request will succeed if it requires only rights granted to the requesting subject by the Update operation. The Request will fail if it requires any right not granted by the Update operation. - LDAP Update (Grant), Other, LDAP Access Request The Request will succeed if it requires only rights granted to the requesting subject by the Update operation. The Request may succeed if it requires rights not granted by the Update operation, depending on the policy in force before the Update operation. - LDAP Update (Deny), Other, LDAP Access Request The Request will fail if it requires any right denied to the requesting subject by the Update operation. If the Request requires only rights which were not denied by the Update operation, it may succeed, depending on the policy in force before the Update operation. - LDAP Update (Replace), Datastore Policy Update, LDAP Query The result of the Query is not defined. - LDAP Update (Grant), Datastore Policy Update, LDAP Query The result of the Query is not defined. - LDAP Update (Deny), Datastore Policy Update, LDAP Query The result of the Query is not defined. - LDAP Update (Replace), Datastore Policy Update, LDAP Access Request The result of the Access Request is not defined. - LDAP Update (Grant), Datastore Policy Update, LDAP Access Request The result of the Access Request is not defined. - LDAP Update (Deny), Datastore Policy Update, LDAP Access Request Stokes, et al Expires 14 January 2001 [Page 34] =0C Internet-Draft Access Control Model 14 July 2000 The result of the Access Request is not defined. 10. Access Control Parameters for LDAP Controls & Extended Operations This section defines the parameters used in the access control LDAP controls and extended operations in this document. targetDN specifies the initial directory entry in DN syntax on which the control or extended operation is performed. whichObject specifies whether the access control information (in the get effective rights control) which is retrieved is for the target directory entry (ENTRY) or the target directory entry and its subtree (SUBTREE). rights in the get effective rights control or extended operation response is of the form specified in the BNF for . subject is a LDAP string that defines the subject. Access control is get/set on a subject. The syntax of the subject is the same as the subject field in the BNF. 11. Access Control Information (ACI) Controls The access control information controls provide a way to manipulate access control information in conjunction with a LDAP operation. One LDAP control is defined. This control allows access control information to be retrieved while manipulating other directory information for that entry. The control is: - getEffectiveRights to obtain the effective rights for a given directory entry(s) for a given subject during a ldap_search operation 11.1 getEffectiveRights Control 11.1.1 Request Control This control may only be included in the ldap_search message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. Stokes, et al Expires 14 January 2001 [Page 35] =0C Internet-Draft Access Control Model 14 July 2000 The controlType is set to . The criticality MAY be either TRUE or FALSE (where absent is also equivalent to FALSE) at the client's option. The controlValue is an OCTET STRING, whose value is the BER encoding of a value of the following SEQUENCE: getEffectiveRightsRequest ::=3D SEQUENCE { effectiveRightsRequest SEQUENCE OF SEQUENCE { whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, subject in BNF> | "*" } } The effectiveRightsRequest is a set of sequences that state the whichObject (entry or entry plus subtree) and specifics of the control request to be performed. A "*" in the subject field specifies that all DN types are to be used in returning the effective rights. This control is applied to the filter and scope set by the ldap_search operation, i.e. base, one-level, subtree. So the attributes/values returned are defined by the ldap_search operation. 11.1.2 Response Control This control is included in the ldap_search_response message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. The controlType is set to . There is no need to set the criticality on the response. The controlValue is an OCTET STRING, whose value is the BER encoding of a value of the following SEQUENCE: getEffectiveRightsResponse ::=3D { result ENUMERATED { success (0), operationsError (1), unavailableCriticalExtension (12), noSuchAttribute (16), undefinedAttributeType (17), invalidAttributeSyntax (21), insufficientRights (50), unavailable (52), unwillingToPerform (53), other (80) } } Stokes, et al Expires 14 January 2001 [Page 36] =0C Internet-Draft Access Control Model 14 July 2000 The effective rights returned are returned with each entry returned by the search result. The control response for ldap_search is: PartialEffectiveRightsList ::=3D SEQUENCE OF SEQUENCE { rights in BNF>, whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, subject < see in BNF > } Although this extends the search operation, there are no incompatibilities between versions. LDAPv2 cannot send a control, hence the above structure cannot be returned to a LDAPv2 client. A LDAPv3 client cannot send this request to a LDAPv2 server. A LDAPv3 server not supporting this control cannot return the additional data. 11.1.3 Client-Server Interaction The getEffectiveRightsRequest control requests the rights that MUST be in effect for requested directory entry/attribute based on the subject DN. The server that consumes the search operation looks up the rights for the returned directory information based on the subject DN and returns that rights information. There are six possible scenarios that may occur as a result of the getEffectiveRights control being included on the search request: 1. If the server does not support this control and the client specified TRUE for the control's criticality field, then the server MUST return unavailableCriticalExtension as a return code in the searchResponse message and not send back any other results. This behavior is specified in section 4.1.12 of [LDAPv3]. 2. If the server does not support this control and the client specified FALSE for the control's criticality field, then the server MUST ignore the control and process the request as if it were not present. This behavior is specified in section 4.1.12 of [LDAPv3]. 3. If the server supports this control but for some reason such as cannot process specified family and the client specified TRUE for the control's criticality Stokes, et al Expires 14 January 2001 [Page 37] =0C Internet-Draft Access Control Model 14 July 2000 field, then the server SHOULD do the following: return unavailableCriticalExtension as a return code in the searchResult message. 4. If the server supports this control but for some reason such as cannot process specified family and the client specified FALSE for the control's criticality field, then the server should process as 'no rights returned for that family' and include the result Unavailable in the getEffectiveRightsResponse control in the searchResult message. 5. If the server supports this control and can return the rights per the family information, then it should include the getEffectiveRightsResponse control in the searchResult message with a result of success. 6. If the search request failed for any other reason, then the server SHOULD omit the getEffectiveRightsResponse control from the searchResult message. The client application is assured that the correct rights are returned for scope of the search operation if and only if the getEffectiveRightsResponse control returns the rights. If the server omits the getEffectiveRightsResponse control from the searchResult message, the client SHOULD assume that the control was ignored by the server. The getEffectiveRightsResponse control, if included by the server in the searchResponse message, should have the getEffectiveRightsResult set to either success if the rights are returned or set to the appropriate error code as to why the rights could not be returned. The server may not be able to return a right because it may not exist in that directory object's attribute; in this case, the rights request is ignored with success. 12. Access Control Extended Operation An extended operation, get effective rights, is defined to obtain the effective rights for a given directory entry for a given subject. This operation may help with the management of access control information independent of manipulating other directory information. Stokes, et al Expires 14 January 2001 [Page 38] =0C Internet-Draft Access Control Model 14 July 2000 12.1 LDAP Get Effective Rights Operation ldapGetEffectiveRightsRequest ::=3D [APPLICATION 23] SEQUENCE { requestName [0] , requestValue [1] OCTET STRING OPTIONAL } where requestValue ::=3D SEQUENCE { targetDN LDAPDN, updates SEQUENCE OF SEQUENCE { whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, attr SEQUENCE { attr in BNF > }, subject < see in BNF > | "*" } } The requestName is a dotted-decimal representation of the OBJECT IDENTIFIER corresponding to the request. The requestValue is information in a form defined by that request, encapsulated inside an OCTET STRING. The server will respond to this with an LDAPMessage containing the ExtendedResponse which is a rights list. ldapGetEffectiveRightsResponse ::=3D [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] OPTIONAL, effectiveRights [11] OCTET STRING OPTIONAL } where effectiveRights ::=3D SEQUENCE OF SEQUENCE { rights in BNF>, whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, subject < see in BNF > } If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing Stokes, et al Expires 14 January 2001 [Page 39] =0C Internet-Draft Access Control Model 14 July 2000 the protocolError result code. 13. Security Considerations This document proposes protocol elements for transmission of security policy information. Security considerations are discussed throughout this draft. Because subject security attribute information is used to evaluate decision requests, it is security-sensitive information and must be protected against unauthorized modification whenever it is stored or transmitted. Interaction of access control with other directory functions (other than the ones defined in this document) are not defined in this document, but instead in the documents where those directory functions are defined. For example, the directory replication documents should address the interaction of access control with the replication function. 14. References [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [ECMA] ECMA, "Security in Open Systems: A Security Framework" ECMA TR/46, July 1988. [REQTS] Stokes, Byrne, Blakley, "Access Control Requirements for LDAP", RFC 2820, May 2000. [ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)": Attribute Syntax Definitions, RFC 2252, December 1997. [UTF] M. Wahl, S. Kille, "Lightweight Directory Access Protocol (v3)": A UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [Bradner97] Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement Levels", RFC 2119. [AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000. [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Stokes, et al Expires 14 January 2001 [Page 40] =0C Internet-Draft Access Control Model 14 July 2000 ACKNOWLEDGEMENT This is to acknowledge the numerous companies and individuals who have contributed their valuable help and insights to the development of this specification. AUTHOR(S) ADDRESS Ellen Stokes Bob Blakley Tivoli Systems Tivoli Systems 6300 Bridgepoint Parkway 6300 Bridgepoint Parkway Austin, TX 78731 Austin, TX 78731 USA USA mail-to: estokes@tivoli.com mail-to: blakley@tivoli.com phone: +1 512 436 9098 phone: +1 512 436 1564 fax: +1 512 436 1199 fax: +1 512 436 1199 Debbie Rinkevich Robert Byrne IBM Sun Microsystems 11400 Burnet Rd 29 Chemin du Vieux Chene Austin, TX 78758 Meylan ZIRST 38240 USA France mail-to: djbrink@us.ibm.com mail-to: rbyrne@france.sun.com phone: +1 512 838 1960 phone: +33 (0)4 76 41 42 05 fax: +1 512 838 8597 Stokes, et al Expires 14 January 2001 [Page 41] =0C Internet-Draft Access Control Model 14 July 2000 Stokes, et al Expires 14 January 2001 [Page 42] =0C CONTENTS 1. Introduction....................................... 2 2. The LDAPv3 Access Control Model.................... 2 3. Access Control Mechanism Attributes................ 5 3.1 Root DSE Attribute for Access Control Mechanism.................................... 5 3.2 Root DSE Attribute for Control of Disclosing Errors....................................... 5 3.3 Subentry Class Access Control Mechanism...... 6 4. The Access Control Information Attribute (ldapACI).......................................... 7 4.1 The BNF...................................... 8 4.1.1 ACI String Representation 8 4.1.2 ACI Binary Representation 10 4.2 The Components of ldapACI Attribute.......... 11 4.2.1 Scope 11 4.2.2 Access Rights and Permissions 11 4.2.3 Attributes 14 4.2.4 Subjects and Associated Authentication 15 4.3 Grant/Deny Evaluation Rules.................. 15 5. Required Permissions for each LDAP Operation....... 17 5.1 Bind Operation............................... 18 5.2 Search Operation............................. 18 5.3 Modify Operation............................. 21 5.4 Add Operation................................ 22 5.5 Delete Operation............................. 23 5.6 Modify DN Operation.......................... 23 5.7 Compare Operation............................ 24 5.8 Abandon Operation............................ 25 5.9 Extended Operation........................... 25 6. Required Permissions for Handling Aliases and References......................................... 25 6.1 ACI Distribution............................. 25 6.2 Aliases...................................... 26 6.3 Referrals.................................... 26 7. Controlling Access to Access Control Information........................................ 27 8. ACI Examples....................................... 27 8.1 Attribute Definition......................... 27 8.2 Modifying the ldapACI Values................. 28 8.3 Evaluation................................... 30 - i - 9. Operational Semantics of Access Control Operations......................................... 31 9.1 Types of actions............................. 32 9.2 Semantics of Histories....................... 32 10. Access Control Parameters for LDAP Controls & Extended Operations................................ 35 11. Access Control Information (ACI) Controls.......... 35 11.1 getEffectiveRights Control................... 35 11.1.1 Request Control 35 11.1.2 Response Control 36 11.1.3 Client-Server Interaction 37 12. Access Control Extended Operation.................. 38 12.1 LDAP Get Effective Rights Operation.......... 39 13. Security Considerations............................ 40 14. References......................................... 40 - ii - Full Copyright Statement Copyright (C) The Internet Society (2000).=A0 All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.=A0 However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. - iii - --=====================_56377510==_-- From list@netscape.com Fri Jul 14 12:15:12 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17154 for ; Fri, 14 Jul 2000 12:15:11 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6EG8pU29705; Fri, 14 Jul 2000 09:08:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6EGDdA23077; Fri, 14 Jul 2000 09:13:39 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 09:13:39 -0700 (PDT) Message-Id: <4.3.2.7.0.20000714091014.00b4ad10@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 09:12:39 -0700 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: LDAP subentry schema request for last call Cc: , , , Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_221505327==_.ALT" Resent-Message-ID: <"PXSTo.A.CoF.ywzb5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=====================_221505327==_.ALT Content-Type: text/plain; charset="us-ascii" Even if you dismiss my suggestion to align with X.500 subentry, the LDAPentry I-D still needs work and, IMO, not ready for last call. 1) Given that LDAPsubentry is NOT X.500 subentry, the I-D must explicit in defining it's semantics. As defined, it is not clear which X.500 subentry semantics apply or which ones don't. The reader cannot assume X.500 semantics apply unless the document explicitly states they do apply. It is not clear of how LDAPsubentries are scoped. It is not clear whether or not X.500 placement (at administrative points) restrictions apply to LDAPsubentries (the I-D uses a MAY). It is not clear what container restrictions, if any, are applicable. Can they be contained by the root DSE? other non-entry DSEs? Can a LDAPsubentry contain a non-LDAPsubentry? Are there restrictions upon sub-classing with other 'special' object classes (such as 'alias' and 'referral')? 2) I believe the specification of (objectclass=LDAPsubentry) filter component is inadequate and that a control should be used instead. If a filter component is used, the specification should state the semantics of filter component when it is part of an Undefined or FALSE filter component or not evaluated due to filter evaluation short circuiting. I think further overloading the search filter is a really bad idea. But beyond that, a search filter component is limited to only search operation operations and the visibility control may be needed with other operations (such as modify, see below). I proposed use of a control instead of a filter component. We have operational experience with similar controls (ManageDSAit) working well and experience with overloaded search filter components not working well (previous matched values I-D). I believe a control would facilitate implementation of LDAP-DAP gateways. But beyond this, a control is usable with any operation. I would suspect that visibility control would be needed with other operations such as modify and/or extended operations. In particular, note that in X.500 collective attributes (which an LDAP server may support) are not normally modifiable unless the subentries control is present. X.511, 11.3.2: The [modify] operation may be used to modify collective attributes only if the service control subentries is TRUE and if the object is the subentry actually holding the collective attribute(s) to be modified. (careful readers might note this sentence conflicts conflicts with 7.5(f), but that's another matter) At 09:55 AM 7/13/00 -0600, Ed Reed wrote: >With regard to making LDAPsubentry fully compatible with the X.500 subentry, it's been pointed out that people wanting to use the X.500 subentry should feel free to do so - it's incorporated by reference in the base LDAP definitions. Yes. So there must be an overwhelming reason why a replacement is needed. I don't think the complexity of the subtree specifier is an overwhelming reason. It would be similar just to grant vendors some freedom to implement portions of the specifier (as previously suggested by another member). >The purpose of this proposal is to define a subset of the X.500 functionality (and extend the structural rules by allowing nesting of LDAPsubentries) for use by certain LDAP applications which find the subset functionality a useful simplification. I believe the removal of the subtree specifier will require the introduction of replacement scoping mechanisms/placement restrictions with complexity similar to that of the subtree specifier. And if you allow LDAPsubentries to be placed anywhere in the directory, locating the applicable LDAPsubentry becomes quite complex (for both clients and servers). On an editorial note, Section 2: ... RFC 2119 [RFC2119]. The sections below reiterate these definitions and include some additional ones. The need for alternative and/or additional ones should be eliminated. This is an IESG nit: http://www.ietf.org/ID-nits.html --=====================_221505327==_.ALT Content-Type: text/html; charset="us-ascii" Even if you dismiss my suggestion to align with X.500 subentry,
the LDAPentry I-D still needs work and, IMO, not ready for last call.

1) Given that LDAPsubentry is NOT X.500 subentry, the I-D must
explicit in defining it's semantics.  As defined, it is not
clear which X.500 subentry semantics apply or which ones don't.
The reader cannot assume X.500 semantics apply unless the
document explicitly states they do apply.

It is not clear of how LDAPsubentries are scoped.  It is not
clear whether or not X.500 placement (at administrative points)
restrictions apply to LDAPsubentries (the I-D uses a MAY).

It is not clear what container restrictions, if any, are
applicable. Can they be contained by the root DSE?
other non-entry DSEs?  Can a LDAPsubentry contain a
non-LDAPsubentry?  Are there restrictions upon sub-classing
with other 'special' object classes (such as 'alias' and 'referral')?

2) I believe the specification of (objectclass=LDAPsubentry)
filter component is inadequate and that a control should be used
instead.  If a filter component is used, the specification
should state the semantics of filter component when it is
part of an Undefined or FALSE filter component or not
evaluated due to filter evaluation short circuiting.  I think
further overloading the search filter is a really bad idea.
But beyond that, a search filter component is limited to only
search operation operations and the visibility control may be
needed with other operations (such as modify, see below).

I proposed use of a control instead of a filter component.
We have operational experience with similar controls
(ManageDSAit) working well and experience with overloaded
search filter components not working well (previous matched
values I-D).  I believe a control would facilitate
implementation of LDAP-DAP gateways.

But beyond this, a control is usable with any operation.  I
would suspect that visibility control would be needed with
other operations such as modify and/or extended operations.
In particular, note that in X.500 collective attributes
(which an LDAP server may support) are not normally modifiable
unless the subentries control is present.  X.511, 11.3.2:

  The [modify] operation may be used to modify collective attributes only if the
 service control subentries is TRUE and if the object is the subentry actually
  holding the collective attribute(s) to be modified.

(careful readers might note this sentence conflicts conflicts
with 7.5(f), but that's another matter)

At 09:55 AM 7/13/00 -0600, Ed Reed wrote:

With regard to making LDAPsubentry fully compatible with the X.500 subentry, it's been pointed out that people wanting to use the X.500 subentry should feel free to do so - it's incorporated by reference in the base LDAP definitions.

Yes.  So there must be an overwhelming reason why a replacement is
needed.  I don't think the complexity of the subtree specifier is
an overwhelming reason.  It would be similar just to grant vendors
some freedom to implement portions of the specifier (as previously
suggested by another member).

The purpose of this proposal is to define a subset of the X.500 functionality (and extend the structural rules by allowing nesting of LDAPsubentries) for use by certain LDAP applications which find the subset functionality a useful simplification.

I believe the removal of the subtree specifier will require the
introduction of replacement scoping mechanisms/placement restrictions
with complexity similar to that of the subtree specifier.  And if
you allow LDAPsubentries to be placed anywhere in the directory,
locating the applicable LDAPsubentry becomes quite complex (for
both clients and servers).


On an editorial note, Section 2:
  ... RFC 2119 [RFC2119]. The sections below reiterate these definitions
  and include some additional ones.

The need for alternative and/or additional ones should be eliminated.
This is an IESG nit: http://www.ietf.org/ID-nits.html
--=====================_221505327==_.ALT-- From list@netscape.com Fri Jul 14 13:12:03 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04770 for ; Fri, 14 Jul 2000 13:12:02 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6EH21R28192; Fri, 14 Jul 2000 10:02:02 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6EHASY14620; Fri, 14 Jul 2000 10:10:28 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 10:10:28 -0700 (PDT) Sender: rsalz@xwing.netscape.com Message-ID: <396F4929.D074FD85@caveosystems.com> Date: Fri, 14 Jul 2000 13:08:57 -0400 From: Rich Salz X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: I-D ACTION:draft-zeilenga-ldap-authpasswd-03.txt References: <200007131027.GAA11142@ietf.org> <4.3.2.7.0.20000714084856.00b3f9f0@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Resent-Message-ID: <"e3zaVD.A.HkD.Dm0b5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit > Because if a flaw is found in the SHA-1 algorithm, your > directory would be vulnerable to attack if you exposed > SHA-1 values. If a flaw is found in SHA-1 then the entire public-key world will fall apart. I fail to see the point of hashing something if the hash is perceived no more secure than the plaintext. The recommendation should be dropped. /r$ From list@netscape.com Fri Jul 14 13:15:30 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05875 for ; Fri, 14 Jul 2000 13:15:29 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6EH4ZR28888; Fri, 14 Jul 2000 10:04:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6EHD2w16256; Fri, 14 Jul 2000 10:13:02 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 10:13:02 -0700 (PDT) Message-Id: <4.3.2.7.0.20000714091302.00b48510@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 10:12:53 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldapext-refer-00.txt In-Reply-To: <200007141056.GAA10686@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"Yf_Vi.A.p9D.co0b5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Roland, Thanks for putting this together. I would like to see alignment of named references (per old nameref or my I-D) and this draft. I view named references (which supports only superior and subordinate knowledge information) as a "base" (or "simple") functionality. I would prefer that other knowledge information (cross, nssr) be supported through extension of a "base" specification. I prefer this approach as it allows progression of the "base" specification separately from extensions (which are likely require additional time to ready). I think the WG direction given at IETF#46 is still quite applicable: "The authors are requested to ensure that by the next meeting we have a single base document on the simple (base) referral behavior that is suitable for last call to become a Proposed Standard." I would be happy to work with you on ensuring that a base specification was extensible. Regards, Kurt Comments inline. Excerpts from Referrals in LDAP Directories : > 1. Background and intended usage > > The broadening of interest in LDAP directories beyond their use as front > ends to X.500 directories has created a need to represent knowledge > information in a more general way. Knowledge information is information > about one or more servers maintained in another server, used to link > servers and services together. > > This document is based on the following basic assumptions: > > - several naming domains s/domains/schemes/ There is only one domain, the global domain. All naming schemes must produce names which are unique within this domain. > The usage of LDAP as a access protocol to other than X.500 servers has > created islands of directory service systems containing one or more > LDAP servers. The usage of two access protocols did not create islands. The lack of infrastructure to manage knowledge information created islands. If there was adequate infrastructure, the multiple access protocol issues (in theory) could be solved by gateways. > Each of these islands are free to pick their own naming > domain. Organizations are free to choose which scheme the choose to obtain a name within. > And that they also do; some use the old country,organization, > organizationalUnit naming scheme[X.521], some use the newer domain name > based naming scheme but these two are in no way the only ones in use. And many pull names out of thin air. Only organizations which used standard track naming schemes may partcipate in the global directory. Knowledge information infrastructure provided for each scheme varies, so some may have 'islands'. However, the protocol (and other models) supports knowledge information equally well regardless of the naming scheme used. This I-D proposes a model for managing knowledge information. It should be scheme independent. As such, I find the discussion of different naming schemes to be bit irrelevant and maybe better left to other I-Ds. > The > existence of several naming domains are in itself no real problem as > long as they produce unique names for the objects in the directory. Exactly. > Still naming schemes like the domain name based one, might easily create > non-continues naming structures because some toplevel domain names > might no find organizations that are interested and/or willing > to manage them. Therefor tree transversal might not longer be possible > except in parts of the whole tree. This is true with traditional X.500 naming as well. > > - authoritive structure vs directory structure > In some instances even if a part of the tree is delegated to one > organization, the organization doing the delegation might want to > remain as the authority for the baseobject of the delegated tree. The LDAP protocol may not be able to support such without modification. Server A delegates the subtree "o=foo" to server B but remains authority for "o=foo". A subtree search for "o=foo" sent to A, A should return "o=foo" and a search continuation to B. What would the scope (implicitly or explicitly) of the LDAP URI provided in the continuation? subtree? no, this would cause B to either return "o=foo" (if it held a replica of this entry) or a referral (back to A or other) or noSuchObject. All are not acceptable. > - support for onelevel searches > At points in the tree where the responsibility for all or almost all > of the children of a object is delegated to different organizations > and resides in different directory servers a one-level search is not > very efficient if not supported by special facilities in the directory > as such. I assume these special facilities do not change the semantics of protocol operations. > -- directory server discovery > LDAP servers that do not use dc nameing or are not registered with > SRV records in the DNS are very hard to find. You generally do not need to discover the location of an LDAP service which you have a LDAPURI for... > > This document defines a general method of representing knowledge > information in LDAP directories, based on URIs. > Two types of knowledge reference are defined: refer and subRefer. subRefer? > 2.1 The refer attribute > The refer attribute can be further specified by the use of options as > defined in section 4.1.5 of [RFC2251]. This document defines five > options and their use. Future documents might defined other options. Is an option required? If not, what is the semantics of an optionless refer attribute? I also question this use of options. Are there better approaches? I would suggest tieing the semantics of the attribute to object classes and/or type of the DSE its contained in. That is, a refer in the root dse is a superior reference, a refer in a referral object (objectclass=referral) is a subordinate, etc.. > The options defined are: > "me", "sup", "cross", "nssr" and "sub" . > > 'refer;me' is used to hold the reference of this server, and is always > held in the root DSE > > 'refer;sup' is used to hold the reference of a server superior to this > one in this global LDAP naming domain e.g. a server holding the dc=com, > dc=se, or the c=se node. The 'refer;sup' is always held in the root DSE. > 'refer;cross' indicates that this is a cross reference pointing to another > naming context within or outside this global LDAP naming domain. Suggest striking "within or outside this global LDAP naming domain". Naming schemes should be immaterial in the context of this draft. > 'refer;sub' indicates that this is a subordinate reference pointing to > a subordinate naming context in this global LDAP naming domain. Suggest striking "in this global LDAP naming domain". Naming schemes should be immaterial in the context of this draft. > 'refer;nssr' indicates that this is a non-specific subordinate reference > pointing to a subordinate naming context in this global LDAP naming domain. Suggest striking "in this global LDAP naming domain". Naming schemes should be immaterial in the context of this draft. > > 3. Use of the knowledge attribute I would prefer to attach the semantics of 'refer' attribute to the DSE type and if an entry DSE to an object class. In the case of subordinate referrals, a structural object class works well (semantics of DSE are established at instantiation time). For superior referrals, presence in the root DSE is sufficient. > 4 Behaviour specification > > 4.1 Name resolution for any operation > > Clients SHOULD perform at least simple "depth-of-referral count" loop > detection by incrementing a counter each time a new set of referrals is > received. Client behavior is specified by RFC2251. This statement replaced with a statement using wording found in RFC2251 with a clause "as per RFC2251". > 4.2.1 base-level > > If the entry matches the filter and does NOT contain a refer attribute > it will be returned to the client as described in [RFC2251]. > If the entry matches the filter contains a refer attribute without > the 'nssr' option it will be returned as a referral as described here. referral or search continuation? > If a matching entry contains a refer attribute and the URI > contained in the refer attribute is NOT an LDAP URI [RFC2255], > the server should return the URI value contained in the refer > attribute of that entry in a SearchResultReference. > > > Hedberg Expires September 30, 2000 [Page 5] > > Internet-Draft LDAP Knowledge references July 2000 > > > If a matching entry contains a refer attribute in the LDAP > URI syntax, the server will return an SearchResultReference > containing the value(s) of the refer attribute minus any optional > trailing whitespace and labels that might be present. Wouldn't the server have returned a referral as directed above? Is this for the with nssr case? If so, some clarification would be useful. > The URL from the refer attribute must be modified before it is > returned by adding or substituting a "base" scope into the URL. If the > URL does not contain a scope specifier, the "base" scope specifier must > be added. If the URL does contain a scope specifier, the existing scope > specifier must be replaced by the "base" scope. > > 4.2.2 One-level > > Any entries matching the filter and one level scope that > do NOT contain a refer attribute are returned to the client normally as > described in [RFC2251]. Any entries matching the filter and one level > scope that contains a refer attribute without the 'nssr' option must > be returned as referrals as described here. s/referrals/search continuations/ > > If a matching entry contains a refer attribute and the URI > contained in the refer attribute is NOT an LDAP URI [RFC2255], > the server should return the URI value contained in the refer > attribute of that entry in a SearchResultReference. > > If a matching entry contains a refer attribute in the LDAP > URI syntax, the server will return an SearchResultReference > containing the value(s) of the refer attribute minus any optional > trailing whitespace and labels that might be present. > The URL from the refer attribute must be modified before it is > returned by adding or substituting a "base" scope into the URL. If the > URL does not contain a scope specifier, the "base" scope specifier must > be added. If the URL does contain a scope specifier, the existing scope > specifier must be replaced by the "base" scope. > > 4.2.3 Subtree search evaluation > > Any entries, held by the server, matching the filter and > subtree scope that do NOT contain a refer attribute or contains > a refer attribute with the 'nssr' option are > returned to the client normally as described in [RFC2251]. > Any entries matching the subtree scope and containing a refer > attribute must be returned as referrals as described here. s/referrals/search continuations/ > If a matching entry contains a refer attribute and the URI > contained in that attribute is NOT an LDAP URI [RFC2255], > the server should return the URI value contained in the refer > attribute of that entry in a SearchResultReference. > > > > > > Hedberg Expires September 30, 2000 [Page 6] > > Internet-Draft LDAP Knowledge references July 2000 > > If a matching entry contains a refer attribute in the LDAP > URI syntax, the server will return an SearchResultReference > containing the value(s) of the refer attribute minus any > optional trailing whitespace and labels that might be present. > > N.B. in subtree search evaluation a entry containing a > refer attribut with the 'nssr' option might appear twice in the > result, first as a entry and then as a reference. A client > following all references might therefore end up with a resultset > containing two representations of the same entry, one from the > server getting the original query and one from the server > that the 'nssr' reference points to. A (non-extended) search operation should not return the same entry multiple times. If a server returns a search continuation that server must be capable of completely the operation. It is inappropriate for it to return entries which were returned by other servers as part of a single distributed search operation. > 5. The referral object class > > The referral object class is defined as follows. > > ( 1.2.752.17.2.10 > NAME 'referral' > SUP top > STRUCTURAL > MAY ( refer ) ) I suggest this new object class use a new name. I suggest LDAPreferral. > The referral object class is a subclass of top and may contain the > refer attribute. What are the semantics associated with a referral object without an refer attribute? Which such an entry be normally visible? > The referral object class should, in general, > be used in conjunction with the extensibleObject object class to support > the naming attributes used in the entry's distinguished name. I suggest stating that the refer attribute itself should NOT be used for naming purposes. > Servers must support the refer attributes through use of the > referral object class. Any named reference must be of the referral > object class and will likely also be of the extensibleObject object > class to support naming and use of other attributes. > For all uses of refer? This seems odd. From list@netscape.com Fri Jul 14 13:45:38 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16769 for ; Fri, 14 Jul 2000 13:45:38 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6EHdDU14214; Fri, 14 Jul 2000 10:39:14 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6EHi1o03517; Fri, 14 Jul 2000 10:44:01 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 10:44:01 -0700 (PDT) Message-Id: <4.3.2.7.0.20000714104250.00b3c3e0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 10:43:54 -0700 To: Rich Salz From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-zeilenga-ldap-authpasswd-03.txt Cc: ietf-ldapext@netscape.com In-Reply-To: <396F4929.D074FD85@caveosystems.com> References: <200007131027.GAA11142@ietf.org> <4.3.2.7.0.20000714084856.00b3f9f0@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"d8RXfD.A.o2.gF1b5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 01:08 PM 7/14/00 -0400, Rich Salz wrote: >> Because if a flaw is found in the SHA-1 algorithm, your >> directory would be vulnerable to attack if you exposed >> SHA-1 values. > >If a flaw is found in SHA-1 then the entire public-key world will fall >apart. Note that in the public key world it is generally recommended to key private keys protected by multiple layers of security. From list@netscape.com Fri Jul 14 14:17:01 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26686 for ; Fri, 14 Jul 2000 14:17:01 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6EIAjU19377; Fri, 14 Jul 2000 11:10:45 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6EIFXU19121; Fri, 14 Jul 2000 11:15:33 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 11:15:33 -0700 (PDT) Message-Id: <4.3.2.7.0.20000714110212.00b65d10@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 11:15:22 -0700 To: Rich Salz From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-zeilenga-ldap-authpasswd-03.txt Cc: ietf-ldapext@netscape.com In-Reply-To: <396F4929.D074FD85@caveosystems.com> References: <200007131027.GAA11142@ietf.org> <4.3.2.7.0.20000714084856.00b3f9f0@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"xZWCiB.A.aqE.Dj1b5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I have added to "Background and Intended Usage" Storage schemes often use of cryptographic strength one-way hashing. Though the use of one-way hashing reduces the potential that exposed values will allow unauthorized access to the Directory (unless the hash algorithm/implementation is flawed), the hashing of passwords is intended to be as an additional layer of protection. It is RECOMMENDED that hashed values be protected as if they were clear text passwords. and to "Security Considerations" As flaws may be discovered in the hashing algorithm or with a particular implementation of the algorithm, values of AuthPassword SHOULD be protected as if they were clear text passwords. When values are transferred, privacy protections, such as IPSEC or TLS, SHOULD be in place. From list@netscape.com Fri Jul 14 17:08:35 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21434 for ; Fri, 14 Jul 2000 17:08:34 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6EKwcR01007; Fri, 14 Jul 2000 13:58:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6EL75Y07933; Fri, 14 Jul 2000 14:07:05 -0700 (PDT) Resent-Date: Fri, 14 Jul 2000 14:07:05 -0700 (PDT) Message-Id: <4.3.2.7.0.20000714135237.00b8b1e0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 14:06:58 -0700 To: ietf-ldapext@netscape.com, ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LDAPv3bis BOF at IETF#48 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"UQOT7.A.o7B.4D4b5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com The following BOF has been approved and should be scheduled soon. Those interested are encouraged to participate. Please note that we are only collecting suggested changes. This will be used as an aid in identifying items needing to be worked and to develop more concrete proposals. Below is the draft agenda for this BOF. If you like to propose additional agenda items, please drop Bob and I a note. Regards, Kurt Name: LDAPv3bis Chairs: Kurt Zeilenga RL "Bob" Morgan Mailing list: ietf-ldapv3bis@OpenLDAP.org http://www.openldap.org/lists/ietf-ldapv3bis/ Introduction: LDAPv3 core specifications (RFC 2251-56) must be revised if they are to be progressed to Draft Standard per the IESG Notice contained within these documents. With the approval of RFC 2829 and 2830, the necessary secure authentication mechanisms to obtain Draft Standard status have now available. In addition, the community has obtain a wealth of operational experience using the current specifications. The community has identified a number of areas where the specifications need to amended. These amendments include a few significant substantive changes, a fair number of lessor substantive changes, and many clarifications. A forum for discussing and addressing these issues is needed. Purpose: The purpose of this BOF is to discuss proposed updates to the LDAPv3 core protocol specification (RFC 2251-56, 2829-30), to identify work items, and discuss formation of a working group specifically chartered to address identified work items. Extensions to LDAPv3 are not within the scope of this BOF as this is the realm of existing IETF working groups. Background: The LDAPv3 specifications were developed by the ASID and LDAPext working groups. The ASID working group is defunct. The LDAPext WG is focused on significant protocol extensions such as Access Control, APIs, Referrals, and CLDAP. A separate working group is currently proposed to focus energies to address LDAPv3 specification updates while not distracting LDAPext from their chartered work. However, at the discretion of the IESG, work items identified by this BOF may be assigned to LDAPext or other appropriate WG (after appropriate charter review). Agenda: Agenda Review Introduction Discuss IESG Note Discuss LDAPv3 Applicability Statement Discuss incorporation of rescodes I-D into 2251bis Discuss incorporation of partial responses I-D into 2251bis Discuss reorganization of specification Discuss Mark Wahl's 75+ odd changes Discuss Kurt Zeilenga's 75+ odd changes Discuss relationship to X.500 issues Discuss other issues Discuss working group formation issues RFC to be discussed: 2251-2256, 2829-2830 I-D to be discussed: draft-hodges-ldapv3-as-00.txt draft-just-ldapv3-rescodes-02.txt draft-rharrison-ldap-extpartresp-01.txt draft-wahl-ldapv3bis-*.txt (to be issued) draft-zeilenga-ldapv3bis-*.txt From list@netscape.com Sat Jul 15 10:12:58 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01825 for ; Sat, 15 Jul 2000 10:12:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6FE2qR02308; Sat, 15 Jul 2000 07:02:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6FEBKM25686; Sat, 15 Jul 2000 07:11:20 -0700 (PDT) Resent-Date: Sat, 15 Jul 2000 07:11:20 -0700 (PDT) Date: Sat, 15 Jul 2000 10:09:46 -0400 From: Message-Id: <200007151409.KAA03124@pc1.caveosystems.com> To: Kurt@openldap.org, rsalz@CaveoSystems.com Subject: Re: I-D ACTION:draft-zeilenga-ldap-authpasswd-03.txt Cc: ietf-ldapext@netscape.com X-Loop-Detect: 1 Resent-Message-ID: <"isJ-jC.A.rQG.HEHc5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com >Note that in the public key world it is generally recommended to >key private keys protected by multiple layers of security. But hashes are public. No matter the content, it is safe to expose the hash. /r$ From list@netscape.com Sat Jul 15 10:48:23 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09879 for ; Sat, 15 Jul 2000 10:48:22 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6FEg6U14814; Sat, 15 Jul 2000 07:42:06 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6FEktk02135; Sat, 15 Jul 2000 07:46:55 -0700 (PDT) Resent-Date: Sat, 15 Jul 2000 07:46:55 -0700 (PDT) Date: Sat, 15 Jul 2000 10:45:29 -0400 From: Message-Id: <200007151445.KAA03278@pc1.caveosystems.com> To: Kurt@openldap.org, rsalz@CaveoSystems.com Subject: Re: I-D ACTION:draft-zeilenga-ldap-authpasswd-03.txt Cc: ietf-ldapext@netscape.com X-Loop-Detect: 1 Resent-Message-ID: <"hKpmhB.A.-g.dlHc5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I still strongly disagree. When it comes to hashes and crypto, we should defer to the IETF PKIX WG, or have a strongly justifiable reason for doing so -- enough to convince PKIX to change. This means: MD5 should be discouraged. SHA1 results are public. Perhaps we should ask IET-PKIX folks for an opinion? From list@netscape.com Sat Jul 15 11:15:20 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18116 for ; Sat, 15 Jul 2000 11:15:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6FF5SR05365; Sat, 15 Jul 2000 08:05:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6FFDu607139; Sat, 15 Jul 2000 08:13:56 -0700 (PDT) Resent-Date: Sat, 15 Jul 2000 08:13:56 -0700 (PDT) Message-Id: <4.3.2.7.0.20000715072026.00ae9a60@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 15 Jul 2000 08:13:24 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-zeilenga-ldap-authpasswd-03.txt Cc: rsalz@CaveoSystems.com, ietf-ldapext@netscape.com In-Reply-To: <200007151409.KAA03124@pc1.caveosystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"6LAa2D.A.MvB.z-Hc5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 10:09 AM 7/15/00 -0400, rsalz@CaveoSystems.com wrote: >>Note that in the public key world it is generally recommended to >>key private keys protected by multiple layers of security. > >But hashes are public. No matter the content, it is safe to expose >the hash. > /r$ I disagree when the content is an authentication secret. Like any other algorithm, hashing algorithms (and their application) are subject to flaws of design and implementation and we, as users of these algorithms, should take this into consideration. If such a flaw were discovered, the secret would be vulnerable. As such, additional protections, in my option, are warranted. If you look at modern systems which use password hashing, you should find additional layers of protection. Also, if you look at modern systems which use other cryptographic algorithms (such as a cipher) to protect authentication secrets, you will find other layers of protection. Kurt From list@netscape.com Sat Jul 15 12:03:39 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29617 for ; Sat, 15 Jul 2000 12:03:38 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6FFvLU18709; Sat, 15 Jul 2000 08:57:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6FG2AM16065; Sat, 15 Jul 2000 09:02:10 -0700 (PDT) Resent-Date: Sat, 15 Jul 2000 09:02:10 -0700 (PDT) Message-Id: <4.3.2.7.0.20000715081410.00af5150@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 15 Jul 2000 09:02:04 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-zeilenga-ldap-authpasswd-03.txt Cc: rsalz@CaveoSystems.com, ietf-ldapext@netscape.com In-Reply-To: <200007151445.KAA03278@pc1.caveosystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"BsE8g.A.s6D.AsIc5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 10:45 AM 7/15/00 -0400, rsalz@CaveoSystems.com wrote: >I still strongly disagree. Noted. We've beaten this horse to death. I am open for review by others and will submit the subsequent revisions of this draft to "experts" (namely the Security Area Director(s)). I suggest we defer this discussion for now. I will also request a recommendation for hash algorithm selection and make changes based upon this recommendation. From list@netscape.com Sat Jul 15 12:19:00 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03474 for ; Sat, 15 Jul 2000 12:18:59 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6FG6IR08649; Sat, 15 Jul 2000 09:06:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6FGElQ18916; Sat, 15 Jul 2000 09:14:47 -0700 (PDT) Resent-Date: Sat, 15 Jul 2000 09:14:47 -0700 (PDT) Date: Sat, 15 Jul 2000 12:13:24 -0400 From: Message-Id: <200007151613.MAA03823@pc1.caveosystems.com> To: Kurt@openldap.org Subject: Re: I-D ACTION:draft-zeilenga-ldap-authpasswd-03.txt Cc: ietf-ldapext@netscape.com X-Loop-Detect: 1 Resent-Message-ID: <"bmTjuB.A.PnE.13Ic5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Your plan makes complete sense to me; I'll abide by the review. Thanks! From list@netscape.com Sun Jul 16 00:30:20 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04336 for ; Sun, 16 Jul 2000 00:30:19 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6G4O1U14705; Sat, 15 Jul 2000 21:24:02 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6G4SpA22735; Sat, 15 Jul 2000 21:28:51 -0700 (PDT) Resent-Date: Sat, 15 Jul 2000 21:28:51 -0700 (PDT) Date: Sat, 15 Jul 2000 21:28:31 -0700 (PDT) From: a_z49@yahoo.com Message-Id: <200007160428.e6G4SVM19320@ywing.netscape.com> Resent-Message-ID: <"GkgksB.A.qiF._nTc5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com Subject: Unidentified subject! X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com TIRED OF ENDLESSLY POSTING YOUR ONLINE CLASSIFIED AD AND GETTING NORESULTS? The fact is there are over 7000 such sites scattered about the web and frankly none of them generate enough traffic to be worth your while. Even when someone does find or visits one of these sites, your ad is hopelessly lost in a myriad of similar offerings. Another frustration is search engines. If you are not in the Top 10 forget about high traffic visiting your web site. Not everyone can be in the Top 10 and stay there, when there are estimates of 4 million that have a web pages. You ask, how do we know? That's exactly what we used to do. The greatest way of marketing this century is undoubtedly direct e-mail. It's similar to the postman delivering a letter to your mailbox. There is NO stumbling on to it! The ability to promote your product, service, website, or MLM/Network Marketing opportunity to millions instantly is what advertisers have been dreaming of for over 100 years. We will e-mail your one page promotion to a list of our general addresses. The greatest part is, it's completely affordable. ----------------------------------------------------------------------- NOTICE: No pornography, chain letters, get quick rich, pyramid scheme, or any threatening or questionable materials. Don't even Ask!! ----------------------------------------------------------------------- STANDARD PRICING AND PROCEDURES ----------------------------------------------------------------------- EXTRACTING:Our list of general Internet addreses are actually extracted from the most popular web sites on the Internet. The addresses are verified and run through our purification process. The process includes addresses run against our custom filter of 2,492 keywords to remove as well as through our 192MB remove /flamer list. The EDU, ORG, GOV, Mil, and US domains are removed as well as well as other domains that asked not to receive e-mail. ----------------------------------------------------------------------- SET-UP FEE: $150.00 This will cover the costs of uploading files, Internet Access (ISP), and software set-up. ----------------------------------------------------------------------- EVALUATION: $350.00 (optional) One of our Marketing Specialists will evaluate your sales letter, and offer his/her expertise on how to make it the most successful. ----------------------------------------------------------------------- STANDARD PRICING: (Emails Delivered)1 Million- $800.00 per2 Million- $700.00 per 3 Million & up- $600.00 per ----------------------------------------------------------------------- SPECIAL OFFER!This introductory offer of $475.00 includes:1. Set-Up Fee 2. Evaluation of sales letter 3. 250,000 e-mails delivered to a general list of recipients. ----------------------------------------------------------------------- PAYMENT POLICY All services must be paid in full prior to delivery of advertisement. Under NO CIRCUMSTANCES will any sales or marketing strategies be discussed until payment is received. ----------------------------------------------------------------------- If you are serious about Direct Email Marketing-Fax the following form to (520) 438-2702 ---------------------------------------------------------------------- THIS FORM MUST BE COMPLETELY FILLED OUT! Contact Name: _____________________________________________ Business Name: ______________________________________ Business Type: ______________________________________ # Years in Business: _________________________ Address: _________________________________________________ City: ____________________ State: ______ Zip: ______________ Country: _______________ Email Address: _______________________________________________ Phone: __________________________Fax: ____________________________ ----------------------------------------------------------------------- From list@netscape.com Mon Jul 17 00:45:15 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10555 for ; Mon, 17 Jul 2000 00:45:14 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6H4cWU05795; Sun, 16 Jul 2000 21:38:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6H4d8E17412; Sun, 16 Jul 2000 21:39:08 -0700 (PDT) Resent-Date: Sun, 16 Jul 2000 21:39:08 -0700 (PDT) Reply-To: From: "Steven Legg" To: Cc: , Subject: RE: LDAP subentry alignment with X.500 subentry Date: Mon, 17 Jul 2000 13:08:52 +1000 Message-ID: <001501bfef9c$56aa6f10$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <001701bfed6c$c3a0a800$17448490@vic.bigpond.net.au> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Resent-Message-ID: <"7V_FUD.A.lNE.R3oc5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Albert, > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Albert Langer > Sent: Friday, 14 July 2000 18:23 > To: Robert.Byrne@France.Sun.COM; Alan.Lloyd@ca.com; Ron.Ramsay@ca.com; > ietf-ldapext@netscape.com > Cc: ietf-ldup@imc.org > Subject: RE: LDAP subentry alignment with X.500 subentry [snip] > [Robert] > Albert, doesn't an entry know the other attributes that it > contains as well > and so could evaluate an arbitrary filter ? > [Albert] > Sorry, I should have said "the (structural) object class of > an entry is > fixed and therefore the set of applicable subentries does not > need to be > recalculated on every search". With general filters such a > calculation would > be needed on every search, for every subentry that has a > parent within the > base of the search applied to every entry within the scope of > the search. > This is multiplying the cost of a search by the number of potentially > applicable subentries (not just the number of actually applicable > subentries). The specificationFilter of a SubtreeSpecification applies to the objectClass attribute rather than the structuralObjectClass. Since the objectClass can contain optional auxiliary object classes that come and go, a conformant X.500 implementation already has to deal with the situation where the set of applicable subentries changes. Some of our customers need to be able to set access controls based on the non-objectClass attributes of the entry. The way we have achieved this with X.500 basic access control is to define an auxiliary object class, with no mandatory or optional attributes, that we use to tag entries satisfying an implied filter on the entry contents. SubtreeSpecifications then reference the auxiliary class in their specificationFilters. The auxiliary class tagging has to be maintained manually. Being able to filter on arbitrary entry contents in the specificationFilter would be better. [snip] > > Please send or CC any comments to LDUP as I won't see them in LDAP-EXT. > > Seeya, Albert Regards, Steven From list@netscape.com Mon Jul 17 00:49:47 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11039 for ; Mon, 17 Jul 2000 00:49:47 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6H4hWU06119; Sun, 16 Jul 2000 21:43:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6H4kIU21808; Sun, 16 Jul 2000 21:46:18 -0700 (PDT) Resent-Date: Sun, 16 Jul 2000 21:46:18 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Mark Wahl'" Cc: Subject: RE: Unique identifiers for LDAP attributes Date: Mon, 17 Jul 2000 13:32:31 +1000 Message-ID: <001601bfef9f$a443d290$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <29562.963588666@threadgill.austin.innosoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Resent-Message-ID: <"a7M0AD.A.pMF.O9oc5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Mark, > -----Original Message----- > From: wahl@austin.innosoft.com [mailto:wahl@austin.innosoft.com]On > Behalf Of Mark Wahl > Sent: Saturday, 15 July 2000 1:31 > To: d.w.chadwick@salford.ac.uk > Cc: ietf-ldapext@netscape.com; Ramsay, Ron > Subject: Re: Unique identifiers for LDAP attributes > > > > Its RFC 2252 section 4.2: > > > Schema developers MUST NOT create attribute definitions > whose names > > conflict with attributes defined for use with LDAP in existing > > standards-track RFCs. The problem is not that schema designers are using standard defined attribute names in new definitions but rather that schema designers are unwittingly using the same names in new definitions where those new definitions are different (different OIDs or different syntaxes or different equality matching, etc). And there is no guarantee that an unused attribute name I choose today isn't going to be commandeered by some future standard. Regards, Steven Adacel Technologies > > Mark Wahl, Directory Architect, Service Provider/Infrastructure > Sun Microsystems, Inc. iPlanet Alliance > > From list@netscape.com Mon Jul 17 01:05:33 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13277 for ; Mon, 17 Jul 2000 01:05:32 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6H4tWR05116; Sun, 16 Jul 2000 21:55:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6H4pX226316; Sun, 16 Jul 2000 21:51:33 -0700 (PDT) Resent-Date: Sun, 16 Jul 2000 21:51:33 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Ramsay, Ron'" Cc: Subject: RE: Unique identifiers for LDAP attributes Date: Mon, 17 Jul 2000 14:23:17 +1000 Message-ID: <001901bfefa6$bbcc6f10$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <11981F9F5649D411BC92009027D0D18C5B7CF9@aspams01.cai.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Resent-Message-ID: <"fymDPB.A.VZG.ODpc5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Ron, We have customers with 100+ locally defined attribute types in their schemas so most of the attribute types would be flowing back and forth as OIDs under the "middle course". This doesn't look substantially different to me than deprecating the use of type names for all attribute types, even the standard ones. If a significant number of attributes are known only by OID then they might as well all be. A creeping list of recognized attribute names sounds like more trouble than if we just fixed the list of attribute names as they stand now. Regards, Steven > -----Original Message----- > From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com] > Sent: Friday, 14 July 2000 14:43 > To: d.w.chadwick@salford.ac.uk; ietf-ldapext@netscape.com > Subject: RE: Unique identifiers for LDAP attributes > > > David, > > I agree with the philosophy. However, there may be a middle > course. Where > the attribute has been standardised by appearing in an IETF > standard, the > name used in the standard could be considered standardised. > For all other > attributes, an OID is required. There may be other > publication methods which > can standardise attribute names, eg informational RFCs. > > Ron. > > -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] > Sent: Friday, 14 July 2000 0:03 > To: ietf-ldapext@netscape.com > Subject: Unique identifiers for LDAP attributes > > > Folks > > I was at a Middleware meeting a few weeks ago where some guys > from Internet 2 were talking about outstanding problems with LDAP. > One of the points raised was the lack of a unique name for attribute > types, and that two LDAP servers could have the same name for > different attributes or different names for the same attribute. They > were wanting to create a group that could standardise on the > names of LDAP attribute types. When I pointed out to them that we > already have unique identifiers for each attribute type in the shape > of OIDs, that do not have the multilingual and character set > problems that strings have, they seemed convinced that this could > work. > > However, we have the situation that some LDAP servers do not > require OIDs to be defined for attribute types, and the LDAP spec > deprecates the use of OIDs in protocol in preference to strings. > > Given that many LDAP clients now map the attribute type strings > from protocol into a user friendly language dependent display string, > the string representation in protocol has about had its day and > served its purpose. Isnt it about time that we altered the LDAP > spec to recommend that OIDs be the preferred way of transferring > attribute types in protocol, and that the OIDs become the globally > unique way of identifying attribute types. > > (Firewalls up to protect from flames) > > David > > *************************************************** > > David Chadwick > IS Institute, University of Salford, Salford M5 4WT > Tel +44 161 295 5351 Fax +44 161 745 8169 > Mobile +44 790 167 0359 > Email D.W.Chadwick@salford.ac.uk > Home Page http://www.salford.ac.uk/its024/chadwick.htm > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string MLJ9-DU5T-HV8J > > *************************************************** > > From list@netscape.com Mon Jul 17 02:46:06 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00404 for ; Mon, 17 Jul 2000 02:46:06 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6H6a6R11844; Sun, 16 Jul 2000 23:36:06 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6H6IVE23018; Sun, 16 Jul 2000 23:18:31 -0700 (PDT) Resent-Date: Sun, 16 Jul 2000 23:18:31 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C6190FF@aspams01.cai.com> From: "Lloyd, Alan" Cc: ietf-ldapext@netscape.com Subject: RE: Unique identifiers for LDAP attributes Date: Mon, 17 Jul 2000 16:18:32 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"PJMlEC.A.FnF.0Uqc5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I think the basic issue again comes down to discipline.. The OSI and OID stuff was considered all too hard and long winded, registration, formality, etc as opposed to quick fix - cut the code, see it works stuff.. X.500 defined 15 or so OCs and about 40 attributes as its base information set... with OIDs we all know that. So where we (in the directory world) build systems for online customers we go through the formal schema design processes and where required, OIDs registration under our national bodies. Just to ensure these orgs who spend a lot of money on these systems - we are always concened that commercial work does not get undermined by "an experimental document" out of somewhere.. We cannot change history - but would should learn that the issue with directories is not one of protocols - but one of information standardisation and identification. Simply because commincation protocols can go through gateways, but transforming information - is a real pain (synrax, semantic, naming, etc. If there are no engineering or doctrinal rules applied - how is it a standards process? XML will hit this issue .. but is anyone concerned? XML - a simple Ebusiness solution.. seen that before eh! using OIDs means that the author and the standards organisation under which they are registered are taking some care - it isnt perfect but it does mean existing systems should not be compromised. regards alan -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Monday, July 17, 2000 1:33 PM To: 'Mark Wahl' Cc: ietf-ldapext@netscape.com Subject: RE: Unique identifiers for LDAP attributes Mark, > -----Original Message----- > From: wahl@austin.innosoft.com [mailto:wahl@austin.innosoft.com]On > Behalf Of Mark Wahl > Sent: Saturday, 15 July 2000 1:31 > To: d.w.chadwick@salford.ac.uk > Cc: ietf-ldapext@netscape.com; Ramsay, Ron > Subject: Re: Unique identifiers for LDAP attributes > > > > Its RFC 2252 section 4.2: > > > Schema developers MUST NOT create attribute definitions > whose names > > conflict with attributes defined for use with LDAP in existing > > standards-track RFCs. The problem is not that schema designers are using standard defined attribute names in new definitions but rather that schema designers are unwittingly using the same names in new definitions where those new definitions are different (different OIDs or different syntaxes or different equality matching, etc). And there is no guarantee that an unused attribute name I choose today isn't going to be commandeered by some future standard. Regards, Steven Adacel Technologies > > Mark Wahl, Directory Architect, Service Provider/Infrastructure > Sun Microsystems, Inc. iPlanet Alliance > > From list@netscape.com Mon Jul 17 04:00:30 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17597 for ; Mon, 17 Jul 2000 04:00:26 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6H7s6U18364; Mon, 17 Jul 2000 00:54:06 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6H7wvI24029; Mon, 17 Jul 2000 00:58:57 -0700 (PDT) Resent-Date: Mon, 17 Jul 2000 00:58:57 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C62C82A@aspams01.cai.com> From: "Lloyd, Alan" To: steven.legg@adacel.com.au, "Ramsay, Ron" Cc: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft Date: Mon, 17 Jul 2000 17:58:55 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"1Wh-.A.n2F.9yrc5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com We have had this debate havnt we... If you use DAP or DISP or DSP - then the P_Layer is the ASN.1 decode/encode (C++-BER) which must be there.. Internal representation (C++) to transfer syntax (BER)... This leaves us with the S_Layer which in OSI terms was/is the same (almost) a every FAX machine on this planet... But as we know the fundamental use of TLS/SSL for security in most application protocols - it still means we have DAP, etc over P-Layer over SSL/TLS... So DAP over TCP is not very commercially acceptable.. is it? OSI wasnt complex.. and now - with SSL/TLS - I think a simple stack is "history"...Try OCSP over HTTP over SSL! But the point is - the issue is not the stacks any more - its how one builds large scale distributed information systems... and if the stack is complex what label would one put on the rest of the distributed directory system code - regards alan -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Monday, July 17, 2000 1:39 PM To: Ramsay, Ron Cc: ietf-ldapext@netscape.com Subject: RE: Revised Matched Values Draft It's now part of the amendments to X.519 and X.501. > -----Original Message----- > From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com] > Sent: Friday, 14 July 2000 17:13 > To: steven.legg@adacel.com.au; 'Kurt D. Zeilenga' > Cc: ietf-ldapext@netscape.com > Subject: RE: Revised Matched Values Draft > > > You got your proposal through? > > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Friday, 14 July 2000 16:33 > To: 'Kurt D. Zeilenga' > Cc: ietf-ldapext@netscape.com > Subject: RE: Revised Matched Values Draft > > > > > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > Sent: Thursday, 13 July 2000 3:05 > > To: Lloyd, Alan > > Cc: Miklos, Sue A.; Bruce Greenblatt; d.w.chadwick@salford.ac.uk; > > ietf-ldapext@netscape.com > > Subject: RE: Revised Matched Values Draft > > > > > > At 11:38 PM 7/12/00 +1000, Lloyd, Alan wrote: > > >Isnt it amazing that the reason for LDAP was that DAP was > > too complex - and > > >here we are (years later) adding more complexity to LDAP > > beyond that of > > >DAP..:-) > > > regards alan > > > > The primary complexity of DAP that LDAP removed was need to > implement > > the ISO protocol stack. > > Even the OSI stack can be avoided now. The 2000 edition of > X.500 contains > the provisions for mapping the protocols directly onto TCP/IP. > > Regards, > Steven > > > From list@netscape.com Mon Jul 17 05:40:58 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12095 for ; Mon, 17 Jul 2000 05:40:54 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6H9YaU24648; Mon, 17 Jul 2000 02:34:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6H9dRo03291; Mon, 17 Jul 2000 02:39:27 -0700 (PDT) Resent-Date: Mon, 17 Jul 2000 02:39:27 -0700 (PDT) Date: Mon, 17 Jul 2000 05:39:06 -0400 (EDT) Date-warning: Date header was inserted by SMTP00.InfoAve.Net From: free-info@uip.sanet.sk (E. F. Publications) Subject: FREE! Start Your Own Software Business. To: free-info@uip.sanet.sk Reply-to: "info- 2000"@uip.sanet.sk Message-id: <200007172995AAA52390@post.com> Comments: Authenticated sender is Resent-Message-ID: <"CLDDGC.A.zy.NRtc5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com ********************************************************** Make Up To $247,500 Distributing Our Complete Line OF Money-Making Software That You Can Virtually Get (From Us) -- For FREE! ********************************************************** Become a Distributor for our entire line of Money Making Software, and we will fulfill all the orders you can get - at NO COST TO YOU! - When people order our Software, they'll pay you $99 plus $16 shipping & handling. - Out Of the $99 selling price, You Keep $99. - The only portion that goes to us is the $16 shipping & handling fee. We'll process, pack and ship all orders direct to your customers. This means you don't have to mess around with fulfillment. No products to put in boxes. No licking stamps. No trips to the Post Office... We do all the work for you. We will fulfill and ship up to 2,500 Software orders at Zero ($0) Price to you. This means that you can make up to ($99 X 2,500 =) $247,500 without having to pay a penny for our Software. Earn instant gobs of cash in the most unusual, and quite possibly the most generous Distributor Program in the market today. So hurry. To receive your FREE Distributor Information simply fill out the "Free Info Pak Coupon" and mail coupon below to... E. F. Publications, Box 382, Ridgeland,SC 29936 ********************************************************* FREE INFO PAK COUPON I want To become a Software Distributor Please Send me a free Distributor Information Pack to this address. Thanks! NAME: -------------------------------------------------- ADDRESS: -------------------------------------------------- CITY: -------------------------------------------------- STATE: ---------------------------ZIP-------------------- EMAIL -------------------------------------------------- From list@netscape.com Mon Jul 17 05:54:57 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15057 for ; Mon, 17 Jul 2000 05:54:57 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6H9mhU25973; Mon, 17 Jul 2000 02:48:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6H9rYU07698; Mon, 17 Jul 2000 02:53:34 -0700 (PDT) Resent-Date: Mon, 17 Jul 2000 02:53:34 -0700 (PDT) Date: Mon, 17 Jul 2000 02:53:21 -0700 (PDT) Message-Id: <200007170953.e6H9rKM20981@ywing.netscape.com> From: john@smartbox.co.uk To: Business@ywing.netscape.com, Opportunity@netscape.com Subject: Unusual Oriental Opportunity X-Reply-To: john@smartbox.co.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0lbQFC.A.63B.detc5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hi Your name has been given to us as a person who is interested in highly lucrative business opportunities. If that is not the case or you would prefer not to hear from us again, please hit "reply" and send us a blank message with "remove" in the subject heading. We honour all remove requests. Many thanks. -------------------------------------------------------------------- Drive a brand new car of your choice and let our company pay for it. Get a brand new house and let our company make the monthly payments up to $10,000 per month. The single largest event in network marketing history is about to happen. You can get positioned NOW in front of tens of thousands of people already lined up and ready to join. Most people never get the opportunity like this to join *BEFORE* something this big happens. Consider this: * 15 Year International Company * Traded on the NASDAQ * Online Marketing Tools * Phenomenal Support Systems * Huge Compensation Plan * House bonus * Car bonus * Residual income Go to the web site below to get all the details. http://www.nflijapan.com/183966 Don't drag your feet on this one. It could very well be what you have been waiting for all your life! From list@netscape.com Mon Jul 17 09:48:48 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14664 for ; Mon, 17 Jul 2000 09:48:45 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6HDgIU10205; Mon, 17 Jul 2000 06:42:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6HDlAk02859; Mon, 17 Jul 2000 06:47:10 -0700 (PDT) Resent-Date: Mon, 17 Jul 2000 06:47:10 -0700 (PDT) X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: , Subject: RE: LDAP subentry alignment with X.500 subentry Date: Mon, 17 Jul 2000 23:46:40 +1000 Message-ID: <000801bfeff5$702bae00$17448490@vic.bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <001501bfef9c$56aa6f10$b05508cb@osmium.adacel.com.au> Importance: Normal Resent-Message-ID: <"R3bqSC.A.Ns.c5wc5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Steven, Thanks for: a) The correction below. b) The explanation of why the non-restriction to structural classes is useful. c) The explanation of why general filters would be more useful. Clearly I was wrong about the restriction to object class avoiding any need to dynamically track which DACDs an entry is in, though I still think it might be simpler and more efficient than for a general filter, eg some implementations only having to recalculate when an entry changes its object class attribute (rarely), rather than for any change. I'm still not convinced about the advantage of c) over b), although this certainly does at least diminish one argument against c). Other reasons are: 1. General principle that LDAP should remain "lighter" than X.500 and compatible with it. Therefore any superset variations should be demonstrably necessary, eg to simplify something else, not just desirable. Proper subentries are demonstrably necessary to simplify access control. As Kurt pointed out, not providing them will just result in more complex ways of doing the same thing being required anyway. But "enhanced" subentries are not demonstrably necessary. 2. What kinds of DACD can be specified should be a matter for schema administrators (ie "manually" in practice), not for access control administrators. It really is an issue of maintaining consistent schema (in this case for access control) so that there is a common understanding of what each type of DACD actually means. Maintaining that commonality of understanding of the schema is inevitably and intentionally less flexible than the changes that other kinds of administrators and end users should be allowed to make to the directory. The concept of a DACD is currently less familiar to LDAP administrators, who are often both schema and access control administrators (whether or not they understand much about either). The concept of a general filter is more familiar to them, but the relative rigidity of DACDs will actually make it easier for administrators and end users to understand in the long run, as the point of standardizing these things is to enable full interoperability over much larger areas than most LDAP administrators are currently administering, with delegation within those areas. eg "Allow printer administers to administer printers within this part of the tree" is easily understood. If it turns out that a different set of permissions should be granted with respect to color printers, then they are entries with a different type of behaviour from other printers and should have their own object class, even if they don't need extra attributes. If they do not need recognition in the common schema applicable organization wide as a distinct type of entry, then any variations in types of access control should be local to the particular part of the tree that perceives the need for this. Authority over types of access control should not be delegated unless one is also willing to delegate authority over schema. Delegation is rapidly moving down to end users and lower level administrators need a clear and stable conceptual framework. If its really inconvenient, lower level administrators can ask schema administrators to define a new object class. The standards do not prevent them tagging entries with auxiliary object classes once those classes have been defined, but only from introducing new ones without coordination. An implementation might make such tagging unnecessarily "manual", but that it is not a standards problem. The goal here is to reduce variation in conceptual framework, not facilitate it. General filters are intended to, and would succeed in, enabling easy ad hoc changes to the conceptual framework for administering access controls. If that was desirable, then general filters would be desirable. As it is undesirable, they are a bad idea. 3. I suspect that the interaction between general filters, permissions and priorities is likely to not be well understood, and result in errors when people are given permission to change an attribute value without understanding that this will have side effects on access controls. 4. Even with atomicity, I don't think its going to be at all easy to cope with the interactions between ACI and replication. My error regarding structural object classes may have resulted from wishful thinking, since it will be even harder to cope, given that an object can move in and out of a DACD as a result of a change in its auxiliary object classes. But at least that only adds one kind of replicated change to worry about, on top of changes to entry and prescriptive ACI themselves (not to mention group membership and changes in distinguished name prefixes that can also affect access controls). Adding potential surprises in permissions resulting from unsynchronized replication of other attribute values would not be helpful. In earlier discussions on the LDUP list it was recognized that this problem of entries moving in and out of the scope of a filter made it undesirable to allow general filters for specifying fractional replicated areas. 5. Its clear that there is a strong reluctance to introduce proper subentries at all, despite their obvious necessity for ACI, which goes far beyond what is immediately needed for LDUP. I would rather see a successful quick resolution by acceptance of existing standards for subentries, or a viable subset of them, than a protracted delay in achieving any reasonable support for ACI at all. (The arguments raised against the current draft by others already establish that at least some specification of the base and a filter on object class will be necessary before final call. Adding chop specifications does not really complicate implementation much, whereas general filters still does to at least some extent, and would therefore increase the resistance and consequently the delay for accepting the necessity for having proper subentries). BTW If the reference to manual maintenance of tagging below means that your customers *want* the DACD applicable to an entry to change dynamically with the ordinary contents of the entry, and you are having to change the object classes in synchronization with other changes to the entry, then I can only suggest seeking more sensible customers ;-) I have assumed above that you were only referring to the manual difficulties of tagging entries when the customer's conceptual framework changes, not when the entries change. Implementation tools should allow administrators to apply a general filter to re-tag entries, without a need for standardization. A standard DUA should be able to do that just by scripting to apply the change desired to each entry within the scope of the filter. If standards were required for directory operations that apply to more than entry, they would be be for more general changes, not just in relation to access controls. Seeya, Albert [original below] > [Robert] > Albert, doesn't an entry know the other attributes that it > contains as well > and so could evaluate an arbitrary filter ? > [Albert] > Sorry, I should have said "the (structural) object class of > an entry is > fixed and therefore the set of applicable subentries does not > need to be > recalculated on every search". With general filters such a > calculation would > be needed on every search, for every subentry that has a > parent within the > base of the search applied to every entry within the scope of > the search. > This is multiplying the cost of a search by the number of potentially > applicable subentries (not just the number of actually applicable > subentries). [Steven] The specificationFilter of a SubtreeSpecification applies to the objectClass attribute rather than the structuralObjectClass. Since the objectClass can contain optional auxiliary object classes that come and go, a conformant X.500 implementation already has to deal with the situation where the set of applicable subentries changes. Some of our customers need to be able to set access controls based on the non-objectClass attributes of the entry. The way we have achieved this with X.500 basic access control is to define an auxiliary object class, with no mandatory or optional attributes, that we use to tag entries satisfying an implied filter on the entry contents. SubtreeSpecifications then reference the auxiliary class in their specificationFilters. The auxiliary class tagging has to be maintained manually. Being able to filter on arbitrary entry contents in the specificationFilter would be better. [snip] > > Please send or CC any comments to LDUP as I won't see them in LDAP-EXT. > > Seeya, Albert Regards, Steven From list@netscape.com Mon Jul 17 10:32:04 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03366 for ; Mon, 17 Jul 2000 10:32:04 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6HEM3R11170; Mon, 17 Jul 2000 07:22:03 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6HEUaw16078; Mon, 17 Jul 2000 07:30:36 -0700 (PDT) Resent-Date: Mon, 17 Jul 2000 07:30:36 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com, ietf-ldup@imc.org Date: Mon, 17 Jul 2000 15:29:37 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: LDAPv3bis BOF at IETF#48 Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <39732661.15578.1784E6F@localhost> Priority: normal In-reply-to: <4.3.2.7.0.20000714135237.00b8b1e0@infidel.boolean.net> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"0M-O0B.A.36D.Kixc5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date forwarded: Fri, 14 Jul 2000 14:07:07 -0700 (PDT) Date sent: Fri, 14 Jul 2000 14:06:58 -0700 To: ietf-ldapext@netscape.com, ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LDAPv3bis BOF at IETF#48 Forwarded by: ietf-ldapext@netscape.com > The following BOF has been approved and should be scheduled > soon. Those interested are encouraged to participate. > > Please note that we are only collecting suggested changes. > This will be used as an aid in identifying items needing to > be worked and to develop more concrete proposals. > > Below is the draft agenda for this BOF. If you like to > propose additional agenda items, please drop Bob and I a > note. Kurt the following document may be in Mark's list of 75+ other changes. If not can you please include it in the agenda Ta David > > Regards, Kurt > > > > Name: LDAPv3bis > > Chairs: > Kurt Zeilenga > RL "Bob" Morgan > > Mailing list: > ietf-ldapv3bis@OpenLDAP.org > http://www.openldap.org/lists/ietf-ldapv3bis/ > > Introduction: > LDAPv3 core specifications (RFC 2251-56) must be revised if > they are to be progressed to Draft Standard per the IESG > Notice contained within these documents. With the approval > of RFC 2829 and 2830, the necessary secure authentication > mechanisms to obtain Draft Standard status have now available. > > In addition, the community has obtain a wealth of operational > experience using the current specifications. The community > has identified a number of areas where the specifications > need to amended. These amendments include a few significant > substantive changes, a fair number of lessor substantive changes, > and many clarifications. A forum for discussing and addressing > these issues is needed. > > Purpose: > The purpose of this BOF is to discuss proposed updates to the > LDAPv3 core protocol specification (RFC 2251-56, 2829-30), > to identify work items, and discuss formation of a working > group specifically chartered to address identified work items. > > Extensions to LDAPv3 are not within the scope of this BOF > as this is the realm of existing IETF working groups. > > Background: > The LDAPv3 specifications were developed by the ASID and > LDAPext working groups. The ASID working group is defunct. > The LDAPext WG is focused on significant protocol extensions > such as Access Control, APIs, Referrals, and CLDAP. A separate > working group is currently proposed to focus energies to address > LDAPv3 specification updates while not distracting LDAPext from > their chartered work. However, at the discretion of the IESG, work > items identified by this BOF may be assigned to LDAPext or other > appropriate WG (after appropriate charter review). > > Agenda: > Agenda Review > Introduction > Discuss IESG Note > Discuss LDAPv3 Applicability Statement > Discuss incorporation of rescodes I-D into 2251bis > Discuss incorporation of partial responses I-D into 2251bis > Discuss reorganization of specification > Discuss Mark Wahl's 75+ odd changes > Discuss Kurt Zeilenga's 75+ odd changes > Discuss relationship to X.500 issues > Discuss other issues > Discuss working group formation issues > > RFC to be discussed: > 2251-2256, 2829-2830 > > I-D to be discussed: > draft-hodges-ldapv3-as-00.txt > draft-just-ldapv3-rescodes-02.txt > draft-rharrison-ldap-extpartresp-01.txt > draft-wahl-ldapv3bis-*.txt (to be issued) > draft-zeilenga-ldapv3bis-*.txt > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Mon Jul 17 15:51:05 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07566 for ; Mon, 17 Jul 2000 15:51:04 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6HJeaR25336; Mon, 17 Jul 2000 12:40:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6HJn8E15791; Mon, 17 Jul 2000 12:49:08 -0700 (PDT) Resent-Date: Mon, 17 Jul 2000 12:49:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4408.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01BFF027.FB9D1AD2" Subject: Discovering LDAP Services with DNS - draft-ietf-ldapext-locate-03.txt Date: Mon, 17 Jul 2000 12:48:30 -0700 Message-ID: <96BABA22ECEAEA45B53D08D63E1B5678527F97@DF-SPIKE.platinum.corp.microsoft.com> Thread-Topic: Result Message for LDAP Controls - draft-armijo-ldap-control-error-00.txt Thread-Index: Ab/tu0uYKtTUnEHrQ7alj95bcWtTBAAAcU9QAJpnZwA= From: "Michael Armijo" To: X-OriginalArrivalTime: 17 Jul 2000 19:48:22.0457 (UTC) FILETIME=[F6CB4290:01BFF027] Resent-Message-ID: <"VDRmuD.A.a2D.zM2c5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multi-part message in MIME format. ------_=_NextPart_001_01BFF027.FB9D1AD2 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01BFF027.FB9D1AD2" ------_=_NextPart_002_01BFF027.FB9D1AD2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The Locate draft has been updated and sent to Internet-Drafts based on comments from LDAPEXT. Changes include: Sample of conversion from DN to fully qualified DNS name. Additional definition of ------_=_NextPart_002_01BFF027.FB9D1AD2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Discovering LDAP Services with DNS - = draft-ietf-ldapext-locate-03.txt

The Locate draft has been updated and sent to = Internet-Drafts based on comments from LDAPEXT.

Changes include:
Sample of conversion from DN to fully qualified DNS = name.
Additional definition of <proto>

------_=_NextPart_002_01BFF027.FB9D1AD2-- ------_=_NextPart_001_01BFF027.FB9D1AD2 Content-Type: text/plain; name="draft-ietf-ldapext-locate-03.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-ldapext-locate-03.txt Content-Disposition: attachment; filename="draft-ietf-ldapext-locate-03.txt" Content-Transfer-Encoding: base64 SU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1p Y2hhZWwgUC4gQXJtaWpvDQo8ZHJhZnQtaWV0Zi1sZGFwZXh0LWxvY2F0ZS0wMy50eHQ+ICAgICAg ICAgICAgICAgICAgICAgICAgICBMZXZvbiBFc2lib3YNCkp1bHksIDIwMDAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUGF1bCBMZWFjaA0KRXhwaXJl czogSmFudWFyeSwgMjAwMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWljcm9zb2Z0IENv cnBvcmF0aW9uDQoJCQkJCQkJICAgICBSLkwuIE1vcmdhbg0KCQkJCQkJVW5pdmVyc2l0eSBvZiBX YXNoaW5ndG9uDQoNCiAgICAgICAgICAgICAgICBEaXNjb3ZlcmluZyBMREFQIFNlcnZpY2VzIHdp dGggRE5TDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJ bnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoDQogICBhbGwgcHJv dmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuDQoNCiAgIEludGVybmV0LURyYWZ0cyBh cmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNr IEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0 aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50 cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0 IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LSBEcmFm dHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBh cyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQt RHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFp ZC1hYnN0cmFjdHMudHh0DQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBE aXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwuDQoNCiAgIERpc3RyaWJ1dGlvbiBvZiB0aGlzIG1lbW8gaXMgdW5saW1pdGVkLiAg SXQgaXMgZmlsZWQgYXMgPGRyYWZ0LQ0KICAgaWV0Zi1sZGFwZXh0LWxvY2F0ZS0wMy50eHQ+LCBh bmQgZXhwaXJlcyBvbiBKYW51YXJ5IDE0LCAyMDAxLiAgDQogICBQbGVhc2Ugc2VuZCBjb21tZW50 cyB0byB0aGUgYXV0aG9ycy4NCg0KDQoxLiBBYnN0cmFjdA0KDQogICBBIExpZ2h0d2VpZ2h0IERp cmVjdG9yeSBBY2Nlc3MgUHJvdG9jb2wgKExEQVApIHJlcXVlc3QgbXVzdCBiZQ0KICAgZGlyZWN0 ZWQgdG8gYW4gYXBwcm9wcmlhdGUgc2VydmVyIGZvciBwcm9jZXNzaW5nLiAgVGhpcyBkb2N1bWVu dA0KICAgc3BlY2lmaWVzIGEgbWV0aG9kIGZvciBkaXNjb3ZlcmluZyBzdWNoIHNlcnZlcnMgdXNp bmcgaW5mb3JtYXRpb24gaW4NCiAgIHRoZSBEb21haW4gTmFtZSBTeXN0ZW0uIA0KDQoNCjIuIElu dHJvZHVjdGlvbg0KDQogICBUaGUgTERBUHYzIHByb3RvY29sIFsxXSBpcyBkZXNpZ25lZCB0byBi ZSBhIGxpZ2h0d2VpZ2h0IGFjY2Vzcw0KICAgcHJvdG9jb2wgZm9yIGRpcmVjdG9yeSBzZXJ2aWNl cyBzdXBwb3J0aW5nIFguNTAwIG1vZGVscy4gIEFzIGENCiAgIGRpc3RyaWJ1dGVkIGRpcmVjdG9y eSBzZXJ2aWNlLCB0aGUgY29tcGxldGUgc2V0IG9mIGRpcmVjdG9yeQ0KICAgaW5mb3JtYXRpb24g KGtub3duIGFzIHRoZSBEaXJlY3RvcnkgSW5mb3JtYXRpb24gQmFzZSkgaXMgc3ByZWFkDQogICBh Y3Jvc3MgbWFueSBkaWZmZXJlbnQgc2VydmVycy4gIEhlbmNlIHRoZXJlIGlzIHRoZSBuZWVkIHRv DQogICBkZXRlcm1pbmUsIHdoZW4gaW5pdGlhdGluZyBvciBwcm9jZXNzaW5nIGEgcmVxdWVzdCwg d2hpY2ggc2VydmVycw0KICAgaG9sZCB0aGUgcmVsZXZhbnQgaW5mb3JtYXRpb24uICBJbiBMREFQ LCB0aGUgU2VhcmNoLCBNb2RpZnksIEFkZCwNCiAgIERlbGV0ZSwgTW9kaWZ5RE4sIGFuZCBDb21w YXJlIG9wZXJhdGlvbnMgYWxsIHNwZWNpZnkgYSBEaXN0aW5ndWlzaGVkDQogICBOYW1lIChETikg WzJdIG9uIHdoaWNoIHRoZSBvcGVyYXRpb24gaXMgcGVyZm9ybWVkLiAgQSBjbGllbnQsIG9yIGEN CiAgIHNlcnZlciBhY3Rpbmcgb24gYmVoYWxmIG9mIGEgY2xpZW50LCBtdXN0IGJlIGFibGUgdG8g ZGV0ZXJtaW5lIHRoZQ0KICAgc2VydmVyKHMpIHRoYXQgaG9sZCB0aGUgbmFtaW5nIGNvbnRleHQg Y29udGFpbmluZyB0aGF0IEROLCBzaW5jZQ0KICAgdGhhdCBzZXJ2ZXIgKG9yIG9uZSBvZiB0aGF0 IHNldCBvZiBzZXJ2ZXJzKSBtdXN0IHJlY2VpdmUgYW5kIHByb2Nlc3MNCiAgIHRoZSByZXF1ZXN0 LiAgVGhpcyBkZXRlcm1pbmF0aW9uIHByb2Nlc3MgaXMgY2FsbGVkICJzZXJ2ZXINCiAgIGxvY2F0 aW9uIi4gIFRvIHN1cHBvcnQgZHluYW1pYyBkaXN0cmlidXRlZCBvcGVyYXRpb24sIHRoZQ0KICAg aW5mb3JtYXRpb24gbmVlZGVkIHRvIHN1cHBvcnQgc2VydmVyIGxvY2F0aW9uIG11c3QgYmUgYXZh aWxhYmxlIHZpYQ0KICAgbG9va3VwcyBkb25lIGF0IHJlcXVlc3QgcHJvY2Vzc2luZyB0aW1lLCBy YXRoZXIgdGhhbiwgZm9yIGV4YW1wbGUsDQogICBhcyBzdGF0aWMgZGF0YSBjb25maWd1cmVkIGlu dG8gZWFjaCBjbGllbnQgb3Igc2VydmVyLg0KDQogICBJdCBpcyBwb3NzaWJsZSB0byBtYWludGFp biB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIHRvIHN1cHBvcnQgc2VydmVyDQogICBsb2NhdGlvbiBp biB0aGUgZGlyZWN0b3J5IGl0c2VsZiwgYW5kIFguNTAwIGRpcmVjdG9yeSBkZXBsb3ltZW50cw0K ICAgdHlwaWNhbGx5IGRvIHNvLiAgSW4gcHJhY3RpY2UsIGhvd2V2ZXIsIHRoaXMgb25seSBwZXJt aXRzIGxvY2F0aW9uDQogICBvZiBzZXJ2ZXJzIHdpdGhpbiBhIGxpbWl0ZWQgWC41MDAtY29ubmVj dGVkIHNldC4gIExEQVAtc3BlY2lmaWMNCiAgIG1ldGhvZHMgb2YgbWFpbnRhaW5pbmcgc2VydmVy IGxvY2F0aW9uIGluZm9ybWF0aW9uIGluIHRoZSBkaXJlY3RvcnkNCiAgIGhhdmUgbm90IHlldCBi ZWVuIHN0YW5kYXJkaXplZC4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbg0KICAgYWx0ZXJuYXRp dmUgbWV0aG9kIG9mIG1hbmFnaW5nIHNlcnZlciBsb2NhdGlvbiBpbmZvcm1hdGlvbiB1c2luZyB0 aGUNCiAgIERvbWFpbiBOYW1lIFN5c3RlbS4gVGhpcyBtZXRob2QgdGFrZXMgYWR2YW50YWdlIG9m IHRoZSBnbG9iYWwNCiAgIGRlcGxveW1lbnQgb2YgdGhlIEROUywgYnkgYWxsb3dpbmcgTERBUCBz ZXJ2ZXIgbG9jYXRpb24gaW5mb3JtYXRpb24NCiAgIGZvciBhbnkgZXhpc3RpbmcgRE5TIGRvbWFp biB0byBiZSBwdWJsaXNoZWQgYnkgY3JlYXRpbmcgdGhlIHJlY29yZHMNCiAgIGRlc2NyaWJlZCBi ZWxvdy4gIEEgZnVsbCBkaXNjdXNzaW9uIG9mIHRoZSBiZW5lZml0cyBhbmQgZHJhd2JhY2tzIG9m DQogICB0aGUgdmFyaW91cyBkaXJlY3RvcnkgbG9jYXRpb24gYW5kIG5hbWluZyBtZXRob2RzIGlz IGJleW9uZCB0aGUNCiAgIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIFJGQyAyMjQ3WzNd IGRlZmluZXMgYW4gYWxnb3JpdGhtIGZvciBtYXBwaW5nIEROUyBkb21haW4gbmFtZXMgaW50bw0K ICAgRE5zLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBpbnZlcnNlIG1hcHBpbmcsIGZyb20g RE5zIHRvIEROUw0KICAgZG9tYWluIG5hbWVzLCBiYXNlZCBvbiB0aGUgY29udmVudGlvbnMgaW4g WzNdLCBmb3IgdXNlIGluIHRoaXMNCiAgIHNlcnZlciBsb2NhdGlvbiBtZXRob2QuICBUaGUgc2Vy dmVyIGxvY2F0aW9uIG1ldGhvZCBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQgaXMgb25s eSBkZWZpbmVkIGZvciBETnMgdGhhdCBjYW4gYmUgc28gbWFwcGVkLCBpLmUuLA0KICAgdGhvc2Ug RE5zIHRoYXQgYXJlIGJhc2VkIG9uIGRvbWFpbiBuYW1lcy4gIEluIHByYWN0aWNlIHRoaXMgaXMN CiAgIHJlYXNvbmFibGUgYmVjYXVzZSBtYW55IG9iamVjdHMgb2YgaW50ZXJlc3QgYXJlIG5hbWVk IHdpdGggZG9tYWluDQogICBuYW1lcywgYW5kIHVzZSBvZiBkb21haW4tbmFtZS1iYXNlZCBETnMg aXMgYmVjb21pbmcgY29tbW9uLg0KDQoNCjMuIE1hcHBpbmcgRGlzdGluZ3Vpc2hlZCBOYW1lcyBp bnRvIERvbWFpbiBOYW1lcw0KDQogICBUaGlzIHNlY3Rpb24gZGVmaW5lcyBhIG1ldGhvZCBvZiBj b252ZXJ0aW5nIGEgRE4gaW50byBhIEROUyBkb21haW4NCiAgIG5hbWUgZm9yIHVzZSBpbiB0aGUg c2VydmVyIGxvY2F0aW9uIG1ldGhvZCBkZXNjcmliZWQgYmVsb3cuICBTb21lDQogICBETnMgY2Fu bm90IGJlIGNvbnZlcnRlZCBpbnRvIGEgZG9tYWluIG5hbWUuICBDb252ZXJ0ZWQgRE5zIHJlc3Vs dCANCiAgIGluIGEgZnVsbHkgcXVhbGlmaWVkIGRvbWFpbiBuYW1lLg0KDQogICBUaGUgb3V0cHV0 IGRvbWFpbiBuYW1lIGlzIGluaXRpYWxseSBlbXB0eS4gIEZvciBlYWNoIFJETiBjb21wb25lbnQN CiAgIG9mIHRoZSBETiwgYmVnaW5uaW5nIHdpdGggdGhlIHJpZ2h0bW9zdCBhbmQgd29ya2luZyBs ZWZ0LCBpZiB0aGUgDQogICBhdHRyaWJ1dGUgdHlwZSBpcyAiREMiLCB0aGVuIHRoZSBhdHRyaWJ1 dGUgdmFsdWUgaXMgdXNlZCBhcyBhIGRvbWFpbiANCiAgIG5hbWUgY29tcG9uZW50IChsYWJlbCku DQogICBUaGUgZmlyc3Qgc3VjaCB2YWx1ZSBiZWNvbWVzIHRoZSBtb3N0IHNpZ25pZmljYW50IChp LmUuLCByaWdodG1vc3QpDQogICBkb21haW4gbmFtZSBjb21wb25lbnQsIGFuZCBzdWNjZXNzaXZl IHZhbHVlcyBvY2N1cHkgbGVzcyBzaWduaWZpY2FudA0KICAgcG9zaXRpb25zIChpLmUuLCBleHRl bmRpbmcgbGVmdHdhcmQpLCBpbiBvcmRlci4gIElmIHRoZSBhdHRyaWJ1dGUNCiAgIHR5cGUgaXMg bm90ICJEQyIsIHRoZW4gcHJvY2Vzc2luZyBzdG9wcy4gIElmIHRoZSBmaW5hbCBSRE4gY29tcG9u ZW50DQogICBvZiB0aGUgRE4gaXMgbm90IG9mIHR5cGUgIkRDIiB0aGVuIHRoZSBETiBjYW5ub3Qg YmUgY29udmVydGVkIHRvIGENCiAgIGRvbWFpbiBuYW1lLiANCg0KICAgRm9yIEROOg0KDQogICBj bj1Kb2huIERvZSxvdT1hY2NvdW50aW5nLGRjPWV4YW1wbGUsZGM9bmV0DQoNCiAgIFRoZSBjbGll bnQgd291bGQgY29udmVydCB0aGUgREMgY29tcG9uZW50cyBhcyBkZWZpbmVkIGFib3ZlIGludG8g DQogICBETlMgbmFtZToNCg0KICAgZXhhbXBsZS5uZXQuDQoNCiAgIFRoZSBkZXRlcm1pbmVkIERO UyBuYW1lIHdpbGwgYmUgc3VibWl0dGVkIGFzIGEgRE5TIHF1ZXJ5IHVzaW5nIHRoZSANCiAgIGFs Z29yaXRobSBkZWZpbmVkIGluIHNlY3Rpb24gNC4NCg0KDQo0LiBMb2NhdGluZyBMREFQIHNlcnZl cnMgdGhyb3VnaCBETlMNCg0KICAgTERBUCBzZXJ2ZXIgbG9jYXRpb24gaW5mb3JtYXRpb24gaXMg dG8gYmUgc3RvcmVkIHVzaW5nIEROUyBTZXJ2aWNlDQogICBMb2NhdGlvbiBSZWNvcmQgKFNSVilb NV0uICBUaGUgZGF0YSBpbiBhIFNSViByZWNvcmQgY29udGFpbnMgdGhlIEROUw0KICAgbmFtZSBv ZiB0aGUgc2VydmVyIHRoYXQgcHJvdmlkZXMgdGhlIExEQVAgc2VydmljZSwgY29ycmVzcG9uZGlu Zw0KICAgUG9ydCBudW1iZXIsIGFuZCBwYXJhbWV0ZXJzIHRoYXQgZW5hYmxlIHRoZSBjbGllbnQg dG8gY2hvb3NlIGFuDQogICBhcHByb3ByaWF0ZSBzZXJ2ZXIgZnJvbSBtdWx0aXBsZSBzZXJ2ZXJz IGFjY29yZGluZyB0byB0aGUgYWxnb3JpdGhtDQogICBkZXNjcmliZWQgaW4gWzVdLiAgVGhlIG5h bWUgb2YgdGhpcyByZWNvcmQgaGFzIHRoZSBmb2xsb3dpbmcgZm9ybWF0Og0KDQogICAgICBfPFNl cnZpY2U+Ll88UHJvdG8+LjxEb21haW4+DQoNCiAgIHdoZXJlIDxTZXJ2aWNlPiBpcyBhbHdheXMg ImxkYXAiLCBhbmQgPFByb3RvPiBpcyBhIHByb3RvY29sIHRoYXQgY2FuDQogICBiZSBlaXRoZXIg InVkcCIgb3IgInRjcCIuICAiX2xkYXAuX3RjcCIgYXBwbGllcyB0byBzZXJ2aWNlcyANCiAgIGNv bXBhdGlibGUgd2l0aCBMREFQdjIgWzddIG9yIExEQVB2MyBbMV0uICAiX2xkYXAuX3VkcCIgDQog ICBhcHBsaWVzIHRvIHNlcnZpY2VzIGNvbXBhdGlibGUgd2l0aCBDTERBUCBbOF0uICA8RG9tYWlu PiBpcyANCiAgIHRoZSBkb21haW4gbmFtZSBmb3JtZWQgYnkgY29udmVydGluZyB0aGUgRE4gb2Yg YSBuYW1pbmcgY29udGV4dCANCiAgIG1hc3RlcmVkIGJ5IHRoZSBMREFQIFNlcnZlciBpbnRvIGEg ZG9tYWluIG5hbWUgdXNpbmcgdGhlIGFsZ29yaXRobSBpbiANCiAgIFNlY3Rpb24gMy4gIE5vdGUg dGhhdCAibGRhcCIgaXMgdGhlIHN5bWJvbGljIG5hbWUgZm9yIHRoZSBMREFQIHNlcnZpY2UgDQog ICBpbiBBc3NpZ25lZCBOdW1iZXJzWzZdLCBhcyByZXF1aXJlZCBieSBbNV0uDQoNCiAgIFByZXNl bmNlIG9mIHN1Y2ggcmVjb3JkcyBlbmFibGVzIGNsaWVudHMgdG8gZmluZCB0aGUgTERBUCBzZXJ2 ZXJzDQogICB1c2luZyBzdGFuZGFyZCBETlMgcXVlcnkgWzRdLiAgQSBjbGllbnQgKG9yIHNlcnZl cikgc2Vla2luZyBhbiBMREFQDQogICBzZXJ2ZXIgZm9yIGEgcGFydGljdWxhciBETiBjb252ZXJ0 cyB0aGF0IEROIHRvIGEgZG9tYWluIG5hbWUgdXNpbmcNCiAgIHRoZSBhbGdvcml0aG0gb2YgU2Vj dGlvbiAyLCBkb2VzIGEgU1JWIHJlY29yZCBxdWVyeSB1c2luZyB0aGUgRE5TDQogICBuYW1lIGZv cm1lZCBhcyBkZXNjcmliZWQgaW4gdGhlIHByZWNlZGluZyBwYXJhZ3JhcGgsIGFuZCBpbnRlcnBy ZXRzDQogICB0aGUgcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluIFs1XSB0byBkZXRlcm1pbmUgYSBo b3N0IChvciBob3N0cykgdG8NCiAgIGNvbnRhY3QuIEFzIGFuIGV4YW1wbGUsIGEgY2xpZW50IHRo YXQgc2VhcmNoZXMgZm9yIGFuIExEQVAgc2VydmVyDQogICBmb3IgdGhlIEROICJvdT1mb28sZGM9 ZXhhbXBsZSxkYz1uZXQiIHRoYXQgc3VwcG9ydHMgdGhlIFRDUCBwcm90b2NvbA0KICAgd2lsbCBz dWJtaXQgYSBETlMgcXVlcnkgZm9yIGEgc2V0IG9mIFNSViByZWNvcmRzIHdpdGggb3duZXIgbmFt ZToNCg0KICAgICAgX2xkYXAuX3RjcC5leGFtcGxlLm5ldC4NCg0KICAgVGhlIGNsaWVudCB3aWxs IHJlY2VpdmUgdGhlIGxpc3Qgb2YgU1JWIHJlY29yZHMgcHVibGlzaGVkIGluIEROUw0KICAgdGhh dCBzYXRpc2Z5IHRoZSByZXF1ZXN0ZWQgY3JpdGVyaWEuICBUaGUgZm9sbG93aW5nIGlzIGFuIGV4 YW1wbGUgb2YNCiAgIHN1Y2ggYSByZWNvcmQ6DQoNCiAgICAgIF9sZGFwLl90Y3AuZXhhbXBsZS5u ZXQuICAgSU4JICBTUlYgIDAgMCAzODkgcGhvZW5peC5leGFtcGxlLm5ldC4NCg0KICAgVGhlIHNl dCBvZiByZXR1cm5lZCByZWNvcmRzIG1heSBjb250YWluIG11bHRpcGxlIHJlY29yZHMgaW4gdGhl IGNhc2UNCiAgIHdoZXJlIG11bHRpcGxlIExEQVAgc2VydmVycyBzZXJ2ZSB0aGUgc2FtZSBkb21h aW4uICBJZiB0aGVyZSBhcmUgbm8gDQogICBtYXRjaGluZyBTUlYgcmVjb3JkcyBhdmFpbGFibGUg Zm9yIHRoZSBjb252ZXJ0ZWQgRE4gdGhlIGNsaWVudCBTSE9VTEQgDQogICBOT1QgYXR0ZW1wdCB0 byAnd2FsayB0aGUgdHJlZScgYnkgcmVtb3ZpbmcgdGhlIGxlYXN0IHNpZ25pZmljYW50IA0KICAg cG9ydGlvbiBvZiB0aGUgY29uc3RydWN0ZWQgZnVsbHkgcXVhbGlmaWVkIGRvbWFpbiBuYW1lLg0K DQoNCjUuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIGEgbWV0aG9kIHRoYXQgdXNlcyBETlMgU1JWIHJlY29yZHMgdG8gDQogICBkaXNjb3ZlciBM REFQIHNlcnZlcnMuICBBbGwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgcmVsYXRlZCB0byBETlMN CiAgIFNSViByZWNvcmRzIGFyZSBpbmhlcml0ZWQgYnkgdGhpcyBkb2N1bWVudC4gIFNlZSB0aGUg c2VjdXJpdHkgDQogICBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGluIFs2XSBmb3IgbW9yZSBkZXRh aWxzLg0KDQoNCjYuIFJlZmVyZW5jZXMNCg0KICAgWzFdICBXYWhsLCBNLiwgSG93ZXMsIFQuIGFu ZCBTLiBLaWxsZSwgIkxpZ2h0d2VpZ2h0IERpcmVjdG9yeSBBY2Nlc3MNCiAgICAgICAgUHJvdG9j b2wodjMpIiwgUkZDIDIyNTEsIERlY2VtYmVyIDE5OTcuDQoNCiAgIFsyXSAgV2FobCwgTS4sIEtp bGxlLCBTLiBhbmQgVC4gSG93ZXMsICJMaWdodHdlaWdodCBEaXJlY3RvcnkgQWNjZXNzDQogICAg ICAgIFByb3RvY29sICh2Myk6ICBVVEYtOCBTdHJpbmcgUmVwcmVzZW50YXRpb24gb2YgRGlzdGlu Z3Vpc2hlZA0KICAgICAgICBOYW1lcyIsIFJGQyAyMjUzLCBEZWNlbWJlciAxOTk3Lg0KDQogICBb M10gIEtpbGxlLCBTLiBhbmQgTS4gV2FobCwgIlVzaW5nIERvbWFpbnMgaW4gTERBUC9YLjUwMA0K ICAgICAgICBEaXN0aW5ndWlzaGVkIE5hbWVzIiwgUkZDIDIyNDcsIEphbnVhcnkgMTk5OC4NCg0K ICAgWzRdICBNb2NrYXBldHJpcywgUC4sICJET01BSU4gTkFNRVMgLSBDT05DRVBUUyBBTkQgRkFD SUxJVElFUyIsIFJGQw0KICAgICAgICAxMDM0LCBTVEQgMTMsIE5vdmVtYmVyIDE5ODcuDQoNCiAg IFs1XSAgR3VsYnJhbmRzZW4sIEEuLCBWaXhpZSwgUC4gYW5kIEwuIEVzaWJvdiwgIkEgRE5TIFJS IGZvcg0KICAgICAgICBzcGVjaWZ5aW5nIHRoZSBsb2NhdGlvbiBvZiBzZXJ2aWNlcyAoRE5TIFNS VikiLCBSRkMgMjc4MiwNCiAgICAgICAgRmVicnVhcnkgMjAwMC4NCg0KICAgWzZdICBSZXlub2xk cywgSi4gYW5kIEouIFBvc3RlbCwgIkFzc2lnbmVkIE51bWJlcnMiLCBTVEQgMiwgUkZDDQogICAg ICAgIDE3MDAsIE9jdG9iZXIgMTk5NC4NCg0KICAgWzddICBZZW9uZywgVy4sIEhvd2VzLCBULiBh bmQgS2lsbGUsIFMuLCAgIkxpZ2h0d2VpZ2h0IERpcmVjdG9yeSBBY2Nlc3MgDQogICAgICAgIFBy b3RvY29sIiwgIFJGQyAxNzc3LCBNYXJjaCAxOTk1DQoNCiAgIFs4XSAgWW91bmcsIEEuLCAiQ29u bmVjdGlvbi1sZXNzIExpZ2h0d2VpZ2h0IERpcmVjdG9yeSBBY2Nlc3MgUHJvdG9jb2wiLA0KICAg ICAgICBSRkMgMTc5OCwgSnVuZSAxOTk1DQoNCg0KNy4gQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAg IE1pY2hhZWwgUC4gQXJtaWpvDQogICBPbmUgTWljcm9zb2Z0IFdheQ0KICAgUmVkbW9uZCwgV0Eg OTgwNTINCiAgIG1pY2hhcm1AbWljcm9zb2Z0LmNvbQ0KDQogICBQYXVsIExlYWNoDQogICBPbmUg TWljcm9zb2Z0IFdheQ0KICAgUmVkbW9uZCwgV0EgOTgwNTINCiAgIHBhdWxsZUBtaWNyb3NvZnQu Y29tDQoNCiAgIExldm9uIEVzaWJvdg0KICAgT25lIE1pY3Jvc29mdCBXYXkNCiAgIFJlZG1vbmQs IFdBIDk4MDUyDQogICBsZXZvbmVAbWljcm9zb2Z0LmNvbQ0KDQogICBSTCAiQm9iIiBNb3JnYW4N CiAgIFVuaXZlcnNpdHkgb2YgV2FzaGluZ3Rvbg0KICAgNDU0NSAxNXRoIEF2ZSBORQ0KICAgU2Vh dHRsZSwgV0EgIDk4MTA1DQogICBVUw0KDQogICBQaG9uZTogKzEgMjA2IDIyMSAzMzA3DQogICBF TWFpbDogcmxtb3JnYW5Ad2FzaGluZ3Rvbi5lZHUNCiAgIFVSSTogICBodHRwOi8vc3RhZmYud2Fz aGluZ3Rvbi5lZHUvcmxtb3JnYW4vDQoNCiAgIEV4cGlyZXMgSmFudWFyeSwgMjAwMQ0KDQoNCg0K ------_=_NextPart_001_01BFF027.FB9D1AD2-- From list@netscape.com Mon Jul 17 18:31:01 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22372 for ; Mon, 17 Jul 2000 18:31:00 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6HMOGU12352; Mon, 17 Jul 2000 15:24:17 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6HMQmg06164; Mon, 17 Jul 2000 15:26:48 -0700 (PDT) Resent-Date: Mon, 17 Jul 2000 15:26:48 -0700 (PDT) Message-Id: <200007172226.e6HMQew15689@xwing.netscape.com> From: zasebno@yahoo.com To: ietf-ldapext@netscape.com Subject: New Virus Alert! Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 18 Jul 2000 00:23:46 Resent-Message-ID: <"XpmYSB.A.beB.kg4c5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Disclaimer at the end of this message! Gentlemen! This is our anti-spam virus vaccinisation. Please help! Your e-mail has found its way to our address book as our paths crossed somewhere in the near past. We offer a variety of free services as well as entertainment, shopping experiences, learning and business opportunities, what you can check at: http://www.free-sites-for-free-offers.com http://hotyellowlinks.com/davorin http://marketerzdream.com/ffa/cihsar/index.html http://www.davorin.com/ http://www.knowledgefarmer.com/ http://www.makeithappenonthenet.com/ From time to time (once or twice a week) we post information on different useful products and services (mainly about free stuff, free trials and special opportunities) to our partners. We are currently cleaning our mailing list database. If you wish to narrow our information to your interest only and earn 25 $ you can do it at http://www.davorin.com/coinfreesurvey.html . If you don’t want to receive future mailings from us just send blank e-mail to remove@davorin.net . If you want to block exchange of information between our domains just send us blank e-mail to block@davorin.net .(for webmasters only) To add us to your mailing list and contact us use cihsar@davorin.net . Do not reply to this address as messages will not be read by humans. Davorin Sadar, CEO Concepts International, Inc. 16835 Algonquin Street #422 Huntington Beach 92648-3852 California phone 800 264 3248 fax 775 665 8315 --------------------Disclaimer--------------------------------- Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter cannot be considered spam as long as we include: Contact information & a Remove Link From list@netscape.com Tue Jul 18 02:14:56 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06512 for ; Tue, 18 Jul 2000 02:14:55 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6I64lR11911; Mon, 17 Jul 2000 23:04:47 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6I6DKc28386; Mon, 17 Jul 2000 23:13:20 -0700 (PDT) Resent-Date: Mon, 17 Jul 2000 23:13:20 -0700 (PDT) Message-Id: <4.2.2.20000718010702.00a2c640@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 18 Jul 2000 01:13:00 -0500 To: d.w.chadwick@salford.ac.uk, ietf-ldapext-acm@openldap.org, ietf-ldapext@netscape.com From: Ellen Stokes Subject: Re: Authentication Level In-Reply-To: <39738FDB.24155.3146330@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"nNYsPD.A.36G.-V_c5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David, I agree that I need to include your point in section 4.2.4. This is a good case for how 'any' works. Thanks. Ellen At 10:59 PM 7/17/00 +0100, David Chadwick wrote: >Ellen] > >An important point about the authentication level (which I could not >find in the draft) is that for the permission to be granted the subject >must have been authenticated to at least the level specified, but that >if the right is a deny, then EVERYONE is denied access unless they >have been authenticated to at least the level specified in authnLevel. > >David > >*************************************************** > >David Chadwick >IS Institute, University of Salford, Salford M5 4WT >Tel +44 161 295 5351 Fax +44 161 745 8169 >Mobile +44 790 167 0359 >Email D.W.Chadwick@salford.ac.uk >Home Page http://www.salford.ac.uk/its024/chadwick.htm >Understanding X.500 http://www.salford.ac.uk/its024/X500.htm >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm >Entrust key validation string MLJ9-DU5T-HV8J > >*************************************************** From list@netscape.com Tue Jul 18 06:37:20 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14538 for ; Tue, 18 Jul 2000 06:37:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6IAUgU27425; Tue, 18 Jul 2000 03:30:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6IAZaU22238; Tue, 18 Jul 2000 03:35:36 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 03:35:36 -0700 (PDT) Message-Id: <200007181035.GAA13706@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-ldap-java-api-11.txt Date: Tue, 18 Jul 2000 06:35:28 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"6qqO9D.A._aF.3LDd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : The Java LDAP Application Program Interface Author(s) : R. Weltman, C. Tomlinson, M. Kekic, J. Sermersheim, M. Smith, T. Howes Filename : draft-ietf-ldapext-ldap-java-api-11.txt Pages : 121 Date : 17-Jul-00 This document defines a Java language application program interface to the lightweight directory access protocol (LDAP), in the form of a class library. It complements but does not replace RFC 1823 ([7]), which describes a C language application program interface. It updates the previous draft in correcting a few minor errors which are listed in appendix B. It also includes the asynchronous layer of the API which was previously defined in draft-ietf-ldapext-ldap-java-api- asynch [10]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-java-api-11.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapext-ldap-java-api-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapext-ldap-java-api-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000717145929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-ldap-java-api-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-ldap-java-api-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000717145929.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Tue Jul 18 06:37:35 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14686 for ; Tue, 18 Jul 2000 06:37:34 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6IAV5U27660; Tue, 18 Jul 2000 03:31:06 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6IAZxY22744; Tue, 18 Jul 2000 03:35:59 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 03:35:59 -0700 (PDT) Sender: Robert.Byrne@france.Sun.COM Message-ID: <397432E5.8ACCC467@france.sun.com> Date: Tue, 18 Jul 2000 12:35:17 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: d.w.chadwick@salford.ac.uk CC: ietf-ldapext-acm@openldap.org, ietf-ldapext@netscape.com Subject: Re: Suggestion for scope of ACI References: <3973746A.6703.2A92F20@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"lY4E5C.A.uiF.NMDd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit David Chadwick wrote: > Ellen and co. > > I have a suggestion to make for the scope of ldapACI attributes. > > Remove it, and replace it with 2 attribute types: EntryACI and > SubtreeACI. This simplifies the syntax of the attribute values by > removing the first element, but more importantly, it allows you to > have separation of responsibilities. Because we do not have > attribute value level ACI, then we currently have no way of allowing > different people to administer entry aci and subtree aci, since they > are attribute values in the same attribute. But by having two > attribute types we can can give permissions to different people to > adminster the different tattribute types. > > The functionality remains exactly the same as now, and both > attributes will have the same syntax, but different semantics will be > applied to them, one having the existing meaning of entry scope, the > other the existing meaning of subentry scope. I can see that gives more granularity but could you motivate the need for this ? What about other components of the aci, should they be exposed too ? One effect of moving this way would be to put the draft closer to being able to put acis (of both kinds) into subentries. The reason is that once you put acis into subentries, you need some way to control access to the subentries themselves, and this could be done with the entryACI. > > > A related Question. Is there a bug in the current specification (either > description or semantics). Consider this, I set a subentry scope on > ldapACI, I give add permission with a subject of "this", meaning that > I want to allow people or applications to create their own entries. > However, with the text as it now reads it seems to allow clients to > create subordinate entries beneath their own entry, as the definition > of add reads "add an entry below this entry". Is this a correct > interpretation. I would interpret it the latter way--that way it's consistent with the other operations (ie. the permission is granted to the entry defined by the bindDN (what if it's an authzID ?)). Seems like it's a choice--either it allows you to create your own entry (only interesting in the case where you bind to one server and it chains the add on to another ?) or it allows you to create entries under your own entry (only interesting in the case where your own entry already exists). We will at least clarify the meaning. > > > David > > *************************************************** > > David Chadwick > IS Institute, University of Salford, Salford M5 4WT > Tel +44 161 295 5351 Fax +44 161 745 8169 > Mobile +44 790 167 0359 > Email D.W.Chadwick@salford.ac.uk > Home Page http://www.salford.ac.uk/its024/chadwick.htm > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string MLJ9-DU5T-HV8J > > *************************************************** From list@netscape.com Tue Jul 18 08:01:32 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16018 for ; Tue, 18 Jul 2000 08:01:32 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6IBpDR22851; Tue, 18 Jul 2000 04:51:13 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6IBxlY18273; Tue, 18 Jul 2000 04:59:47 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 04:59:47 -0700 (PDT) Message-ID: From: ANTIGEN_SCHZMXS1 To: "'ietf-ldapext@netscape.com'" Subject: Antigen found VBS/LoveLetter.A-V@mm.Worm virus Date: Tue, 18 Jul 2000 13:59:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Resent-Message-ID: <"SAUadD.A.MdE.yaEd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Antigen for Exchange found LOVE-LETTER-FOR-YOU.TXT.vbs infected with VBS/LoveLetter.A-V@mm.Worm virus. The file is currently Deleted. The message, "ILOVEYOU", was sent from Nigel Ratcliffe and was discovered in Public Folders\Mail Lists\LDAP-related MLs\IETF-LDAPEXT located at Nortel Secure Networks/ENTRUST_CH/SCHZMXS1. From list@netscape.com Tue Jul 18 10:06:18 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09784 for ; Tue, 18 Jul 2000 10:06:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6IDuDR09289; Tue, 18 Jul 2000 06:56:13 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6IE4lQ20363; Tue, 18 Jul 2000 07:04:47 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 07:04:47 -0700 (PDT) X-Lotus-FromDomain: TIVOLI SYSTEMS From: Ellen_Stokes@tivoli.com To: ietf-ldapext@netscape.com, ietf-ldapext-acm@openldap.org Message-ID: <86256920.004D52DB.00@tivmta4.tivoli.com> Date: Tue, 18 Jul 2000 09:04:31 -0500 Subject: where to send comments to on draft-ietf-ldapext-acl-model-06.txt Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=rZhsUNYxDgsUtOThz3X653EhdYSTUNZzENFZZhD1gyS8nbOKlwzgs25v" Content-Disposition: inline Resent-Message-ID: <"kB5RsD.A.h9E.9PGd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --0__=rZhsUNYxDgsUtOThz3X653EhdYSTUNZzENFZZhD1gyS8nbOKlwzgs25v Content-type: text/plain; charset=us-ascii Content-Disposition: inline Folks, To comment on the access control model draft, please send your comments to the ldapext mailing list: --0__=rZhsUNYxDgsUtOThz3X653EhdYSTUNZzENFZZhD1gyS8nbOKlwzgs25v Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =A0 =A0 ietf-ldapext@netscape.com and NOT to ietf-ldapext-acm@OpenLDAP.org (an interim working list that not all interested ldapEXTers have subscribed to). This will ensure all interested parties in ldapext will see and be able= to repsond to comments. Ellen = --0__=rZhsUNYxDgsUtOThz3X653EhdYSTUNZzENFZZhD1gyS8nbOKlwzgs25v-- From list@netscape.com Tue Jul 18 10:13:10 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12899 for ; Tue, 18 Jul 2000 10:13:10 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6IE3BR10773; Tue, 18 Jul 2000 07:03:11 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6IEBjw25343; Tue, 18 Jul 2000 07:11:45 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 07:11:45 -0700 (PDT) X-Lotus-FromDomain: TIVOLI SYSTEMS From: Ellen_Stokes@tivoli.com To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com Message-ID: <86256920.004DF474.00@tivmta4.tivoli.com> Date: Tue, 18 Jul 2000 09:11:25 -0500 Subject: Re: Typos, bugs, clarifications for ACI draft Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=tJDDabYaqPWRA0TMoq8pRAv3wVcGc2U79ZmEqDXDOdmxvkTyVBXHCvME" Content-Disposition: inline Resent-Message-ID: <"eigrWB.A._KG.eWGd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --0__=tJDDabYaqPWRA0TMoq8pRAv3wVcGc2U79ZmEqDXDOdmxvkTyVBXHCvME Content-type: text/plain; charset=us-ascii Content-Disposition: inline resending... David, At 10:59 PM 7/17/00 +0100, David Chadwick wrote: Ellen could you clarify a few points for me please i) section 2 says the draft is neutral with respect to implicit vs explicit denials, then says in 4.3 deny is the default when there is no access control information. These statements seem to be in conflict. (EJS) The neutrality statement in section 2 refers to whether you deny by granting no rights (implicit) or you provide a deny verb in the ACI to explicitly deny rights. --0__=tJDDabYaqPWRA0TMoq8pRAv3wVcGc2U79ZmEqDXDOdmxvkTyVBXHCvME Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =A0 We've chosen to allow either. Also, if I remember from email many months ago, there was discussion of what the ACI is when no ACI is explicitly defined at the root of the DIT held by a server - and the rough consensus was 'default is deny'. ii) 4.3 precedence of subjects has public in the bottom 2 levels and this in the middle two levels. Can you explain this to me please. (EJS) will respond in separate email iii) delete this entry permission. What happens if the entry has subordinates. Are permissions needed for the subordinates or not. The text is mute on this point, although it does mention that no permissions are needed on attributes in the entry. (EJS)=A0 The intent here was to provide the same semantic as X.500. However, I think we may have missed the point you mention about subordinates.=A0 It seems to me that if you the entry you're deleting is a leaf entry, then no problem.=A0 If there are subordinates, then you can't just delete an entry in the middle of the DIT, but also need permisison to delete each subordinate.=A0 What does X.500 do? iv) add is permission for below an entry, but import appears not to be ("permissions at the source location", not "below the source location"). I dont think it is helpful to have different rules here (or= different text). Can we be consistent please as adding or importing seem to be very similar in where the new entries are placed. (EJS) will respond in separate email v) bottom of 4.2.2, example of subtree#grant. If the grant list is empty, why does this mean deny all?? See also comment i) above. (EJS)=A0 No rights are granted and no rights means deny (see i) respons= e) vi) section 4.2.4, Can you add text after role and ipAddress to say what these mean (all the other subjects have some). (EJS) Oops.=A0 Here's the proposed text: ipAddress - defined as IP Address in dotted decimal form or domain =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 name; wildcar= ds allowed (see BNF) role - =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 ---I'll have to think about the text some more= for this one vii) section 4.3, step 2. what does 'this may also be combined with group to use the power of "this"' mean. Sorry to be dumb. (EJS) will respond in separate email David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351=A0 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page=A0 http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500=A0 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** = --0__=tJDDabYaqPWRA0TMoq8pRAv3wVcGc2U79ZmEqDXDOdmxvkTyVBXHCvME-- From list@netscape.com Tue Jul 18 11:20:29 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16056 for ; Tue, 18 Jul 2000 11:20:26 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6IFA7R22057; Tue, 18 Jul 2000 08:10:08 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6IFIgM14838; Tue, 18 Jul 2000 08:18:42 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 08:18:42 -0700 (PDT) Message-Id: <4.2.2.20000718014644.00a29ae0@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 18 Jul 2000 02:23:49 -0500 To: d.w.chadwick@salford.ac.uk, ietf-ldapext-acm@openldap.org, ietf-ldapext@netscape.com From: Ellen Stokes Subject: Re: Typos, bugs, clarifications for ACI draft (i, iii, v, vi) In-Reply-To: <39738FDB.3106.3146556@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"P4g8jC.A.dnD.QVHd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David, At 10:59 PM 7/17/00 +0100, David Chadwick wrote: >Ellen > >could you clarify a few points for me please > >i) section 2 says the draft is neutral with respect to implicit vs >explicit denials, then says in 4.3 deny is the default when there is no >access control information. These statements seem to be in conflict. (EJS) The neutrality statement in section 2 refers to whether you deny by granting no rights (implicit) or you provide a deny verb in the ACI to explicitly deny rights. We've chosen to allow either. Also, if I remember from email many months ago, there was discussion of what the ACI is when no ACI is explicitly defined at the root of the DIT held by a server - and the rough consensus was 'default is deny'. >ii) 4.3 precedence of subjects has public in the bottom 2 levels and >this in the middle two levels. Can you explain this to me please. (EJS) will respond in separate email >iii) delete this entry permission. What happens if the entry has >subordinates. Are permissions needed for the subordinates or not. >The text is mute on this point, although it does mention that no >permissions are needed on attributes in the entry. (EJS) The intent here was to provide the same semantic as X.500. However, I think we may have missed the point you mention about subordinates. It seems to me that if you the entry you're deleting is a leaf entry, then no problem. If there are subordinates, then you can't just delete an entry in the middle of the DIT, but also need permisison to delete each subordinate. What does X.500 do? >iv) add is permission for below an entry, but import appears not to >be ("permissions at the source location", not "below the source >location"). I dont think it is helpful to have different rules here (or >different text). Can we be consistent please as adding or importing >seem to be very similar in where the new entries are placed. (EJS) will respond in separate email >v) bottom of 4.2.2, example of subtree#grant. If the grant list is >empty, why does this mean deny all?? See also comment i) above. (EJS) No rights are granted and no rights means deny (see i) response) >vi) section 4.2.4, Can you add text after role and ipAddress to say >what these mean (all the other subjects have some). (EJS) Oops. Here's the proposed text: ipAddress - defined as IP Address in dotted decimal form or domain name; wildcards allowed (see BNF) role - ---I'll have to think about the text some more for this one >vii) section 4.3, step 2. what does 'this may also be combined with >group to use the power of "this"' mean. Sorry to be dumb. (EJS) will respond in separate email >David > >*************************************************** > >David Chadwick >IS Institute, University of Salford, Salford M5 4WT >Tel +44 161 295 5351 Fax +44 161 745 8169 >Mobile +44 790 167 0359 >Email D.W.Chadwick@salford.ac.uk >Home Page http://www.salford.ac.uk/its024/chadwick.htm >Understanding X.500 http://www.salford.ac.uk/its024/X500.htm >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm >Entrust key validation string MLJ9-DU5T-HV8J > >*************************************************** From list@netscape.com Tue Jul 18 11:22:57 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17322 for ; Tue, 18 Jul 2000 11:22:57 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6IFANR22202; Tue, 18 Jul 2000 08:10:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6IFIv615255; Tue, 18 Jul 2000 08:18:57 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 08:18:57 -0700 (PDT) Message-Id: <4.2.2.20000718012021.00a39210@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 18 Jul 2000 01:25:32 -0500 To: d.w.chadwick@salford.ac.uk, ietf-ldapext-acm@openldap.org, ietf-ldapext@netscape.com From: Ellen Stokes Subject: Re: ASN.1 vs BNF In-Reply-To: <39738FDB.10016.3146452@localhost> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Resent-Message-ID: <"-k6v7C.A.RtD.dVHd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David,

When the BNF / ASN.1 was rewritten, an important point was lost, that
is, in the ACI value you specify grant and deny at most once, not multiple
times.

Here's the BNF from version 05 which is correct:
          < rights > ::= "grant" + ';' + <permissions> + ';'+<attr>
             | "deny" + ';' + <permissions> + ';'+<attr> |
             "grant"+';'+<permissions>+';'+"deny"+';'+<permissions>+';'+<attr>

          < permissions > ::= [ ] | [ <permission>
                              + [ ',' + <permission> ] ]*

This area of the BNF / ASN.1 needs to be fixed in version 06.

Ellen


At 10:59 PM 7/17/00 +0100, David Chadwick wrote:
Ellen

I dont believe that the ASN.1 and BNF are compatible.

The rights in ASN.1 is a SEQUENCE OF CHOICE meaning that
grants and denies can appear as many times as one wants, in any
order. However in the BNF there is no chance of repetition. (An * is
missing I believe immediately after the =

Also the ASN.1 has two "subject" references. Suggest call the
second one "subjectName"

David



***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************
From list@netscape.com Tue Jul 18 13:23:31 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11203 for ; Tue, 18 Jul 2000 13:23:30 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6IHH4U29957; Tue, 18 Jul 2000 10:17:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6IHLx629617; Tue, 18 Jul 2000 10:21:59 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 10:21:59 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: Ellen Stokes , ietf-ldapext@netscape.com Date: Tue, 18 Jul 2000 18:21:07 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: delete permission Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <3974A013.24741.73B9E49@localhost> Priority: normal In-reply-to: <4.2.2.20000718014644.00a29ae0@popmail2.austin.ibm.com> References: <39738FDB.3106.3146556@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"UCjoTC.A._NH.0IJd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT > > >iii) delete this entry permission. What happens if the entry has > >subordinates. Are permissions needed for the subordinates or not. The > >text is mute on this point, although it does mention that no > >permissions are needed on attributes in the entry. > > (EJS) The intent here was to provide the same semantic as X.500. > However, I think we may have missed the point you mention about > subordinates. It seems to me that if you the entry you're deleting is > a leaf entry, then no problem. If there are subordinates, then you > can't just delete an entry in the middle of the DIT, but also need > permisison to delete each subordinate. What does X.500 do? X.500 does not have this problem as only leaf entries can be removed. LDAPv3 basic only allows leaf entries to be deleted, but there was talk of having an operation to delete full subtrees. I dont know the status of this, do you? David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Tue Jul 18 13:23:38 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11253 for ; Tue, 18 Jul 2000 13:23:37 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6IHHFU00072; Tue, 18 Jul 2000 10:17:15 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6IHM8I29764; Tue, 18 Jul 2000 10:22:09 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 10:22:09 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: Rob Byrne - Sun Microsystems Date: Tue, 18 Jul 2000 18:21:07 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Suggestion for scope of ACI Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <3974A013.15898.73BA02E@localhost> Priority: normal In-reply-to: <397432E5.8ACCC467@france.sun.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"Gm19XD.A.DOH.0IJd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date forwarded: Tue, 18 Jul 2000 03:36:01 -0700 (PDT) Date sent: Tue, 18 Jul 2000 12:35:17 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems To: d.w.chadwick@salford.ac.uk Copies to: ietf-ldapext-acm@OpenLDAP.org, ietf- ldapext@netscape.com Subject: Re: Suggestion for scope of ACI Forwarded by: ietf-ldapext@netscape.com > David Chadwick wrote: > > > Ellen and co. > > > > I have a suggestion to make for the scope of ldapACI attributes. > > > > Remove it, and replace it with 2 attribute types: EntryACI and > > SubtreeACI. This simplifies the syntax of the attribute values by > > removing the first element, but more importantly, it allows you to > > have separation of responsibilities. Because we do not have > > attribute value level ACI, then we currently have no way of allowing > > different people to administer entry aci and subtree aci, since they > > are attribute values in the same attribute. But by having two > > attribute types we can can give permissions to different people to > > adminster the different tattribute types. > > > > The functionality remains exactly the same as now, and both > > attributes will have the same syntax, but different semantics will > > be applied to them, one having the existing meaning of entry scope, > > the other the existing meaning of subentry scope. > > I can see that gives more granularity but could you motivate the need > for this ? Sure. Firstly it is in line with existing LDAP practices, for example language codes did not add tags to values (even though this was the original proposal like the X.500 model of contexts) but rather they qualify the attribute type to say what language the value is in. Secondly it simplifies the syntax of the aci attribute by removing an element. Thirdly it allows different administrators/users to be have different access rights to subentry and entry aci (you cant do this with the current scheme as value level permissions dont exist) Fourthly it means that partial delegation no longer needs to be supported Fifthly I think it simplifies the model, as entry aci now apply to the entry only and to one level down for creation - this will simplify the text when describing the various permissions. Subtree aci will then apply only to subtrees, and this will give people permission to create entries to any arbitrary depth in the tree (not just to children). This actually makes the model more powerful but again simplifies the description of the permissions, since we do not need to mix up the different cases of entry and subtree aci as in the current text. Sixth, entry aci can be used to protect subtree aci in the entry in which the latter exist Seventh, subtree aci can be used to protect entry aci in a whole subtree. Eight, if you wanted you could move subtree aci to subentries, although this is not essential to the model. Remember that subentries as originally conceived were conceptually part of the admin points, and were a way of grouping attributes together - just like the new model of families of entries. It is still helpful sometimes to think of subentries as not whole entries but as part of their superior entry. Is that enough for now? > What about other components of the aci, should they be > exposed too ? I dont think so. I see the remaining components as a tuple that stick together, whereas subtree/entry was a difference in semantics that applied to the remaining components. > > > > A related Question. Is there a bug in the current specification > > (either description or semantics). Consider this, I set a subentry > > scope on ldapACI, I give add permission with a subject of "this", > > meaning that I want to allow people or applications to create > >their > > own entries. However, with the text as it now reads it seems to > > allow clients to create subordinate entries beneath their own > > entry, > > as the definition of add reads "add an entry below this entry". Is > > this a correct interpretation. > > I would interpret it the latter way--that way it's consistent with the > other operations (ie. the permission is granted to the entry defined > by the bindDN (what if it's an authzID ?)). Seems like it's a > choice--either it allows you to create your own entry (only > interesting in the case where you bind to one server and it chains > the > add on to another ?) or it allows you to create entries under your > own > entry (only interesting in the case where your own entry already > exists). We will at least clarify the meaning. Now splitting up the aci into entry and subtree aci solves this problem. Entry aci give permission to create entries subordinate to this one. Subtree aci give permission to create any entry. So "this" in the latter case would mean the DN of the entry being created, whilst in the former case would mean the DN of the superior. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Tue Jul 18 17:43:32 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07026 for ; Tue, 18 Jul 2000 17:43:31 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6ILXPR22865; Tue, 18 Jul 2000 14:33:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6ILfxo00800; Tue, 18 Jul 2000 14:41:59 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 14:41:59 -0700 (PDT) Message-Id: <4.3.1.0.20000718143905.00ad3920@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 18 Jul 2000 14:46:19 -0700 To: d.w.chadwick@salford.ac.uk, Ellen Stokes , ietf-ldapext@netscape.com From: Bruce Greenblatt Subject: Re: delete permission In-Reply-To: <3974A013.24741.73B9E49@localhost> References: <4.2.2.20000718014644.00a29ae0@popmail2.austin.ibm.com> <39738FDB.3106.3146556@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"A4i5n.A.8L.l8Md5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 06:21 PM 07/18/2000 +0100, David Chadwick wrote: > LDAPv3 basic only allows leaf entries to be deleted, but >there was talk of having an operation to delete full subtrees. I dont >know the status of this, do you? > >David My proposal that included subtree operations for delete, copy and modify as extended operations has expired. Michael Armijo wrote a draft that included a control to add to the existing delete operation, which also appears to have expired. If there is interest, I can resubmit the draft to reactivate it (I have a change or two that I need to make anyway). Of the two approaches I liked mine better (but I'm biased). Michael did make some interesting points in favor of the use of a control. Bruce From list@netscape.com Tue Jul 18 17:49:46 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09748 for ; Tue, 18 Jul 2000 17:49:45 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6ILdbR24151; Tue, 18 Jul 2000 14:39:37 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6ILmCk03681; Tue, 18 Jul 2000 14:48:12 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 14:48:12 -0700 (PDT) Message-Id: <4.3.1.0.20000718145033.00ad3d40@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 18 Jul 2000 14:52:38 -0700 To: ietf-ldapext@netscape.com From: Bruce Greenblatt Subject: TISDAG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"I4coID.A.I5.aCNd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I was just sifting through my backlog of drafts to read, and came across the latest TISDAG update. It makes pretty good reading. It's fascinating to see how all of these technologies come together in a real environment. My congratulations to the authors (I'm not one of them, and have zero to do with the project)... ftp://ftp.isi.edu/internet-drafts/draft-daigle-tisdag-02.txt Bruce From list@netscape.com Tue Jul 18 18:10:31 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17563 for ; Tue, 18 Jul 2000 18:10:30 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6IM0VR27525; Tue, 18 Jul 2000 15:00:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6ILuGI07818; Tue, 18 Jul 2000 14:56:16 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 14:56:16 -0700 (PDT) Message-Id: <4.2.2.20000718165021.00a38d00@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 18 Jul 2000 16:55:52 -0500 To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com, bgreenblatt@directory-applications.com From: Ellen Stokes Subject: Re: delete permission In-Reply-To: <3974A013.24741.73B9E49@localhost> References: <4.2.2.20000718014644.00a29ae0@popmail2.austin.ibm.com> <39738FDB.3106.3146556@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"fw1LHD.A.W5B.9JNd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David / Bruce, I think the ldap model should use delete in the X.500 sense - the object must be a leaf entry. However, subtree delete becomes interesting if/when we decide to surface the scope of ACI (entry/subtree) via your entryACI / subtreeACI proposal. At that point in time, then the expired subtree drafts become interesting because you have a way actually invoke the subtree operation and apply access control to the operation. Comments? Ellen At 06:21 PM 7/18/00 +0100, David Chadwick wrote: > > > > >iii) delete this entry permission. What happens if the entry has > > >subordinates. Are permissions needed for the subordinates or not. The > > >text is mute on this point, although it does mention that no > > >permissions are needed on attributes in the entry. > > > > (EJS) The intent here was to provide the same semantic as X.500. > > However, I think we may have missed the point you mention about > > subordinates. It seems to me that if you the entry you're deleting is > > a leaf entry, then no problem. If there are subordinates, then you > > can't just delete an entry in the middle of the DIT, but also need > > permisison to delete each subordinate. What does X.500 do? > >X.500 does not have this problem as only leaf entries can be >removed. LDAPv3 basic only allows leaf entries to be deleted, but >there was talk of having an operation to delete full subtrees. I dont >know the status of this, do you? > >David > >*************************************************** > >David Chadwick >IS Institute, University of Salford, Salford M5 4WT >Tel +44 161 295 5351 Fax +44 161 745 8169 >Mobile +44 790 167 0359 >Email D.W.Chadwick@salford.ac.uk >Home Page http://www.salford.ac.uk/its024/chadwick.htm >Understanding X.500 http://www.salford.ac.uk/its024/X500.htm >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm >Entrust key validation string MLJ9-DU5T-HV8J > >*************************************************** From list@netscape.com Tue Jul 18 18:46:45 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00975 for ; Tue, 18 Jul 2000 18:46:45 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6IMadR03378; Tue, 18 Jul 2000 15:36:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6IMjDQ04243; Tue, 18 Jul 2000 15:45:13 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 15:45:13 -0700 (PDT) Message-Id: <4.3.2.7.0.20000718143734.00b164a0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jul 2000 15:44:56 -0700 To: IETF-LDAPbis@openldap.org, agenda@ietf.org From: "Kurt D. Zeilenga" Subject: LDAP (v3) Revision BOF (LDAPbis) Cc: IETF-LDAPext@netscape.com, IETF-LDUP@imc.org, IETF@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"Mp5Kj.A.8BB.33Nd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is the final IETF#48 LDAPbis BOF agenda. Those interested are encouraged to attend. Regards, Kurt --- cut here --- NAME: LDAP (v3) Revision BOF ACRONYM: LDAPbis CHAIRS: Kurt Zeilenga RL "Bob" Morgan MAILING LIST: Archives: http://www.openldap.org/lists/ietf-ldapbis/ Subscribe: mailto:ietf-ldapbis-request@OpenLDAP.org?body=subscribe Post: mailto:ietf-ldapbis@OpenLDAP.org Policy: You must be subscribed to post. INTRODUCTION: LDAPv3 core specifications (RFC 2251-56) must be revised if they are to be progressed to Draft Standard per the IESG Note contained within these documents. With the approval of RFC 2829 and 2830, the necessary secure authentication mechanisms to obtain Draft Standard status are now available. In addition, the community has obtain a wealth of operational experience using the current specifications. The community has identified a number of areas where the specifications need to amended. These amendments include a few significant substantive changes, a fair number of lessor substantive changes, and many clarifications. A forum for discussing and addressing these issues is needed. PURPOSE: The purpose of this BOF is to discuss proposed updates to the LDAPv3 core protocol specification (RFC 2251-56, 2829-30), to identify work items, and discuss formation of a working group specifically chartered to address identified work items. Extensions to LDAPv3 are not within the scope of this BOF as this is the realm of existing IETF working groups. BACKGROUND: The LDAPv3 specifications were developed by the ASID and LDAPext working groups. The ASID working group is defunct. The LDAPext WG is focused on significant protocol extensions such as Access Control, APIs, Referrals, and CLDAP. A separate working group is currently proposed to focus energies to address LDAPv3 specification updates while not distracting LDAPext from their chartered work. However, at the discretion of the IESG, work items identified by this BOF may be assigned to LDAPext or other appropriate WG (after appropriate charter review). TIME/PLACE: WEDNESDAY, August 2, 2000, 1530-1730 AGENDA: Agenda Bashing Introduction, Chair(s), 10m Extent of suggested changes LDAPv3 vs LDAPv4 IESG Note, AD, 5m LDAPv3 Applicability Statement, JeffH, 10m Relationship to X.500, MarkW, 10m Reorganisation of the Specification, MarkW, 5m Other Issues, TBD, 10m Next Steps, Chair(s), 10m I-D Review (as time permits), Author(s), 1hr (5m/I-D) Order to be determined by chair(s) READING MATERIALS: RFC 2251-2256,2829,2830 draft-armijo-ldap-control-error-00.txt draft-hodges-ldapv3-as-00.txt draft-just-ldapv3-rescodes-02.txt draft-rharrison-ldap-extpartresp-01.txt draft-smith-ldapv3-dn-update-00.txt draft-smith-ldapv3-url-update-00.txt draft-zeilenga-ldapv3bis-opattrs.txt draft-zeilenga-ldapv3bis-rfc2251.txt draft-zeilenga-ldapv3bis-rfc2252.txt draft-zeilenga-ldapv3bis-rfc2253.txt draft-zeilenga-ldapv3bis-rfc2254.txt draft-zeilenga-ldapv3bis-rfc2255.txt draft-zeilenga-ldapv3bis-rfc2256.txt draft-zeilenga-ldapv3bis-rfc2829.txt draft-zeilenga-ldapv3bis-rfc2830.txt From list@netscape.com Tue Jul 18 20:34:24 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09610 for ; Tue, 18 Jul 2000 20:34:23 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6J0RxU09018; Tue, 18 Jul 2000 17:27:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6J0Wrg24051; Tue, 18 Jul 2000 17:32:53 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 17:32:53 -0700 (PDT) Date: Tue, 18 Jul 2000 17:32:36 -0700 (PDT) Message-Id: <200007190032.e6J0WZw09823@xwing.netscape.com> From: beefii@yahoo.com To: friends@netscape.com Subject: FREE Advertizing X-Reply-To: beefii@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"e6K_PD.A.j2F.wcPd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit You have sent me an e-mail or we belong to the same opt-in group. Want to send your ad to 3,200,000 people..... ALL FOR FREE ? Dear Advertiser : You've got a product or service to sell? You've set up a beautiful >web-site, submitted to all the search engines and your fingers are numb from endless posting to classified and free-4-all sites? - You did everything right? Still, prospects you expected to flood you with orders just dribble in! I know, I've been there also! What if I told you that, in just a few short weeks, you would have to hire extra personnel to handle a mountain of incoming orders! You'd be interested, right? Now, what if I told you, you can accomplish this amazing feat in under one hour a day and that it would be ABSOLUTELY FREE!! That's right, I said FREE and I meant it! What's more, you need not fear "flames", "bombs", the loss of your ISP or an unfriendly knock at the door in the early morning hours! Sound too good to be true? Read on! In less than an hour a day, you can put your product or service in front of as many as 3,200,000 potential customers! That's right, as many as THREE MILLION TWO HUNDRED THOUSAND POTENTIAL CUSTOMERS Are you ready to learn this foolproof, FREE system? All right, let's get started : STEP 1 : Make a copy of this letter. STEP 2 : Read the 5 advertisements at the end of this letter. STEP 3 : Remove the ad in the number 1 position and renumber the remaining ads as # 1 through # 4. STEP 4 : Place your ad for product, service or website AFTER the number 4 ad and number it as number 5. ( I'll explain why a little later ). STEP 5 : Send the letter to 10 people a day, for five days a week for two weeks. That's a total of 100 letters! (I'll tell you where to find them free). That's it! You're finished !! Too simple you say? Let's look at the math! The reason for sending 10 letters a day for 2 weeks is that you can reasonably assume that at least 20% of those receiving your letter are savvy enough business people to see the value of this FREE system! That gives you 20 potential customers who will SEE YOUR ADVERTISEMENT. Not impressed, Let's continue! Each of those 20 recipients send out 100 letters and get a 20% participation. You now have 400 POTENTIAL CUSTOMERS SEEING YOUR AD! Each of those 400 people send out 100 letters, and get a 20% participation. You're now up to 8,000 POTENTIAL CUSTOMERS SEEING YOUR AD! Each of those 8,000 send out 100 letters, get a 20% participation and your ad is ---exposed to 160,000 POTENTIAL customers. Your advertisement is now in the number 1 position! If each of the 160,000 send out 100 letters and get only 20% participation, YOUR AD IS SEEN BY 3,200,000 POTENTIAL CUSTOMERS and YOU HAVE NOT SPENT ONE RED CENT!! Now, take a minute to catch your breath while I explain where to find the 100 people to send your letter to at ABSOLUTELY NO COST and why it's important to place your ad in the number 5 position! Actually, we'll start with the positioning first! You may ask yourself "why not shoot for the top and put my ad in the number 1 position?" The answer is quite simple! Those who participate in this POWERFUL and COMPLETELY FREE SYSTEM will be doing the same thing you should do, removing the number 1 ad and placing their ad in the number 5 position. If you were to put your ad in the number 1 spot, it will be goneafter the first cycle! By placing it in the number 5 slot, your ad won't be removed until it seen by as many as 3,200,000 POTENTIAL CUSTOMERS! And remember, this system is based on a REALISTIC participation rate of only 20%! A good chunk of the 80% who aren't serious enough about their business and their future to participate will also be reading YOUR AD! When you begin calculating them, the total numbers are absolutely staggering! So, where do you find the 100 people to send your letter to? Again, it's quite simple and TOTALLY FREE! Just go to your favorite search engine ( Yahoo, Lycos, Alta Vista, Netscape, Look Smart, etc. ) classified section! Further more, even when you go to your favorite search Engines and type posting service you will find THOUSANDS of commercial advertisements with e- mail addresses! The possibilities are endless. These are professional marketers, like yourself---( AND MANY OF THEM EVEN PAID FOR THE ADS. ) --- marketers who have placed these ads with the same hopes of attracting customers you have! Do you think they will go for this powerful FREE way of MASSIVE advertising that brings in more result than magazines ads, news paper ads and TV commercials combined? All for FREE. Of course they would!!! Talk about a Target Market! So, there you have it! And, of course, you don't have to stop at sending your letter to only 100 people! If you wish ( and can handle the MASSIVE VOLUME this FREE system provides ), you can send out more letters as time permits and INCREASE YOUR PROFITS BEYOUND YOUR WILDEST DREAMS! This system simply CAN'T FAIL! Please notice that I never promised a 100% articipation rate. You and I both know that would be totally unrealistic. That's why I use the 20% example. Your results may be more or less. It doesn't matter! If you can accomplish even 10% participation, you're still miles ahead of those timid, lazy souls who find themselves lost in a sea of mediocrity. BY the way, a 10% participation would still EXPOSE YOUR PRODUCT OR SERVICE TO OVER 600,000 POTENTIAL CUSTOMERS! And if 10% out of 600,000 buy your product or service that's 60 THOUSAND. WOW!! You simply CAN'T LOSE!! We both know and agree the keys to a successful business is a numbers game. That's all it is. The more people you expose your business to, the greater the chances of your product or services being sold or achieving outstanding success. Don't you agree? So, what are you waiting for? You have nothing to lose. Start making money today. Thanks. Read the advertisements below and start sending your letter out NOW! ---------FREE ADVERTISING-------- _____________________________________________________________________________________ 1)Get Paid To Do What You're Doing Right Now!! You have a home page right? Do they pay you? This one will and it's FREE! You Browse around the Internet right? Do you get paid for it? This one will, and it's FREE! Please visit my site @ http://www.realmoney.bigstep.comm and start to get paid for what you are already doing! THERE IS NO REASON NOT TO! _____________________________________________________________________________________ 2)HERE IS THE EASIEST PROGRAM ON THE INTERNET! Get paid when your computer is on IDLE!! That's right!! Just use WAVEVU as your SCREENSAVER!! It does'nt get ANY EASIER! http://www.wavevu.com/wavevu.asp?RefID=F13834 _____________________________________________________________________________________ 3)Are you health conscious and are interested in maintaining your health, or perhaps are interested in losing a little weight? Do you want to break free from working long hours for someone else and not spending time with your family or being able to do what you want? Then let me show you a simple way to make a substantial income, while getting superior health and wellness products, at a discount price, from a well established company that is free to join. Lots of people are doing extremely well, money wise and health wise with this, and you can too! Follow this link and click on make money Go to http://virgilsandberg.FreeLife.com _____________________________________________________________________________________ 4) QuickCommerce is a powerful Internet based software tool that is a real-time authorization terminal and complete secure transaction processing system. Merchants can use Virtual Terminal and WebLink to settle credit card transactions without the need for a separate terminal or software. Credit card transactions are authorized immediately upon submitting! Electronic Checks, are also supported on the QuickCommerce system. With our quick and easy merchant account setup you can be accepting credit cards in as few as a 7 days! In today’s competitive business environment you need to accept secure credit card and check payments over the Internet. To begin, simply click http://www.qcaffiliate.com/qc/beefii/index.html or beefii@yahoo,com -------------------------------------------------------------------------------------------------------------------------------- This message is sent in compliance of the new e-mail bill section 301.Under Bill S. 1618 TITLE III passed by the 105 th. U.S. Congress. This message can not be Considered Spam as long as we include the way to be removed, Paragraph (a) (c) of S. 618,further transmissions to you by the sender of this e-mail may be stopped at no cost to you by sending a request to be removed e - mail to: ( YOUR E-MAIL )--- Please type "Remove" in the subject line _____________________________________________________________________________________ From list@netscape.com Tue Jul 18 22:12:20 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09697 for ; Tue, 18 Jul 2000 22:12:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6J25fU18869; Tue, 18 Jul 2000 19:05:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6J2AaE23068; Tue, 18 Jul 2000 19:10:36 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 19:10:36 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C69868F@aspams01.cai.com> From: "Ramsay, Ron" To: Ellen Stokes , d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com, bgreenblatt@directory-applications.com Subject: RE: delete permission Date: Wed, 19 Jul 2000 12:10:41 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"3oq5o.A.DoF.a4Qd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hi, It will always be possible for a client to recursively delete the subtree using the usual delete of a leaf. Access controls, as discussed on this thread, will still apply and have the expected outcome. Ron. -----Original Message----- From: Ellen Stokes [mailto:stokes@austin.ibm.com] Sent: Wednesday, 19 July 2000 7:56 To: d.w.chadwick@salford.ac.uk; ietf-ldapext@netscape.com; bgreenblatt@directory-applications.com Subject: Re: delete permission David / Bruce, I think the ldap model should use delete in the X.500 sense - the object must be a leaf entry. However, subtree delete becomes interesting if/when we decide to surface the scope of ACI (entry/subtree) via your entryACI / subtreeACI proposal. At that point in time, then the expired subtree drafts become interesting because you have a way actually invoke the subtree operation and apply access control to the operation. Comments? Ellen At 06:21 PM 7/18/00 +0100, David Chadwick wrote: > > > > >iii) delete this entry permission. What happens if the entry has > > >subordinates. Are permissions needed for the subordinates or not. The > > >text is mute on this point, although it does mention that no > > >permissions are needed on attributes in the entry. > > > > (EJS) The intent here was to provide the same semantic as X.500. > > However, I think we may have missed the point you mention about > > subordinates. It seems to me that if you the entry you're deleting is > > a leaf entry, then no problem. If there are subordinates, then you > > can't just delete an entry in the middle of the DIT, but also need > > permisison to delete each subordinate. What does X.500 do? > >X.500 does not have this problem as only leaf entries can be >removed. LDAPv3 basic only allows leaf entries to be deleted, but >there was talk of having an operation to delete full subtrees. I dont >know the status of this, do you? > >David > >*************************************************** > >David Chadwick >IS Institute, University of Salford, Salford M5 4WT >Tel +44 161 295 5351 Fax +44 161 745 8169 >Mobile +44 790 167 0359 >Email D.W.Chadwick@salford.ac.uk >Home Page http://www.salford.ac.uk/its024/chadwick.htm >Understanding X.500 http://www.salford.ac.uk/its024/X500.htm >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm >Entrust key validation string MLJ9-DU5T-HV8J > >*************************************************** From list@netscape.com Wed Jul 19 01:02:58 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26640 for ; Wed, 19 Jul 2000 01:02:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6J4oER10766; Tue, 18 Jul 2000 21:50:14 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6J4wnU29846; Tue, 18 Jul 2000 21:58:49 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 21:58:49 -0700 (PDT) X-Lotus-FromDomain: TIVOLI SYSTEMS From: Ellen_Stokes@tivoli.com To: "Ramsay, Ron" cc: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com, bgreenblatt@directory-applications.com Message-ID: <86256921.001B597C.00@tivmta4.tivoli.com> Date: Tue, 18 Jul 2000 23:58:35 -0500 Subject: RE: delete permission Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=CcxkTHu1fKjmS4Y7oweTCiYAp49JAH9ZJpmTumk5R8kZ8DaFhftMuwZx" Content-Disposition: inline Resent-Message-ID: <"cjowJD.A._RH.HWTd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --0__=CcxkTHu1fKjmS4Y7oweTCiYAp49JAH9ZJpmTumk5R8kZ8DaFhftMuwZx Content-type: text/plain; charset=us-ascii Content-Disposition: inline I agree... Ellen To: --0__=CcxkTHu1fKjmS4Y7oweTCiYAp49JAH9ZJpmTumk5R8kZ8DaFhftMuwZx Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =A0 =A0 =A0 =A0Ellen Stokes , d.w.chadwick@salfo= rd.ac.uk, ietf-ldapext@netscape.com, bgreenblatt@directory-applications.com cc: =A0 =A0 =A0 =A0 (bcc: Ellen Stokes/Tivoli Systems) Subject: =A0 =A0 =A0 =A0RE: delete permission [IMAGE] Hi, It will always be possible for a client to recursively delete the subtr= ee using the usual delete of a leaf. Access controls, as discussed on this= thread, will still apply and have the expected outcome. Ron. -----Original Message----- From: Ellen Stokes [mailto:stokes@austin.ibm.com] Sent: Wednesday, 19 July 2000 7:56 To: d.w.chadwick@salford.ac.uk; ietf-ldapext@netscape.com; bgreenblatt@directory-applications.com Subject: Re: delete permission David / Bruce, I think the ldap model should use delete in the X.500 sense - the objec= t must be a leaf entry. However, subtree delete becomes interesting if/when we decide to surface the scope of ACI (entry/subtree) via your entryACI / subtreeACI= proposal. =A0At that point in time, then the expired subtree drafts bec= ome interesting because you have a way actually invoke the subtree operatio= n and apply access control to the operation. Comments? Ellen At 06:21 PM 7/18/00 +0100, David Chadwick wrote: > > > > >iii) delete this entry permission. What happens if the entry has > > >subordinates. Are permissions needed for the subordinates or not. = The > > >text is mute on this point, although it does mention that no > > >permissions are needed on attributes in the entry. > > > > (EJS) =A0The intent here was to provide the same semantic as X.500.= > > However, I think we may have missed the point you mention about > > subordinates. =A0It seems to me that if you the entry you're deleti= ng is > > a leaf entry, then no problem. =A0If there are subordinates, then y= ou > > can't just delete an entry in the middle of the DIT, but also need > > permisison to delete each subordinate. =A0What does X.500 do? > >X.500 does not have this problem as only leaf entries can be >removed. LDAPv3 basic only allows leaf entries to be deleted, but >there was talk of having an operation to delete full subtrees. I dont >know the status of this, do you? > >David > >*************************************************** > >David Chadwick >IS Institute, University of Salford, Salford M5 4WT >Tel +44 161 295 5351 =A0Fax +44 161 745 8169 >Mobile +44 790 167 0359 >Email D.W.Chadwick@salford.ac.uk >Home Page =A0http://www.salford.ac.uk/its024/chadwick.htm >Understanding X.500 =A0http://www.salford.ac.uk/its024/X500.htm >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm >Entrust key validation string MLJ9-DU5T-HV8J > >*************************************************** [IMAGE] (Embedded image moved to file: pic24227.pcx) (See attached file: C.gif) (See attached file: att1.eml) = --0__=CcxkTHu1fKjmS4Y7oweTCiYAp49JAH9ZJpmTumk5R8kZ8DaFhftMuwZx Content-type: application/octet-stream; name="pic24227.pcx" Content-Disposition: attachment; filename="pic24227.pcx" Content-Transfer-Encoding: base64 CgUBCAAAAAA4AgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABOQIBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAGxAEyLF9YVzRXLFc0VzQ4VC9WMCwuRE9DwiwyLA0KAMH/r8H6wf8OygDC AQDB1A/B/6/B+sH/SgBbTm90ZXNdRURJVEVYUMIyPVdvcmRQZXJmZWN0IDYuMSwyLF9YVzRXLFc0 VzQ4VC9WMSwuV1BELC5XUFQsLkRPQ8IsMiwNCgDByALB/6/B+sH/DgABIA4BGA/EAAkALBDB/6/B +sH/RgBbTm90ZXNdRURJVEVYUDIzPVdvcmQgZm9yIFdpbmRvd3MgNi4wLDIsX1hXNFcsVzRXNDlU L1YwLC5ET0PCLDIsDQoAr8H6wv+vwfrB/w7KAMIBAJAQwf+vwfrB/xoAW05vdGVzXcJERVRpbWVv dXQ9MTANCgCvwfrC/6/B+sH/DsoAwgEAwfAQwf+vwfrB/8H+AFtOb3Rlc11OQU1FRFNUWUxFMD0w M8IwNDI2MTczNjk2M/8wMTAxMDHFMEHNMDHCMEHCMDUwQcYwNjTCMEHCMDUwQfsw3TDCMDk0MDTM MA0KAMH/r8H6wf8OwgADAQPCATIsX1hXNFcsVzRXNDhUL1YwLC5ET0PCLDIsDQoAwf+vwfrB/w7K AMIBAMHUD8H/r8H6wf9KAFtOb3Rlc11FRElURVhQwjI9V29yZFBlcmZlY3QgNi4xLDIsX1hXNFcs VzRXNDhUL1YxLC5XUEQsLldQVCwuRE9DwiwyLA0KAMHIAsH/r8H6wf8OAAEgDgEYD8QACQAsEMH/ r8H6wf9GAFtOb3Rlc11FRElURVhQMjM9V29yZCBmb3IgV2luZG93cyA2LjAsMixfWFc0VyxXNFc0 OVQvVjAsLkRPQ8IsMiwNCgCvwfrC/6/B+sH/DsoAwgEAkBDB/6/B+sH/GgBbTm90ZXNdwkRFVGlt ZW91dD0xMA0KAK/B+sL/r8H6wf8OygDCAQDB8BDB/6/B+sH/wf4AW05vdGVzXU5BTUVEU1RZTEUw PTAzwjA0MjYxNzM2OTYz/zAxMDEwMcUwQc0wMcIwQcIwNTBBxjA2NMIwQcIwNTBB+zDdMMIwOTQw NMwwDQoAwf+vwfrB/w7CAAMBA8IBMixfWFc0VyxXNFc0OFQvVjAsLkRPQ8IsMiwNCgDB/6/B+sH/ DsoAwgEAwdQPwf+vwfrB/0oAW05vdGVzXUVESVRFWFDCMj1Xb3JkUGVyZmVjdCA2LjEsMixfWFc0 VyxXNFc0OFQvVjEsLldQRCwuV1BULC5ET0PCLDIsDQoAwcgCwf+vwfrB/w4AASAOARgPxAAJACwQ wf+vwfrB/0YAW05vdGVzXUVESVRFWFAyMz1Xb3JkIGZvciBXaW5kb3dzIDYuMCwyLF9YVzRXLFc0 VzQ5VC9WMCwuRE9DwiwyLA0KAK/B+sL/r8H6wf8OygDCAQCQEMH/r8H6wf8aAFtOb3Rlc13CREVU aW1lb3V0PTEwDQoAr8H6wv+vwfrB/w7KAMIBAMHwEMH/r8H6wf/B/gBbTm90ZXNdTkFNRURTVFlM RTA9MDPCMDQyNjE3MzY5NjP/MDEwMTAxxTBBzTAxwjBBwjA1MEHGMDY0wjBBwjA1MEH7MN0wwjA5 NDA0zDANCgDB/6/B+sH/DsIA3hYA9hYPxxYPxBYPwhYPwxYPwhYPFg/GFg/EFg/DFg/CFsMPFg8W DxYPFg/CFg/CFg/DFg/DFg/+FsMP/xb/Fv8W/xbyFtkWyBYAyBbEFsIWDAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA== --0__=CcxkTHu1fKjmS4Y7oweTCiYAp49JAH9ZJpmTumk5R8kZ8DaFhftMuwZx Content-type: image/gif; name="C.gif" Content-Disposition: attachment; filename="C.gif" Content-Description: Compuserve GIF Content-Transfer-Encoding: base64 R0lGODlhBQAfAIAAAAAAAAAAACwAAAAABQAfAEACIIJ75JWqyYxDD00vCXP1fohBG1CNYJWhnnmh 0JqdW+oNADs= --0__=CcxkTHu1fKjmS4Y7oweTCiYAp49JAH9ZJpmTumk5R8kZ8DaFhftMuwZx Content-type: application/octet-stream; name="att1.eml" Content-Disposition: attachment; filename="att1.eml" Content-Transfer-Encoding: base64 UmVjZWl2ZWQ6IGZyb20gY29ycC50aXZvbGkuY29tIChbMTQ2Ljg0LjEwNC4xXSkgYnkgbm90ZXMt YnJhaG1zMi50aXZvbGkuY29tIChMb3R1cyBTTVRQIE1UQSB2NC42LjUgICg4NjMuMiA1LTIwLTE5 OTkpKSB3aXRoIFNNVFAgaWQgODYyNTY5MjEuMDAwQzA4MTQ7IFR1ZSwgMTggSnVsIDIwMDAgMjE6 MTE6MjUgLTA1MDANClJlY2VpdmVkOiBmcm9tIHNtdHAyLnRpdm9saS5jb20gKHNtdHAyLnRpdm9s aS5jb20gWzIwOC4yMzAuMjQ0LjNdKQ0KCWJ5IGNvcnAudGl2b2xpLmNvbSAoOC45LjMvOC45LjAp IHdpdGggU01UUCBpZCBWQUEyMDQ2NzsNCglUdWUsIDE4IEp1bCAyMDAwIDIxOjExOjI2IC0wNTAw IChDRFQpDQpSZWNlaXZlZDogZnJvbSBuZXRzY2FwZS5jb20gKGgtMjA1LTIxNy0yMzctNDYubmV0 c2NhcGUuY29tIFsyMDUuMjE3LjIzNy40Nl0pDQoJYnkgc210cDIudGl2b2xpLmNvbSAoOC45LjMv OC45LjMpIHdpdGggRVNNVFAgaWQgVkFBMjQyNzU7DQoJVHVlLCAxOCBKdWwgMjAwMCAyMToxMToy NSAtMDUwMCAoQ0RUKQ0KUmVjZWl2ZWQ6IGZyb20gYWthLm1jb20uY29tIChha2EubWNvbS5jb20g WzIwNS4yMTcuMjM3LjE4MF0pDQoJYnkgbmV0c2NhcGUuY29tICg4LjEwLjAvOC4xMC4wKSB3aXRo IEVTTVRQIGlkIGU2SjIyR1IwMDM3NjsNCglUdWUsIDE4IEp1bCAyMDAwIDE5OjAyOjE2IC0wNzAw IChQRFQpDQpSZWNlaXZlZDogKGZyb20gbGlzdEBsb2NhbGhvc3QpDQoJYnkgYWthLm1jb20uY29t ICg4LjEwLjAvOC4xMC4wKSBpZCBlNkoyQXBjMjMzMTI7DQoJVHVlLCAxOCBKdWwgMjAwMCAxOTox MDo1MSAtMDcwMCAoUERUKQ0KUmVzZW50LURhdGU6IFR1ZSwgMTggSnVsIDIwMDAgMTk6MTA6NTEg LTA3MDAgKFBEVCkNCk1lc3NhZ2UtSUQ6IDwxMTk4MUY5RjU2NDlENDExQkM5MjAwOTAyN0QwRDE4 QzY5ODY4RkBhc3BhbXMwMS5jYWkuY29tPg0KRnJvbTogIlJhbXNheSwgUm9uIiA8Um9uLlJhbXNh eUBjYS5jb20+DQpUbzogRWxsZW4gU3Rva2VzIDxzdG9rZXNAYXVzdGluLmlibS5jb20+LCBkLncu Y2hhZHdpY2tAc2FsZm9yZC5hYy51aywNCiAgICAgICAgaWV0Zi1sZGFwZXh0QG5ldHNjYXBlLmNv bSwgYmdyZWVuYmxhdHRAZGlyZWN0b3J5LWFwcGxpY2F0aW9ucy5jb20NClN1YmplY3Q6IFJFOiBk ZWxldGUgcGVybWlzc2lvbg0KRGF0ZTogV2VkLCAxOSBKdWwgMjAwMCAxMjoxMDo0MSArMTAwMA0K TUlNRS1WZXJzaW9uOiAxLjANClgtTWFpbGVyOiBJbnRlcm5ldCBNYWlsIFNlcnZpY2UgKDUuNS4y NjUwLjIxKQ0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9Imlzby04ODU5LTEi DQpSZXNlbnQtTWVzc2FnZS1JRDogPCIzb3E1by5BLkRvRi5hNFFkNSJAZ2xhY2llcj4NClJlc2Vu dC1Gcm9tOiBpZXRmLWxkYXBleHRAbmV0c2NhcGUuY29tDQpYLU1haWxpbmctTGlzdDogPGlldGYt bGRhcGV4dEBuZXRzY2FwZS5jb20+IA0KWC1Mb29wOiBpZXRmLWxkYXBleHRAbmV0c2NhcGUuY29t DQpQcmVjZWRlbmNlOiBsaXN0DQpSZXNlbnQtU2VuZGVyOiBpZXRmLWxkYXBleHQtcmVxdWVzdEBu ZXRzY2FwZS5jb20NCg0KSGksDQoNCkl0IHdpbGwgYWx3YXlzIGJlIHBvc3NpYmxlIGZvciBhIGNs aWVudCB0byByZWN1cnNpdmVseSBkZWxldGUgdGhlIHN1YnRyZWUNCnVzaW5nIHRoZSB1c3VhbCBk ZWxldGUgb2YgYSBsZWFmLiBBY2Nlc3MgY29udHJvbHMsIGFzIGRpc2N1c3NlZCBvbiB0aGlzDQp0 aHJlYWQsIHdpbGwgc3RpbGwgYXBwbHkgYW5kIGhhdmUgdGhlIGV4cGVjdGVkIG91dGNvbWUuDQoN ClJvbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEVsbGVuIFN0b2tlcyBb bWFpbHRvOnN0b2tlc0BhdXN0aW4uaWJtLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgMTkgSnVseSAy MDAwIDc6NTYNClRvOiBkLncuY2hhZHdpY2tAc2FsZm9yZC5hYy51azsgaWV0Zi1sZGFwZXh0QG5l dHNjYXBlLmNvbTsNCmJncmVlbmJsYXR0QGRpcmVjdG9yeS1hcHBsaWNhdGlvbnMuY29tDQpTdWJq ZWN0OiBSZTogZGVsZXRlIHBlcm1pc3Npb24NCg0KDQpEYXZpZCAvIEJydWNlLA0KDQpJIHRoaW5r IHRoZSBsZGFwIG1vZGVsIHNob3VsZCB1c2UgZGVsZXRlIGluIHRoZSBYLjUwMCBzZW5zZSAtIHRo ZSBvYmplY3QNCm11c3QgYmUgYSBsZWFmIGVudHJ5Lg0KDQpIb3dldmVyLCBzdWJ0cmVlIGRlbGV0 ZSBiZWNvbWVzIGludGVyZXN0aW5nIGlmL3doZW4gd2UgZGVjaWRlIHRvDQpzdXJmYWNlIHRoZSBz Y29wZSBvZiBBQ0kgKGVudHJ5L3N1YnRyZWUpIHZpYSB5b3VyIGVudHJ5QUNJIC8gc3VidHJlZUFD SQ0KcHJvcG9zYWwuICBBdCB0aGF0IHBvaW50IGluIHRpbWUsIHRoZW4gdGhlIGV4cGlyZWQgc3Vi dHJlZSBkcmFmdHMgYmVjb21lDQppbnRlcmVzdGluZyBiZWNhdXNlIHlvdSBoYXZlIGEgd2F5IGFj dHVhbGx5IGludm9rZSB0aGUgc3VidHJlZSBvcGVyYXRpb24NCmFuZCBhcHBseSBhY2Nlc3MgY29u dHJvbCB0byB0aGUgb3BlcmF0aW9uLg0KDQpDb21tZW50cz8NCg0KRWxsZW4NCg0KDQpBdCAwNjoy MSBQTSA3LzE4LzAwICswMTAwLCBEYXZpZCBDaGFkd2ljayB3cm90ZToNCg0KPiA+DQo+ID4gPmlp aSkgZGVsZXRlIHRoaXMgZW50cnkgcGVybWlzc2lvbi4gV2hhdCBoYXBwZW5zIGlmIHRoZSBlbnRy eSBoYXMNCj4gPiA+c3Vib3JkaW5hdGVzLiBBcmUgcGVybWlzc2lvbnMgbmVlZGVkIGZvciB0aGUg c3Vib3JkaW5hdGVzIG9yIG5vdC4gVGhlDQo+ID4gPnRleHQgaXMgbXV0ZSBvbiB0aGlzIHBvaW50 LCBhbHRob3VnaCBpdCBkb2VzIG1lbnRpb24gdGhhdCBubw0KPiA+ID5wZXJtaXNzaW9ucyBhcmUg bmVlZGVkIG9uIGF0dHJpYnV0ZXMgaW4gdGhlIGVudHJ5Lg0KPiA+DQo+ID4gKEVKUykgIFRoZSBp bnRlbnQgaGVyZSB3YXMgdG8gcHJvdmlkZSB0aGUgc2FtZSBzZW1hbnRpYyBhcyBYLjUwMC4NCj4g PiBIb3dldmVyLCBJIHRoaW5rIHdlIG1heSBoYXZlIG1pc3NlZCB0aGUgcG9pbnQgeW91IG1lbnRp b24gYWJvdXQNCj4gPiBzdWJvcmRpbmF0ZXMuICBJdCBzZWVtcyB0byBtZSB0aGF0IGlmIHlvdSB0 aGUgZW50cnkgeW91J3JlIGRlbGV0aW5nIGlzDQo+ID4gYSBsZWFmIGVudHJ5LCB0aGVuIG5vIHBy b2JsZW0uICBJZiB0aGVyZSBhcmUgc3Vib3JkaW5hdGVzLCB0aGVuIHlvdQ0KPiA+IGNhbid0IGp1 c3QgZGVsZXRlIGFuIGVudHJ5IGluIHRoZSBtaWRkbGUgb2YgdGhlIERJVCwgYnV0IGFsc28gbmVl ZA0KPiA+IHBlcm1pc2lzb24gdG8gZGVsZXRlIGVhY2ggc3Vib3JkaW5hdGUuICBXaGF0IGRvZXMg WC41MDAgZG8/DQo+DQo+WC41MDAgZG9lcyBub3QgaGF2ZSB0aGlzIHByb2JsZW0gYXMgb25seSBs ZWFmIGVudHJpZXMgY2FuIGJlDQo+cmVtb3ZlZC4gTERBUHYzIGJhc2ljIG9ubHkgYWxsb3dzIGxl YWYgZW50cmllcyB0byBiZSBkZWxldGVkLCBidXQNCj50aGVyZSB3YXMgdGFsayBvZiBoYXZpbmcg YW4gb3BlcmF0aW9uIHRvIGRlbGV0ZSBmdWxsIHN1YnRyZWVzLiBJIGRvbnQNCj5rbm93IHRoZSBz dGF0dXMgb2YgdGhpcywgZG8geW91Pw0KPg0KPkRhdmlkDQo+DQo+KioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+DQo+RGF2aWQgQ2hhZHdpY2sNCj5J UyBJbnN0aXR1dGUsIFVuaXZlcnNpdHkgb2YgU2FsZm9yZCwgU2FsZm9yZCBNNSA0V1QNCj5UZWwg KzQ0IDE2MSAyOTUgNTM1MSAgRmF4ICs0NCAxNjEgNzQ1IDgxNjkNCj5Nb2JpbGUgKzQ0IDc5MCAx NjcgMDM1OQ0KPkVtYWlsIEQuVy5DaGFkd2lja0BzYWxmb3JkLmFjLnVrDQo+SG9tZSBQYWdlICBo dHRwOi8vd3d3LnNhbGZvcmQuYWMudWsvaXRzMDI0L2NoYWR3aWNrLmh0bQ0KPlVuZGVyc3RhbmRp bmcgWC41MDAgIGh0dHA6Ly93d3cuc2FsZm9yZC5hYy51ay9pdHMwMjQvWDUwMC5odG0NCj5YLjUw MC9MREFQIFNlbWluYXJzIGh0dHA6Ly93d3cuc2FsZm9yZC5hYy51ay9pdHMwMjQvc2VtaW5hcnMu aHRtDQo+RW50cnVzdCBrZXkgdmFsaWRhdGlvbiBzdHJpbmcgTUxKOS1EVTVULUhWOEoNCj4NCj4q KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0K --0__=CcxkTHu1fKjmS4Y7oweTCiYAp49JAH9ZJpmTumk5R8kZ8DaFhftMuwZx-- From list@netscape.com Wed Jul 19 03:00:16 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03736 for ; Wed, 19 Jul 2000 03:00:15 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6J6qZU06005; Tue, 18 Jul 2000 23:52:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6J6vVs22346; Tue, 18 Jul 2000 23:57:31 -0700 (PDT) Resent-Date: Tue, 18 Jul 2000 23:57:31 -0700 (PDT) Message-ID: <00bb01bff1c8$ec6a35c0$1929b0cb@a0p6q3> From: "Fulfill Your Dreams" To: Subject: Make Cash Daily! Date: Wed, 19 Jul 2000 13:38:27 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B8_01BFF18E.400B5DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Resent-Message-ID: <"Bul_2D.A.zcF.aFVd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multi-part message in MIME format. ------=_NextPart_000_00B8_01BFF18E.400B5DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MAKE YOUR COMPUTER YOUR PERSONAL ATM MACHINE! You only need a few minutes to do this. Start Now!=20 =20 NOW, you can make $50 an hour through your computer. Newbies, = Professionals, anybody who has the desire can do this. It's so simple. = You can even start earning right now. YES RIGHT NOW! It will only take = you 40 minutes to set-up. START NOW! Just simply reply to this e-mail with Send More Info as the text and = we'll show you how simple it is. Thank you very much. BONG =20 * * * * * * * * * * * * * * * * * * * * * * * * = * * * * * * * * * =20 (NO SPAM) You Are Receiving This Mail Because We Either Had Contact = Before Or Your Name Appeared On A Safe E-Mail List That We Both Belong To, Or It Was On An Ad To Make Money And To Receive Money. If You Wish To Be Removed, Simply click the reply button and type REMOVE as text. If Offended You In Any Way Shape Or Form, Please Accept My Sincere Apology. ------=_NextPart_000_00B8_01BFF18E.400B5DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

 
 MAKE YOUR COMPUTER YOUR = PERSONAL=20 ATM MACHINE!
 You only need a few = minutes to=20 do this. Start Now!
 
 


NOW, you can make $50 an hour through your computer. = Newbies,=20 Professionals, anybody who has the desire can do this. It's so simple. = You can=20 even start earning right now. YES RIGHT NOW! It will only take you 40 = minutes to=20 set-up. START NOW!

Just simply reply to this e-mail with Send = More Info=20 as the text and we'll show you how simple it is.

Thank you very=20 much.

BONG
 
*  *  *  *  *  = * =20 *  *  *  *  *  *  *  *  *  = * =20 *  *  *  *  *  *  *  *  *  = * =20 *  *  *  *  *  *  * 

(NO = SPAM) =20 You Are Receiving This Mail Because We Either Had Contact Before Or Your = Name=20 Appeared On A Safe E-Mail List That
We Both Belong To, Or It Was On = An Ad To=20 Make Money And To
Receive Money.  If You Wish To Be Removed, = Simply=20 click the reply
button and type REMOVE as text. If Offended You In = Any Way=20 Shape
Or Form, Please Accept My Sincere = Apology.

------=_NextPart_000_00B8_01BFF18E.400B5DC0-- From list@netscape.com Wed Jul 19 04:42:42 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13116 for ; Wed, 19 Jul 2000 04:42:42 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6J8ZSU12814; Wed, 19 Jul 2000 01:35:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6J8eOs16065; Wed, 19 Jul 2000 01:40:24 -0700 (PDT) Resent-Date: Wed, 19 Jul 2000 01:40:24 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Date: Wed, 19 Jul 2000 18:42:58 +1000 Message-ID: <001801bff15d$5814bd70$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <4.3.2.7.0.20000714091302.00b48510@infidel.boolean.net> Resent-Message-ID: <"87dMcC.A.65D.1lWd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Kurt, > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Saturday, 15 July 2000 3:13 > To: ietf-ldapext@netscape.com > Subject: Re: I-D ACTION:draft-ietf-ldapext-refer-00.txt > > > Roland, [snip] > > 2.1 The refer attribute > > The refer attribute can be further specified by the use > of options as > > defined in section 4.1.5 of [RFC2251]. This document defines five > > options and their use. Future documents might defined > other options. > > Is an option required? If not, what is the semantics of an optionless > refer attribute? > > I also question this use of options. Are there better approaches? > I would suggest tieing the semantics of the attribute to object > classes and/or type of the DSE its contained in. That is, a refer > in the root dse is a superior reference, a refer in a referral > object (objectclass=referral) is a subordinate, etc.. I would rather not tie the semantics to the object class, for the sake of replication. If an entry is represented by its appropriate object class in one server and by an entry with one of the referral classes in another it presents a problem to any server replicating from both sources. What is the object class of the merged object ? Better if the referencing entry is a DSE with no object class, or has the same object class as the referenced entry. I'd prefer to use separate attributes instead of separate options to convey the semantics but that's not critical. Regards, Steven From list@netscape.com Wed Jul 19 11:40:06 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22082 for ; Wed, 19 Jul 2000 11:40:05 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6JFTIR21918; Wed, 19 Jul 2000 08:29:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6JFbso08769; Wed, 19 Jul 2000 08:37:54 -0700 (PDT) Resent-Date: Wed, 19 Jul 2000 08:37:54 -0700 (PDT) Message-Id: <4.3.2.7.0.20000719082822.00b199b0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2000 08:37:21 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Cc: In-Reply-To: <001801bff15d$5814bd70$b05508cb@osmium.adacel.com.au> References: <4.3.2.7.0.20000714091302.00b48510@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"ltSPsB.A.qIC.Qtcd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 06:42 PM 7/19/00 +1000, Steven Legg wrote: >Kurt, > >> -----Original Message----- >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >> Sent: Saturday, 15 July 2000 3:13 >> To: ietf-ldapext@netscape.com >> Subject: Re: I-D ACTION:draft-ietf-ldapext-refer-00.txt >> >> >> Roland, > >[snip] > >> > 2.1 The refer attribute >> > The refer attribute can be further specified by the use >> of options as >> > defined in section 4.1.5 of [RFC2251]. This document defines five >> > options and their use. Future documents might defined >> other options. >> >> Is an option required? If not, what is the semantics of an optionless >> refer attribute? >> >> I also question this use of options. Are there better approaches? >> I would suggest tieing the semantics of the attribute to object >> classes and/or type of the DSE its contained in. That is, a refer >> in the root dse is a superior reference, a refer in a referral >> object (objectclass=referral) is a subordinate, etc.. > >I would rather not tie the semantics to the object class, for the sake of >replication. If an entry is represented by its appropriate object class >in one server and by an entry with one of the referral classes in another >it presents a problem to any server replicating from both sources. >What is the object class of the merged object ? This would be a replication error as one server was not using standard track representation of the referral object. >Better if the referencing >entry is a DSE with no object class, My primary reason of suggesting use of object classes, especially for subordinate references, is that the semantics need to be established when the entry is instantiated. The DSE type associated with the object should be immutable. >or has the same object class as >the referenced entry. Then the object would be required to have all the required attributes of these classes. >I'd prefer to use separate attributes instead of separate options to convey >the semantics but that's not critical. This would at least remove the question "what are the semantics of an optionless 'refer' attribute?". From list@netscape.com Wed Jul 19 15:34:59 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03471 for ; Wed, 19 Jul 2000 15:34:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6JJOiR27575; Wed, 19 Jul 2000 12:24:45 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6JJXLo10207; Wed, 19 Jul 2000 12:33:21 -0700 (PDT) Resent-Date: Wed, 19 Jul 2000 12:33:21 -0700 (PDT) From: hahnt@us.ibm.com X-Priority: 3 (Normal) Importance: Normal Subject: Re: Discovering LDAP Services with DNS - draft-ietf-ldapext-locate-03.txt To: ietf-ldapext@netscape.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Wed, 19 Jul 2000 15:20:52 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.3.01 (Intl)|20 June 2000) at 19/07/2000 03:33:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"vueumB.A.TeC.-Jgd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Greetings, I have the following comments on the Internet Draft: Section 3, last sentence of second paragraph: text from draft: "If the final RDN component of the DN is not of type "DC" then the DN cannot be converted to a domain name." This sentence contradicts the example DN: "cn=John Doe, ou=accounting, dc=example, dc=net" since the "final RDN component" is "cn=John Doe" and thus not of type "DC". I would suggest that the wording of the sentence be modified to indicate that parsing the DNS name stops at the first RDN component (starting from the right) that is NOT of type "DC". That way, in the example, only: "dc=example, dc=net" is used to create "example.net". Section 4: What DN is then submitted to the LDAP server? Would it be the full DN: "cn=John Doe, ou=accounting, dc=example, dc=net" or the portion of the DN that was NOT used in locating the LDAP server instance (i.e. "cn=John Doe, ou=accounting" )? Additional comment: It might be nice to show mappings to LDAP URL formats as well as in: "cn=John Doe, ou=accounting, dc=example, dc=net" ==> ldap://example.net:389/cn=John Doe, ou=accounting, dc=example, dc=net or "cn=John Doe, ou=accounting, dc=example, dc=net" ==> ldap://phoenix.example.net:389/cn=John Doe, ou=accounting etc. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 From list@netscape.com Wed Jul 19 22:15:05 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28206 for ; Wed, 19 Jul 2000 22:15:05 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6K28dU15861; Wed, 19 Jul 2000 19:08:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6K2DaI08250; Wed, 19 Jul 2000 19:13:36 -0700 (PDT) Resent-Date: Wed, 19 Jul 2000 19:13:36 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Date: Thu, 20 Jul 2000 12:16:11 +1000 Message-ID: <000301bff1f0$79bdf340$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <4.3.2.7.0.20000719082822.00b199b0@infidel.boolean.net> Resent-Message-ID: <"rBGstC.A.hAC.OBmd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Kurt, > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, 20 July 2000 1:37 > To: steven.legg@adacel.com.au > Cc: ietf-ldapext@netscape.com > Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt > > > At 06:42 PM 7/19/00 +1000, Steven Legg wrote: > > >Kurt, > > > >> -----Original Message----- > >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > >> Sent: Saturday, 15 July 2000 3:13 > >> To: ietf-ldapext@netscape.com > >> Subject: Re: I-D ACTION:draft-ietf-ldapext-refer-00.txt > >> > >> > >> Roland, > > > >[snip] > > > >> > 2.1 The refer attribute > >> > The refer attribute can be further specified by the use > >> of options as > >> > defined in section 4.1.5 of [RFC2251]. This document > defines five > >> > options and their use. Future documents might defined > >> other options. > >> > >> Is an option required? If not, what is the semantics of > an optionless > >> refer attribute? > >> > >> I also question this use of options. Are there better approaches? > >> I would suggest tieing the semantics of the attribute to object > >> classes and/or type of the DSE its contained in. That is, a refer > >> in the root dse is a superior reference, a refer in a referral > >> object (objectclass=referral) is a subordinate, etc.. > > > >I would rather not tie the semantics to the object class, > for the sake of > >replication. If an entry is represented by its appropriate > object class > >in one server and by an entry with one of the referral > classes in another > >it presents a problem to any server replicating from both sources. > >What is the object class of the merged object ? > > > This would be a replication error as one server was not using > standard track representation of the referral object. That would be so if server A and server B both had references to some third server, but I was talking about the situation where server A masters the entry, server B has a reference to the entry in server A, and server C replicates from both server A and server B. Server A tells server C that the object class is say, organization, while server B tells server C that the object class is referral. Where a DSE is a placeholder for an entry that isn't held locally that DSE shouldn't contain shared information that contradicts the remote master entry. It's painful for replication if it does. > >Better if the referencing > >entry is a DSE with no object class, > > My primary reason of suggesting use of object classes, especially > for subordinate references, is that the semantics need to be > established when the entry is instantiated. The DSE type associated > with the object should be immutable. The DSEType is not immutable in X.500 and is also permitted to be different between servers having knowledge of the same DN. What is "glue" for one server will be "entry" for another and maybe "shadow" as well for a third. The semantics of the reference can be established just as well from the attribute type or from the attribute type and option. > > >or has the same object class as > >the referenced entry. > > Then the object would be required to have all the required attributes > of these classes. That depends on how you interpret clause 19 of X.501:1993. It might be legal for a DSE that is not of type "entry", "alias" or "subentry" to have an objectClass attribute without all the mandatory attributes. > > >I'd prefer to use separate attributes instead of separate > options to convey > >the semantics but that's not critical. > > This would at least remove the question "what are the semantics > of an optionless 'refer' attribute?". > > Regards, Steven From list@netscape.com Thu Jul 20 00:32:54 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18082 for ; Thu, 20 Jul 2000 00:32:54 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6K4LdR27955; Wed, 19 Jul 2000 21:21:40 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6K4UHA10048; Wed, 19 Jul 2000 21:30:17 -0700 (PDT) Resent-Date: Wed, 19 Jul 2000 21:30:17 -0700 (PDT) Message-Id: <4.3.2.7.0.20000719205804.00b10600@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2000 21:29:24 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Cc: In-Reply-To: <000301bff1f0$79bdf340$b05508cb@osmium.adacel.com.au> References: <4.3.2.7.0.20000719082822.00b199b0@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"4FmWDC.A.pcC.XBod5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 12:16 PM 7/20/00 +1000, Steven Legg wrote: >> >> Is an option required? If not, what is the semantics of >> an optionless >> >> refer attribute? No answer to this yet. >> >> I also question this use of options. Are there better approaches? > >That would be so if server A and server B both had references to some >third server, but I was talking about the situation where server A >masters the entry, server B has a reference to the entry in server A, >and server C replicates from both server A and server B. Server A tells >server C that the object class is say, organization, while server B tells >server C that the object class is referral. Yes, this is quite different. This requires C to maintain clear separation of information which A is authority over and information which B is authority over and to restrict updates to accordingly. >Where a DSE is a placeholder for an entry that isn't held locally that >DSE shouldn't contain shared information that contradicts the remote >master entry. It's painful for replication if it does. The proposal suggests using named entries to representing references. For a subordinate reference, it proposes that this object have an attributes associates with naming, object class referral, and object class extensible object. This information my be in contradiction with the actual entry DSE it refers to. When DSE are replicated, receiving server must have a clear mechanism for determining the update is associated with the portion of the DSE. I've suggested one approach, there are others. >> My primary reason of suggesting use of object classes, especially >> for subordinate references, is that the semantics need to be >> established when the entry is instantiated. This is my primary concern. I am not sure it makes sense to change an entry into an subordinate reference just by adding a 'refer' attribute. I believe you should have to delete the entry and add a 'referral' entry. I also think that a 'referral' entry MUST have a 'refer' attribute. >The DSEType is not immutable in X.500 Correct, I should have said that DSEtype is not modifiable by the user. The implication is that certain DSEtype changes make little (or no) sense and using the presence or lack of presence of an attribute type (or types) to indicate such may not be optimal. >That depends on how you interpret clause 19 of X.501:1993. It might be >legal for a DSE that is not of type "entry", "alias" or "subentry" to >have an objectClass attribute without all the mandatory attributes. The proposal models references as entries, with object classes, with RDN attributes, with musts/may requirements. From list@netscape.com Thu Jul 20 01:12:56 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04022 for ; Thu, 20 Jul 2000 01:12:56 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6K52eR00255; Wed, 19 Jul 2000 22:02:40 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6K5BHM19189; Wed, 19 Jul 2000 22:11:17 -0700 (PDT) Resent-Date: Wed, 19 Jul 2000 22:11:17 -0700 (PDT) Message-Id: <3.0.5.32.20000719220417.008f5b50@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 19 Jul 2000 22:04:17 -0700 To: ietf-ldapext@netscape.com From: Bruce Greenblatt Subject: updated draft on subtree operations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"c-u31D.A.crE.0nod5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I have gotten several request to submit an updated version of my subtree operations draft. So, I did. I understand that the I-D people are not accepting things right now, but you can get it from my website here: http://www.directory-applications.com/drafts/sos-01.out. I added an introductory requirements section, and used real OIDs instead of fake ones... No other changes that I know of... Thanks, Bruce ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html From list@netscape.com Thu Jul 20 01:13:04 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04106 for ; Thu, 20 Jul 2000 01:13:03 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6K52vR00445; Wed, 19 Jul 2000 22:02:57 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6K5BYA19613; Wed, 19 Jul 2000 22:11:34 -0700 (PDT) Resent-Date: Wed, 19 Jul 2000 22:11:34 -0700 (PDT) Message-Id: <3.0.5.32.20000719220855.00923100@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 19 Jul 2000 22:08:55 -0700 To: "Ramsay, Ron" , Ellen Stokes , d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com From: Bruce Greenblatt Subject: RE: delete permission In-Reply-To: <11981F9F5649D411BC92009027D0D18C69868F@aspams01.cai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"HKfiHB.A.dxE.Eood5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 12:10 PM 7/19/2000 +1000, Ramsay, Ron wrote: >Hi, > >It will always be possible for a client to recursively delete the subtree >using the usual delete of a leaf. Access controls, as discussed on this >thread, will still apply and have the expected outcome. > >Ron. > While this is certainly the case, in the previous discussion on this issue from last year, it was not agreed that the semantics of a subtree delete were identical to the semantics of a series of "atomic" delete operations due to access control issues. There was some feeling that you would not necessarily want the subtree delete operation to be partially successful. I.e., if you couldn't delete all of the entries in the subtree, then no entries in the subtree were to be deleted. Bruce ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html From list@netscape.com Thu Jul 20 01:37:51 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20478 for ; Thu, 20 Jul 2000 01:37:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6K5TTU28284; Wed, 19 Jul 2000 22:29:29 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6K5YQE24996; Wed, 19 Jul 2000 22:34:26 -0700 (PDT) Resent-Date: Wed, 19 Jul 2000 22:34:26 -0700 (PDT) Message-Id: <4.3.2.7.0.20000719222648.00b0a260@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2000 22:34:02 -0700 To: Bruce Greenblatt From: "Kurt D. Zeilenga" Subject: RE: delete permission Cc: "Ramsay, Ron" , Ellen Stokes , d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com In-Reply-To: <3.0.5.32.20000719220855.00923100@pop.walltech.com> References: <11981F9F5649D411BC92009027D0D18C69868F@aspams01.cai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"pdoOpD.A.NGG.g9od5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 10:08 PM 7/19/00 -0700, Bruce Greenblatt wrote: >While this is certainly the case, in the previous discussion on this issue >from last year, it was not agreed that the semantics of a subtree delete >were identical to the semantics of a series of "atomic" delete operations >due to access control issues. There was some feeling that you would not >necessarily want the subtree delete operation to be partially successful. >I.e., if you couldn't delete all of the entries in the subtree, then no >entries in the subtree were to be deleted. Another issue for subtree deletion is handling of subordinate references with in the subtree. In particular, are delete continuations returned to the client? if so, how? Are there ManageDSAit control issues? Etc. Kurt From list@netscape.com Thu Jul 20 06:47:40 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12518 for ; Thu, 20 Jul 2000 06:47:39 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6KAfHU13512; Thu, 20 Jul 2000 03:41:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6KAkDE24159; Thu, 20 Jul 2000 03:46:13 -0700 (PDT) Resent-Date: Thu, 20 Jul 2000 03:46:13 -0700 (PDT) Message-Id: <200007201046.GAA11573@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-acl-model-06.txt Date: Thu, 20 Jul 2000 06:46:07 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"Mk8blB.A.x4F.zhtd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : Access Control Model for LDAP Author(s) : E. Stokes, B. Blakley, D. Rinkevich, D. Byrne Filename : draft-ietf-ldapext-acl-model-06.txt Pages : 42 Date : 19-Jul-00 This document describes the access control model for the Lightweight Directory Application Protocol V3 (LDAPv3) directory service. It includes a description of the model, the LDAP controls, and the extended operations to the LDAP protocol. The current LDAP APIs are sufficient for most access control operations. An API (in a separate document) is needed for the extended operation getEffectiveAccess. A separate requirements document for access control exists [REQTS]. The access control model used the requirements documents as a guideline for the development of this specification and are reflected in this specification to the extent that the working group could agree on an access control model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapext-acl-model-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapext-acl-model-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000719141402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-acl-model-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-acl-model-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000719141402.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Thu Jul 20 08:20:29 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01161 for ; Thu, 20 Jul 2000 08:20:27 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6KCCtU18045; Thu, 20 Jul 2000 05:12:56 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6KCHq212633; Thu, 20 Jul 2000 05:17:52 -0700 (PDT) Resent-Date: Thu, 20 Jul 2000 05:17:52 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 20 Jul 2000 05:29:19 -0600 From: "Haripriya S" To: "<" Subject: Re: I-D ACTION:draft-ietf-ldapext-acl-model-06.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_144C56DE.7F1E76B3" Resent-Message-ID: <"jk9wUC.A.OED.t3ud5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_144C56DE.7F1E76B3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable In the current model of ACL I cannot find how to actually set ACLs for a = 'to be created entry' based on its objectClass. For example, I may want a = set of ACLs to be present for all the objects of type inetorgperson, to = expose certain attributes by default to even an unauthenticated user. It = would help in this case, if I have mechanism's to set ACLs for the = objectclass itself, so that any entry of that class created automatically = gets these ACLs. The other alternative would be for me to set these ACLs = at one parent with scope subtree and let all the entries under that parent = inherit these ACLs. But this would not let me distinguish by objectclass ( = I may want to expose cn for inetorgperson but not for residentialperson by = default). Does anybody have ideas on this? Thanks and Regards, Haripriya --=_144C56DE.7F1E76B3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In the current model of ACL I cannot find how to actually set ACLs = for a=20 'to be created entry' based on its objectClass. For example, I may want a = set of=20 ACLs to be present for all the objects of type inetorgperson, to expose = certain=20 attributes by default to even an unauthenticated user. It would help in = this=20 case, if I have mechanism's to set ACLs for the objectclass itself, so = that any=20 entry of that class created automatically gets these ACLs. The other = alternative=20 would be for me to set these ACLs at one parent with scope subtree = and let=20 all the entries under that parent inherit these ACLs. But this would not = let me=20 distinguish by objectclass ( I may want to expose cn for inetorgperson but = not=20 for residentialperson by default). Does anybody have ideas on = this?
 
Thanks and Regards,
Haripriya
 
--=_144C56DE.7F1E76B3-- From list@netscape.com Thu Jul 20 10:50:35 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20771 for ; Thu, 20 Jul 2000 10:50:30 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6KEeLR04664; Thu, 20 Jul 2000 07:40:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6KEmxg18828; Thu, 20 Jul 2000 07:48:59 -0700 (PDT) Resent-Date: Thu, 20 Jul 2000 07:48:59 -0700 (PDT) Message-Id: <4.2.2.20000720085542.00a5a810@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jul 2000 09:47:50 -0500 To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com From: Ellen Stokes Subject: Re: Typos, bugs, clarifications for ACI draft (ii, vii) In-Reply-To: <39738FDB.3106.3146556@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"zqpdRC.A.3lE.ZFxd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David, Much of the power / ease of use provided in the access control model is by granting large numbers of people a given set of permission based on a single ACI. 'public' is a good example of this. The second thing that is very powerful is the ability to give someone permission to their own entry by placing a single ldapACI value using 'this' in the tree. So, when we look at the subject precedence order we must include 'this' and 'public' and define where they fit. We've stated that more specific takes precedence over less specific, processing stops when ldapaci values for a given specificity level. 'This' applies to a single DN at a time ( that which matches the entry DN ) and therefore, fits in well with authzID which also applies to a single logical DN. Different from a group which is many member DNs ) In order to take full advantage of the pseudo-DNs they need to apply to multiple levels. An example using 'this' : ldapACI: group RegDeptMembers has rs perms to telephone and rs to secureDocs. THIS has w perm telephone authzID guest has rs to telephone Where we have an organization, and this ACI is on the dept node, and each person in the dept is a child of the dept node. We want all dept members to be able to read each other's telephone numbers, but only update their own. We also have a visiting guest for the month who is not a dept member but should have access to telephone numbers. If 'this' is the same precedence as authz-ID; User guest would come in a receive permission to read everything and have write access to his own entry. However, the rest of the dept would be able to read everything on each other's entries, but processing for their own entry would not be as desired. They would receive 'w' for telephone by virtue of 'this' but processing would stop because 'this' is a higher precedence then group. So, they could change their phone number, but not read it. If 'this' is the same precedence as group, then the opposite happens. All dept members can read everyone's phone number and update their own. However, the guest can not update his phone number. Processing would stop after finding that he matched on the authz level for guest, and he would not receive the permission to update his own phone number, since that is granted by 'this' which is at the group level. So, really, in order to really use the power that comes with the concept of 'this' it really needs to be combined with either groups or authZids and that by itself, it should not stop processing due to precedence. The same type of thing is true with the 'public' pseudoDN. ellen At 10:59 PM 7/17/00 +0100, David Chadwick wrote: >Ellen > >could you clarify a few points for me please > >ii) 4.3 precedence of subjects has public in the bottom 2 levels and >this in the middle two levels. Can you explain this to me please. > >vii) section 4.3, step 2. what does 'this may also be combined with >group to use the power of "this"' mean. Sorry to be dumb. > > >David > >*************************************************** > >David Chadwick >IS Institute, University of Salford, Salford M5 4WT >Tel +44 161 295 5351 Fax +44 161 745 8169 >Mobile +44 790 167 0359 >Email D.W.Chadwick@salford.ac.uk >Home Page http://www.salford.ac.uk/its024/chadwick.htm >Understanding X.500 http://www.salford.ac.uk/its024/X500.htm >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm >Entrust key validation string MLJ9-DU5T-HV8J > >*************************************************** From list@netscape.com Thu Jul 20 12:45:56 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19570 for ; Thu, 20 Jul 2000 12:45:55 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6KGdSU08435; Thu, 20 Jul 2000 09:39:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6KGiQ209656; Thu, 20 Jul 2000 09:44:26 -0700 (PDT) Resent-Date: Thu, 20 Jul 2000 09:44:26 -0700 (PDT) Date: Thu, 20 Jul 2000 09:44:19 -0700 (PDT) Message-Id: <200007201644.e6KGiJw00420@xwing.netscape.com> From: bfsusan@ISYG.yahoo.com To: ietf-ldapext@YOBO.netscape.com Subject: Yes, you can earn $5,935 per month without spending anything. -UWNN X-Reply-To: shapip@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"PwcbzC.A.GWC.nxyd5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hello, I just like to invite you to register for this new program. The registration is FREE and you will never have to pay anything in the future either. Your FREE registration will let you earn a stable monthly income that can ONLY GROW! Yes, you can earn $5,935 per month without spending anything. If you're interested, mail to shapip@yahoo.com with MOREINFO in the Subject Line. Sincerely, T. Ried Please pardon the intrusion.... Under Bill s.1618 TITLE III passed by the 105th US Congress this letter can not be considered Spam as long as the sender includes contact information & a method of "removal". To be removed from future mailings just reply with REMOVE in the subject line. Thank you for your kind consideration. From list@netscape.com Thu Jul 20 16:20:54 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10599 for ; Thu, 20 Jul 2000 16:20:50 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6KKA6R23126; Thu, 20 Jul 2000 13:10:07 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6KKIjU17748; Thu, 20 Jul 2000 13:18:45 -0700 (PDT) Resent-Date: Thu, 20 Jul 2000 13:18:45 -0700 (PDT) Message-Id: <4.3.2.7.0.20000720123032.00b28100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 13:18:27 -0700 To: "Michael Armijo" From: "Kurt D. Zeilenga" Subject: Re: Discovering LDAP Services with DNS - draft-ietf-ldapext-locate-03.txt Cc: In-Reply-To: <96BABA22ECEAEA45B53D08D63E1B5678527F97@DF-SPIKE.platinum.c orp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"YvZjtB.A.iUE.j61d5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Michael, The I-D is shaping up nicely, a couple of comments: Multiple SRV records I believe you state that listed services under a give domain name provided must be "equally capable of servicing LDAP requests" under the associated DN (suggest using wording similar to that in RFC2251, 4.1.11). FQDN: I noticed the specification now has trailing dots on FQDNs. This may be inappropriate. IIRC, the trailing dot is a user interface convention and not part of the actual DNS protocol itself. Tree Walking SHOULD v MUST? It may be appropriate to make this a MUST. If walking were allowed, a significant burden would placed upon superior DNS zones. And, if done without user interaction, may expose the client to unintended servers creating a privacy concern. Verification of intended services Should there be a note that DNS provided information is easily spoofed and the client may desire to check naming contexts of listed servers (when possible) using LDAP mechanisms (noting that TCP sessions are much harder to spoof than UDP PDU). Security Considerations You refer the reader to [6]: [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. which doesn't discuss considerations. I assume you meant [5]. As noted above, there may be additional security concerns specific to LDAP use of [5]. A more detailed analysis may be appropriate. CLDAP As previously noted, the I-D includes a normative reference to CLDAP. This will couple the progression of specification to maturity levels of both LDAP and CLDAP protocols. From list@netscape.com Thu Jul 20 17:27:10 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13384 for ; Thu, 20 Jul 2000 17:27:09 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6KLGrR02650; Thu, 20 Jul 2000 14:16:53 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6KLPWI14426; Thu, 20 Jul 2000 14:25:32 -0700 (PDT) Resent-Date: Thu, 20 Jul 2000 14:25:32 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: bgreenblatt@directory-applications.com, Ellen Stokes Date: Thu, 20 Jul 2000 22:24:12 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: delete permission Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <39777C0C.3873.5C6CB59@localhost> Priority: normal In-reply-to: <4.2.2.20000718165021.00a38d00@popmail2.austin.ibm.com> References: <3974A013.24741.73B9E49@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"WWUyID.A.4fD.H52d5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date sent: Tue, 18 Jul 2000 16:55:52 -0500 To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com, bgreenblatt@directory-applications.com From: Ellen Stokes Subject: Re: delete permission > David / Bruce, > > I think the ldap model should use delete in the X.500 sense - the > object must be a leaf entry. agreed > > However, subtree delete becomes interesting if/when we decide to > surface the scope of ACI (entry/subtree) via your entryACI / > subtreeACI proposal. At that point in time, then the expired subtree > drafts become interesting because you have a way actually invoke the > subtree operation and apply access control to the operation. > Unless I have misunderstood the current model, or you have misunderstood my proposal, I think the separation out of subtree ACI into a separate attribute type is irrelevant to the subtree delete operation. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Jul 20 17:32:58 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16708 for ; Thu, 20 Jul 2000 17:32:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6KLOqU00908; Thu, 20 Jul 2000 14:24:53 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6KLToM17443; Thu, 20 Jul 2000 14:29:50 -0700 (PDT) Resent-Date: Thu, 20 Jul 2000 14:29:50 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: ietf-ldapext@netscape.com Date: Thu, 20 Jul 2000 22:28:46 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Typos, bugs, clarifications for ACI draft (ii, vii) Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <39777D1E.8636.5CAFA64@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"CT78ZD.A.KQE.M92d5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT From: Ellen Stokes Subject: Re: Typos, bugs, clarifications for ACI draft (ii, vii) Forwarded by: ietf-ldapext@netscape.com > David, > > Much of the power / ease of use provided in the access > control model is by granting large numbers of people a > given set of permission based on a single ACI. 'public' > is a good example of this. The second thing that is very > powerful is the ability to give someone permission to > their own entry by placing a single ldapACI value using > 'this' in the tree. Absolutely agree > > So, when we look at the subject precedence order we must > include 'this' and 'public' and define where they fit. > We've stated that more specific takes precedence over less > specific, processing stops when ldapaci values for a given > specificity level. this is where you have an omission in your processing model. It should read processing stops when an ldapaci value for a sought permission is found in the highest specificity level. You seem to stop when ANY permission is hit, regardless of whether it is the correct one or not. Thus specificity should be ipAddress>authzID>role>this>group>subtree>public. I will show you how this works in the examples below >'This' applies to a single DN at a time > ( that which matches the entry DN ) and therefore, fits in > well with authzID which also applies to a single logical DN. > Different from a group which is many member DNs ) > > > In order to take full advantage of the pseudo-DNs they need > to apply to multiple levels. An example using 'this' : > ldapACI: group RegDeptMembers has rs perms to telephone and > rs to secureDocs. > THIS has w perm telephone > authzID guest has rs to telephone > > Where we have an organization, and this ACI is on the dept > node, and each person in the dept is a child of the dept node. > We want all dept members to be able to read each other's > telephone numbers, but only update their own. We also have a > visiting guest for the month who is not a dept member but > should have access to telephone numbers. > > If 'this' is the same precedence as authz-ID; > User guest would come in a receive permission to read > everything and have write access to his own entry. > However, the rest of the dept would be able to read > everything on each other's entries, but processing > for their own entry would not be as desired. They would > receive 'w' for telephone by virtue of 'this' but > processing would stop because 'this' is a higher precedence > then group. So, they could change their phone number, > but not read it. > This is where the bug in your processing model hits you. As a group member is authorised, and you move down the precedence list you hit "this" first which gives you w access. But it says nothing about r access so if the operation is a read or search, you must move down the precedence list until you come to group, and then you get your r access. Then you stop. > If 'this' is the same precedence as group, then the > opposite happens. All dept members can read everyone's > phone number and update their own. However, the guest > can not update his phone number. Processing would stop > after finding that he matched on the authz level for > guest, and he would not receive the permission to update > his own phone number, since that is granted by 'this' > which is at the group level. > Same bug again. If Guest is doing a read, then processing stops on authz as this covers read, but if he is doing a write access authz has nothing to say about this, so you go to the next level "this" which says he can write. Then you stop processing. > So, really, in order to really use the power that comes > with the concept of 'this' it really needs to be combined > with either groups or authZids and that by itself, it > should not stop processing due to precedence. > this should stop processing if it contains the relevant permission, otherwise it should not stop it. The other problem you have is that you are treating the omission of some permission as a deny i.e. I grant r, so I am automatically denying everything else. True, but this deny is at the lowest precedence of all, since it is implicit. Explicit grants must always override implicit denies, no matter what the precedence level of the grant. David > The same type of thing is true with the 'public' pseudoDN. > > ellen > > > > At 10:59 PM 7/17/00 +0100, David Chadwick wrote: > >Ellen > > > >could you clarify a few points for me please > > > >ii) 4.3 precedence of subjects has public in the bottom 2 levels > >and this in the middle two levels. Can you explain this to me > >please. > > > >vii) section 4.3, step 2. what does 'this may also be combined with > >group to use the power of "this"' mean. Sorry to be dumb. > > > > > >David > > > >*************************************************** > > > >David Chadwick > >IS Institute, University of Salford, Salford M5 4WT > >Tel +44 161 295 5351 Fax +44 161 745 8169 > >Mobile +44 790 167 0359 > >Email D.W.Chadwick@salford.ac.uk > >Home Page http://www.salford.ac.uk/its024/chadwick.htm > >Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > >Entrust key validation string MLJ9-DU5T-HV8J > > > >*************************************************** > > ------- End of forwarded message ------- *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Jul 20 17:33:10 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16788 for ; Thu, 20 Jul 2000 17:33:09 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6KLQlU01691; Thu, 20 Jul 2000 14:26:48 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6KLQ5Q15285; Thu, 20 Jul 2000 14:26:05 -0700 (PDT) Resent-Date: Thu, 20 Jul 2000 14:26:05 -0700 (PDT) Message-Id: <4.2.2.20000720162123.00a4a830@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jul 2000 16:25:26 -0500 To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com From: Ellen Stokes Subject: Re: Clarification of "[all]" and "[entry]" In-Reply-To: <39738FDB.30514.31461B9@localhost> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Resent-Message-ID: <"hZEKQ.A.xtD.q52d5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David,
Responses embedded below...
Ellen

At 10:59 PM 7/17/00 +0100, David Chadwick wrote:
Ellen

could you clarify the meaning of the keywords "[all]" and "[entry"]
please for attributes. The ID states:

"[all]" means the permission set apply to all attributes of
the entry.

What is the meaning of the above if the scope is subtree?

(EJS) The permission set associated with "[all]"
applies to all attributes of each entry in the
subtree.

What if the permission set comprises n,b and t only?

(EJS) These permissions apply only to entries, not
attributes.  So specification of them in this
context is invalid (we need to update the BNF to
reflect this.


[entry] means the permissions apply to the entire object.

What is the meaning if the scope is subtree?

(EJS) The specified permissions apply to each entry
in the subtree.  Recall that only certain permissions
can be applied to the entire entry (we need to update
the BNF to reflect this).


What if the permission set comprises r, w and o only?

(EJS) These permissions apply only to attributes, so
can only be used with "[all]" or specifically listed
attribute(s).  (we need to update the BNF to reflect
this).

If fact is there any purpose of the keyword [entry] at all given that
we have entry level permissions?

(EJS) It helps focus the permissions to either entry or
attribute quickly and and for clarification and ease of
parsing.



David


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************
From list@netscape.com Thu Jul 20 17:54:27 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26297 for ; Thu, 20 Jul 2000 17:54:27 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6KLm1U05656; Thu, 20 Jul 2000 14:48:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6KLqwY25421; Thu, 20 Jul 2000 14:52:58 -0700 (PDT) Resent-Date: Thu, 20 Jul 2000 14:52:58 -0700 (PDT) Message-Id: <200007202152.e6KLqfM08361@ywing.netscape.com> From: Subject: New List 7-19-00! Date: Thu, 20 Jul 2000 13:16:00 Resent-Message-ID: <"4VGo3.A.2MG.4S3d5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com *******New List 7-19-00!!******** The key to success in marketing online is reaching the people who are really interested in your ad! You need targeted e-mails of business opportunity seekers who are ACTIVELY marketing online and trying to expand their business TODAY! These are going to be the lowest prices for deliverable, fresh, opportunity seekers you are going to find anywhere! We strive to clean our lists on a DAILY basis! http://www.homepagez.com/bpencil 10,000 opportunity seekers e-mails for only $15 **New List 7-19-00** 25,000 opportunity seekers e-mails for only $20 50,000 opportunity seekers e-mails for only $35 100,000 opportunity seekers e-mails for only $50 170,000 opportunity seekers e-mails for only $70 - Promotions! **FREE with EVERY order, demo of ListMan e-mail manager software to manage your e-mails list and Credit Helper E-book with Links to Guaranteed Visa's and MC's! **Order 50,000 or more e-mails and receive Express Mail Server to send your e-mails FREE! -Send your e-mails safely bypassing your ISP's mail server! -This is not a demo but a permanent license for the software! **Order 100,000 or more e-mails and receive, CheckMAN software to accept checks online, by phone, or fax, and InfoDisk with 1000+ Money Making Reports. An $80 value yours FREE! _______________________________________________________________ I received your e-mail as someone interested in Internet Business Opportunities. If I received your e-mail in error, or you are no longer interested, please reply with "remove" in the subject. _________________________________________________________________ From list@netscape.com Fri Jul 21 01:46:52 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09942 for ; Fri, 21 Jul 2000 01:46:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6L5aeR25322; Thu, 20 Jul 2000 22:36:40 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6L5jJI02116; Thu, 20 Jul 2000 22:45:19 -0700 (PDT) Resent-Date: Thu, 20 Jul 2000 22:45:19 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Date: Fri, 21 Jul 2000 15:47:58 +1000 Message-ID: <000901bff2d7$3a4d0600$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <4.3.2.7.0.20000719205804.00b10600@infidel.boolean.net> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Resent-Message-ID: <"U1UM3.A.vg.uN-d5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Kurt, > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, 20 July 2000 14:29 > To: steven.legg@adacel.com.au > Cc: ietf-ldapext@netscape.com > Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt > > > At 12:16 PM 7/20/00 +1000, Steven Legg wrote: > >> >> Is an option required? If not, what is the semantics of > >> an optionless > >> >> refer attribute? > > No answer to this yet. I thought that was a question for Roland, but if you want my opinion, it doesn't mean anything. Optionless refer attributes are ignored. > >That would be so if server A and server B both had references to some > >third server, but I was talking about the situation where server A > >masters the entry, server B has a reference to the entry in server A, > >and server C replicates from both server A and server B. > Server A tells > >server C that the object class is say, organization, while > server B tells > >server C that the object class is referral. > > Yes, this is quite different. This requires C to maintain clear > separation of information which A is authority over and information > which B is authority over and to restrict updates to accordingly. You're sort of progressing down the path of X.525's planes of information, which is fine for single master replication but isn't meaningful in a multi-master environment where servers have joint authority over shared data. There really needs to be only one version of the shared data for multi-master replication. > > >Where a DSE is a placeholder for an entry that isn't held > locally that > >DSE shouldn't contain shared information that contradicts the remote > >master entry. It's painful for replication if it does. > > The proposal suggests using named entries to representing references. > For a subordinate reference, it proposes that this object have > an attributes associates with naming, object class referral, and > object class extensible object. This information my be in > contradiction with the actual entry DSE it refers to. > > When DSE are replicated, receiving server must have a clear > mechanism for determining the update is associated with the > portion of the DSE. I've suggested one approach, there are others. To be replication friendly, information in a DSE that is different from one server to another needs to be in DSA-specific attributes if it is reflected in any attributes at all. In X.500 the specialness of DSEs containing references to other DSAs is captured in the dseType, a DSA-specific operational attribute. It looks to me that LDAP needs something like it, though in this case the refer attribute itself would be enough. Roland's description of the processing that takes place depends only on the presence of the refer attribute. The object class of the entry containing the refer attribute doesn't get a mention that I could see. The definition of the referral object class near the end is pretty much incidental. > > >> My primary reason of suggesting use of object classes, especially > >> for subordinate references, is that the semantics need to be > >> established when the entry is instantiated. > > This is my primary concern. I am not sure it makes sense > to change an entry into an subordinate reference just by > adding a 'refer' attribute. I believe you should have to > delete the entry and add a 'referral' entry. I also think > that a 'referral' entry MUST have a 'refer' attribute. If you add a refer attribute to an existing entry then the other attributes in the entry become meaningless and might as well be removed. An LDAP DSE type attribute would help if you feel there is a need to make a more emphatic display of the fundamental change in the nature of the DSE. With LDUP it would be possible for a replica to hold both the actual entry contents and the refer attribute, which is basically what you get if you just add a refer attribute to an existing entry. We would need to define what that means. A refer attribute in a read-only replica is effectively a reference to the server(s) holding the master entry. Whether you send back a referral in this case would depend on things like the X.500 dontUseCopy service control. A refer attribute in a writeable replica could be a self-reference to the server or a reference to one of the other mastering servers for that entry. In either case the refer attribute is ignored. Anything else is processed as Roland describes. > > >The DSEType is not immutable in X.500 > > Correct, I should have said that DSEtype is not modifiable by the > user. Not directly, but user actions can affect the DSEType. For example, adding/removing the administrativeRole attribute changes the admPoint bit in the DSEType. > > The implication is that certain DSEtype changes make little > (or no) sense and using the presence or lack of presence of > an attribute type (or types) to indicate such may not be > optimal. Do I take this to mean that you like the fact that an object class definition mandates what can and can't be in a referral DSE? There are other ways to do that, like writing down the requirements, which is how X.500 deals with the permitted usage of most of the operational attributes. Regards, Steven > > >That depends on how you interpret clause 19 of X.501:1993. > It might be > >legal for a DSE that is not of type "entry", "alias" or "subentry" to > >have an objectClass attribute without all the mandatory attributes. > > The proposal models references as entries, with object classes, > with RDN attributes, with musts/may requirements. > > From list@netscape.com Fri Jul 21 02:40:04 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17532 for ; Fri, 21 Jul 2000 02:40:04 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6L6VOU02163; Thu, 20 Jul 2000 23:31:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6L6aMM12628; Thu, 20 Jul 2000 23:36:22 -0700 (PDT) Resent-Date: Thu, 20 Jul 2000 23:36:22 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C74114A@aspams01.cai.com> From: "Ramsay, Ron" To: steven.legg@adacel.com.au, "'Kurt D. Zeilenga'" Cc: ietf-ldapext@netscape.com Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Date: Fri, 21 Jul 2000 16:36:23 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"Kd7nvB.A.sED.l9-d5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hi, I'm having trouble following the bit about replicating the refer attribute. I agree that it should be a DSA-specific attribute. But my conclusion would be that it *cannot* be replicated. I suppose, under master-slave replication, you could specify that all entries are copied verbatim (though the refer attribute may now point to a DSA which is no longer, eg, local), but for master-master replication there would seem to be no situation in which the attribute can be replicated. (I should have given a long-sentence alert!) In multi-master replication, presumably one of the replicas has the actual entry. If this entry is updated, the updates will be sent to the other masters, so they now have (parts of) the whole entry. The refer attribute now seems to be out-of-place? I should think the entry itself is DSA-specific! Note that, if NSSRs are retained, the NSSR will actually be carried in a real entry. I think this complicates Steven's argument. (I found the draft a bit unsatisfactory in the area of NSSRs.) Ron. -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Friday, 21 July 2000 15:48 To: 'Kurt D. Zeilenga' Cc: ietf-ldapext@netscape.com Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Kurt, > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, 20 July 2000 14:29 > To: steven.legg@adacel.com.au > Cc: ietf-ldapext@netscape.com > Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt > > > At 12:16 PM 7/20/00 +1000, Steven Legg wrote: > >> >> Is an option required? If not, what is the semantics of > >> an optionless > >> >> refer attribute? > > No answer to this yet. I thought that was a question for Roland, but if you want my opinion, it doesn't mean anything. Optionless refer attributes are ignored. > >That would be so if server A and server B both had references to some > >third server, but I was talking about the situation where server A > >masters the entry, server B has a reference to the entry in server A, > >and server C replicates from both server A and server B. > Server A tells > >server C that the object class is say, organization, while > server B tells > >server C that the object class is referral. > > Yes, this is quite different. This requires C to maintain clear > separation of information which A is authority over and information > which B is authority over and to restrict updates to accordingly. You're sort of progressing down the path of X.525's planes of information, which is fine for single master replication but isn't meaningful in a multi-master environment where servers have joint authority over shared data. There really needs to be only one version of the shared data for multi-master replication. > > >Where a DSE is a placeholder for an entry that isn't held > locally that > >DSE shouldn't contain shared information that contradicts the remote > >master entry. It's painful for replication if it does. > > The proposal suggests using named entries to representing references. > For a subordinate reference, it proposes that this object have > an attributes associates with naming, object class referral, and > object class extensible object. This information my be in > contradiction with the actual entry DSE it refers to. > > When DSE are replicated, receiving server must have a clear > mechanism for determining the update is associated with the > portion of the DSE. I've suggested one approach, there are others. To be replication friendly, information in a DSE that is different from one server to another needs to be in DSA-specific attributes if it is reflected in any attributes at all. In X.500 the specialness of DSEs containing references to other DSAs is captured in the dseType, a DSA-specific operational attribute. It looks to me that LDAP needs something like it, though in this case the refer attribute itself would be enough. Roland's description of the processing that takes place depends only on the presence of the refer attribute. The object class of the entry containing the refer attribute doesn't get a mention that I could see. The definition of the referral object class near the end is pretty much incidental. > > >> My primary reason of suggesting use of object classes, especially > >> for subordinate references, is that the semantics need to be > >> established when the entry is instantiated. > > This is my primary concern. I am not sure it makes sense > to change an entry into an subordinate reference just by > adding a 'refer' attribute. I believe you should have to > delete the entry and add a 'referral' entry. I also think > that a 'referral' entry MUST have a 'refer' attribute. If you add a refer attribute to an existing entry then the other attributes in the entry become meaningless and might as well be removed. An LDAP DSE type attribute would help if you feel there is a need to make a more emphatic display of the fundamental change in the nature of the DSE. With LDUP it would be possible for a replica to hold both the actual entry contents and the refer attribute, which is basically what you get if you just add a refer attribute to an existing entry. We would need to define what that means. A refer attribute in a read-only replica is effectively a reference to the server(s) holding the master entry. Whether you send back a referral in this case would depend on things like the X.500 dontUseCopy service control. A refer attribute in a writeable replica could be a self-reference to the server or a reference to one of the other mastering servers for that entry. In either case the refer attribute is ignored. Anything else is processed as Roland describes. > > >The DSEType is not immutable in X.500 > > Correct, I should have said that DSEtype is not modifiable by the > user. Not directly, but user actions can affect the DSEType. For example, adding/removing the administrativeRole attribute changes the admPoint bit in the DSEType. > > The implication is that certain DSEtype changes make little > (or no) sense and using the presence or lack of presence of > an attribute type (or types) to indicate such may not be > optimal. Do I take this to mean that you like the fact that an object class definition mandates what can and can't be in a referral DSE? There are other ways to do that, like writing down the requirements, which is how X.500 deals with the permitted usage of most of the operational attributes. Regards, Steven > > >That depends on how you interpret clause 19 of X.501:1993. > It might be > >legal for a DSE that is not of type "entry", "alias" or "subentry" to > >have an objectClass attribute without all the mandatory attributes. > > The proposal models references as entries, with object classes, > with RDN attributes, with musts/may requirements. > > From list@netscape.com Fri Jul 21 03:27:08 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12367 for ; Fri, 21 Jul 2000 03:27:07 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6L7GqR01320; Fri, 21 Jul 2000 00:16:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6L7PVY22493; Fri, 21 Jul 2000 00:25:31 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 00:25:31 -0700 (PDT) From: 89TPJyb3U@citytrips.be DATE: 21 Jul 00 5:34:43 AM Message-ID: <3VHuyMndiVo34> SUBJECT: >> Planes, Trains, & Automobiles! What do they all have in common? <== oiefjcsx Apparently-To: Apparently-To: Apparently-To: <102717.636@compuserve.com> Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Resent-Message-ID: <"CHVfj.A.IfF.pr_d5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com They all need SUPERIOR LUBRICATION!! Get the Technology and Protection that others don't have!! "We won't promise you that you'll save lots of $$$ or that your car will have more horsepower.... WE'LL PROVE IT." Yes, that's right. You get a RISK FREE opportunity to evaluate incredible new engine technology. The Kinetic Energy Formula and the Kinetic Octane/Cetane Charge will save you a GREAT deal of $$$ * You get more horsepower. * Better gas mileage and * Peace of mind! You also get this FREE report ... * EVERYTHING YOU WANTED TO KNOW ABOUT AUTOMOTIVE REPAIR CENTERS BUT WERE AFRAID TO ASK This FREE report and new automotive technology is a real threat to car dealerships and mechanic shops! Here's why... Are you sick and tired of losing money? If you are, this will definitely be of interest to you!!! + You get up to 30% Increase In MPG!!! + Restored Horsepower & Compression + Completely cleans and optimizes the fuel system. + Increased Engine Life + Reduced Costly Repairs Listen to what the professionals say... "I build and operate competitive drag racing engines. These engines normally last six races. We treated an engine with your products, and it ran for two complete years (over 50 races!) without tear-down or engine failure. When we finally took this motor apart, the engine bearings still had part of the original protective coating. The cam and lifters showed virtually no wear. For years, I have searched for a superior lubrication that could withstand the extreme demands of a racing engine. That search ended with your incredible technology. I use it in both my racing and personal cars. You can't argue with success. The products work!" -- Andy Callahan Engine builder & race car driver. World Record Holder "I bid a job drilling 74,880 .052 diameter holes in aluminum plate. When we started this job we had broke off 4 drill bits in the plate in less than 400 holes drilled. We thought for sure that we were going to lose a lot of money. At this time, we tried using your products in a spray mist on the drill bit as it was drilling. We successfully drilled over 74,000 holes without breaking any more bits and ended up finishing the job ahead of schedule. When we figured out our cost, we made about 10% over rate." "I drive a 1993 Lincoln Town car with a big V-8 engine. I have your products in it and get between 26-30 miles per gallon on the highway and 23-24 miles per gallon back and forth to work. I have four snowmobiles, three motorcycles, four cars, two trucks and 15 machines at my place of business that use your products." "I recently purchased a 1994 boat with a 454 V-8 engine, I have already started to use your products in it as well." "Your products don't cost us money, they save us BIG money!" Lewis Bingham President BIMCO, INC. - Bingham Machine Co "A customer of ours has an old Toyota pickup that leaked oil. When the oil level got low, the engine would begin to make a loud tapping noise. This was due to the lack of oil supply to the valves. After treating his truck with your product, he had traveled quite some time without checking the oil level. He had not heard the usual noise telling him the oil level was low. When he finally did check the engine's oil level, it was three quarts low! In addition, he had also noticed an increase in horsepower. Needless to say, your products quickly made a believer out of him." -- Glenn Mitchell - Business Owner SAV-MOR AUTO CLINIC How Will My Vehicle Benefit From Your Products? It's been proven that 70-80% of the total wear in a car's engine occurs during the start-up. The oil pump can take as long as 3 minutes to completely circulate the engines vital fluids throughout the system. When you turn the car off, the oil drains to the bottom of the engine. This leaves very little protection from metal to metal wear when you start the engine again. Regular and synthetic motor oils will not stop this damaging wear from ruining your car's engine. Our technology protects any engine by creating an impenetrable barrier on the internal metal parts of the engine. With this technology, THERE IS VIRTUALLY NO WEAR!!! You benefit by getting extra power, better gas mileage and reduced emissions. You benefit by putting more of YOUR money back into YOUR pocket! Product Features:-) + Petroleum-based kinetic energy formula. + No Teflon or PTFE. + Completely cleans and optimizes the fuel system. + Rejuvenates - seals and gaskets. + Catalytic Converter Safe. + Maintain a "like new" engine in your Car, Truck, RV, ATV, Boat, Snowmobile, Jet Ski, Lawn Mower, Motorcycle... + Less worry when you're alone on the road and away from home. + Reduce the risk of costly breakdowns. + Substantially lower operating cost. + Increase gas mileage and horsepower. + Environmentally Friendly Products. + 100% Satisfaction Guaranteed. + Independent laboratory test verification. * UP TO 30% MORE HORSEPOWER!!! * UP TO 30% MORE MILES PER GALLON!!! You get a RISK FREE opportunity to evaluate this incredible breakthrough in engine technology. The Ultimate Car-Care package will give your car or truck protection to last up to triple its normal life. The Ultimate Car-Care package gives you peace of mind when your away on road trips that mechanically, your drivetrain is protected! The Ultimate Car-Care package saves you money at the gas pump by giving your car or truck up to 30% better fuel economy. Order Ultimate Car-Care Package today and: * increase the value of your vehicle. * pay yourself with fuel savings with every fillup. 30 Day Satisfaction Guarantee The Ultimate Car-Care package contains: 1 - Kinetic Energy Formula (A special blend designed for the engine, transmission, differential & power steering. Greatly reduces operating temperature. Power that was used fighting friction is now turned into kinetic energy providing UP TO 30% MORE HORSEPOWER!) 2 - Kinetic Octane/Cetane Charge (You'll make money with every fill-up using the least expensive fuel and this product. Get better gas mileage and performance. Experience more horsepower for climbing hills and passing cars! It's like nitrous oxide for your fuel system!) 3 - Waterless Ultra Shine (A specialize treatment removes oxidized paint and protects surface from the harsh road elements without the use of water.) 4 - Leather, Vinyl, Rubber Rejuvenator (A specialize treatment that provides long-lasting protection from sun, dirt and other elements that take the life out of your valuable possessions. Will not attract dust or crack dashboard. 5 - New Battery Technology (Get faster more reliable starts. Prevents corrosion and makes battery and cables last longer.) You won't find these products on any retail shelves. List Price $86.28 - Now on Sale for just $39.95 + S/H You save over $46.00 with this offer. Order by July 28th, 2000 and you get these Special Reports... FREE Report #1 THERE'S A SUCKER BORN EVERY MINUTE FREE Report #2 HOW TO GET 500,000 MILES OR MORE FROM YOUR CAR OR TRUCK FREE Report #3 EVERYTHING YOU WANTED TO KNOW ABOUT AUTOMOTIVE REPAIR CENTERS BUT WERE AFRAID TO ASK These reports are sold normally for $40 each. You get them FREE when you order the Ultimate Car-Care package by July 28th. These FREE reports will help you put even MORE money back into YOUR pockets!! Should you not be completely satisfied with your purchase of the Ultimate Car-Care package, keep these reports as our way of saying thank you for giving us the opportunity to serve you, and we will refund your $39.95. Order the Ultimate Car-Care package by July 28th and get all three reports, a $120 value, for FREE! DON'T WAIT TO GET STARTED... here's what to do: TO ORDER your Ultimate Car-Care package, simply print out the ORDER FORM below and fax it to our order center. We accept Visa, MasterCard, American Express, Discover & Checks by Fax. We will get an incredible response to this offer and our fax line may be busy, please, keep trying...you'll be glad you did!!! *** For your security, the billing information MUST MATCH that on your credit card or we cannot process your order. For Orders Outside the Continental United States there will be additional shipping charges. You will be notified of those charges before your credit card is billed. ---CUT HERE--- -THE ULTIMATE CAR CARE PACKAGE - Send me one Ultimate Car-Care package today for a total amount of $45.90 (price includes S/H) Put your initials next to the statement below. _____Yes! I would like to get better gas mileage, more horsepower and up to triple the life of my vehicle. I am ordering by July 28th, also include the three FREE Reports: Fax Order Center: ===> 559-991-8166 <=== **DATE / / / (DD/MM/YYYY) **AUTH CODE: XR3 **NAME OR COMPANY **ADDRESS **CITY, STATE, ZIP **PHONE NUMBERS ( _ _ _ ) _ _ _ - _ _ _ _ **YOUR EMAIL ADDRESS: **TO ENSURE ACCURACY, PLEASE TYPE OR CLEARLY SPELL **YOUR EMAIL ADDRESS AGAIN: **TYPE OF CREDIT CARD OR PAYMENT: **___VISA ___MASTERCARD ___AMEX ** ___Discover ___CHECK-BY-FAX **CREDIT CARD# **EXPIRATION DATE / (MM/YYYY) **NAME ON CARD **AMOUNT $ **AUTHORIZATION SIGNATURE:______________________ (Required) CHECK BY FAX SERVICES! If you would like to fax a check, paste your check to the bottom of your completed order form then fax it to our order center. If you fax a check, there is no need for you to send the original check. We will draft up a new check, with the exact information. All checks will be held for bank clearance. (7-14 days) Make payable to: EMG =-=-REMOVE INSTRUCTIONS-=-= If you no longer wish to receive these Special Internet Offers, please send us a blank e-mail to plsrmvme09@bigfoot.com with "remove" in the subject field. Or you may Click Here mailto:plsrmvme09@bigfoot.com?subject=remove From list@netscape.com Fri Jul 21 05:03:21 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08623 for ; Fri, 21 Jul 2000 05:03:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6L8uoU12494; Fri, 21 Jul 2000 01:56:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6L91mY13757; Fri, 21 Jul 2000 02:01:48 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 02:01:48 -0700 (PDT) Message-Id: <4.3.2.7.0.20000721014229.00b08540@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 02:01:30 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Cc: In-Reply-To: <000901bff2d7$3a4d0600$b05508cb@osmium.adacel.com.au> References: <4.3.2.7.0.20000719205804.00b10600@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"xhNNSB.A.mWD.6FBe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 03:47 PM 7/21/00 +1000, Steven Legg wrote: >> >That would be so if server A and server B both had references to some >> >third server, but I was talking about the situation where server A >> >masters the entry, server B has a reference to the entry in server A, >> >and server C replicates from both server A and server B. >> Server A tells >> >server C that the object class is say, organization, while >> server B tells >> >server C that the object class is referral. >> >> Yes, this is quite different. This requires C to maintain clear >> separation of information which A is authority over and information >> which B is authority over and to restrict updates to accordingly. > >You're sort of progressing down the path of X.525's planes of information, Well, I'm trying to understand the referral model were proposing. Is it the X.500 model with planes of information with DSAspecific, DSAshared, distributed operational attributes or something else. It seems we're mixing in new ideas which are not well defined. In particular, the old namedref proposal (and my updated version) seems much akin to DNS zone delegation model than the X.500 model. (Which needs to be better specified) Rolands proposal seems to mix of the two models which I find quite confusing. >which is fine for single master replication but isn't meaningful in a >multi-master environment where servers have joint authority over >shared data. There really needs to be only one version of the shared data >for multi-master replication. I think the DNS zone delegation model better support multi-master environments. However, it has other limitations (such as upon the types of knowledge information that can be represented). >> When DSE are replicated, receiving server must have a clear >> mechanism for determining the update is associated with the >> portion of the DSE. I've suggested one approach, there are others. > >To be replication friendly, information in a DSE that is different from >one server to another needs to be in DSA-specific attributes if it is >reflected in any attributes at all. Yes, but 'refer' is distributedOperation and, if DSA-specific, why would your replicate it? >In X.500 the specialness of DSEs >containing references to other DSAs is captured in the dseType, >a DSA-specific operational attribute. It looks to me that LDAP needs >something like it, though in this case the refer attribute itself >would be enough. Roland's description of the processing that takes place >depends only on the presence of the refer attribute. The object class >of the entry containing the refer attribute doesn't get a mention that >I could see. The definition of the referral object class near the end >is pretty much incidental. Excepting when creating an entry to represent a subordinate referral... >> This is my primary concern. I am not sure it makes sense >> to change an entry into an subordinate reference just by >> adding a 'refer' attribute. I believe you should have to >> delete the entry and add a 'referral' entry. I also think >> that a 'referral' entry MUST have a 'refer' attribute. > >If you add a refer attribute to an existing entry then the other >attributes in the entry become meaningless and might as well >be removed. But the server can hold both the entry and the referral DSE. Are saying it cannot hold both? >An LDAP DSE type attribute would help if you feel there is a >need to make a more emphatic display of the fundamental change in the >nature of the DSE. What I think is we either need to follow more closely the X.500 model (including planes of information) or we describe another model. >With LDUP it would be possible for a replica to hold both the >actual entry contents and the refer attribute, which is basically what >you get if you just add a refer attribute to an existing entry. Note you just said the entries contents are ignored if a 'refer' attribute is present. >We would need to define what that means. Exactly. >> >> The implication is that certain DSEtype changes make little >> (or no) sense and using the presence or lack of presence of >> an attribute type (or types) to indicate such may not be >> optimal. > >Do I take this to mean that you like the fact that an object class >definition mandates what can and can't be in a referral DSE? This too! I like the fact that referral object class is structural and disallows certain modifications of the allowed/required attributes. >There are other ways to do that, like writing down the requirements, >which is how X.500 deals with the permitted usage of most of the >operational attributes. Yes. From list@netscape.com Fri Jul 21 08:14:50 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15516 for ; Fri, 21 Jul 2000 08:14:50 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6LC8IU23754; Fri, 21 Jul 2000 05:08:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6LCDFk22817; Fri, 21 Jul 2000 05:13:15 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 05:13:15 -0700 (PDT) Sender: Robert.Byrne@france.Sun.COM Message-ID: <39783E35.72FB2B25@france.sun.com> Date: Fri, 21 Jul 2000 14:12:37 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Haripriya S CC: "<" Subject: filters in ldapACI (WAS Re: I-D ACTION:draft-ietf-ldapext-acl-model-06.txt) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"N58szB.A.ljF.Y5De5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit From list@netscape.com Fri Jul 21 08:17:26 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16605 for ; Fri, 21 Jul 2000 08:17:26 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6LC4WR17923; Fri, 21 Jul 2000 05:04:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6LCDB222727; Fri, 21 Jul 2000 05:13:11 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 05:13:11 -0700 (PDT) Date: Fri, 21 Jul 2000 05:13:00 -0700 (PDT) Subject: Free longdistance and more !! From: webmaster@websquash.com To: ietf-ldapext@netscape.com Message-ID: <96418157002@europa.your-site.com> Resent-Message-ID: <"SFEwMB.A.fhF.T5De5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Websquash Absolutely Free Stuff - a bi-weekly newsletter from Websquash, the first "ABSOLUTELY Free Stuff" newsletter on the Net - http://www.websquash.com/ ------------------------------------------------------------ Hello, Our this bi-weekly ABSOLUTE free stuffs. 1). Free Printable grocery coupons. 2). Free long distance Phone cards. 3). Free Portals for your website (for webmasters) All this and more at http://www.websquash.com staff, http://www.websquash.com --------------------------------------------------------------- You are receiving this email as you or someone for you have subscribed to our services.If you have any questions, comments or need other information about websquash.com, please forward them to webmaster@websquash.com. We look forward to providing you with valuable promotions, offers and information through your existing e-mail account. If this message reached you in error, or you are no longer interested in receiving emails from us Unsubscribe at http://www.websquash.com/unsubscribe.html. ------------------------ From list@netscape.com Fri Jul 21 09:42:13 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13053 for ; Fri, 21 Jul 2000 09:42:12 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6LDZfU00663; Fri, 21 Jul 2000 06:35:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6LDedM14055; Fri, 21 Jul 2000 06:40:39 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 06:40:39 -0700 (PDT) Message-Id: <200007211340.JAA12861@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-locate-03.txt Date: Fri, 21 Jul 2000 09:40:33 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"q9SMdB.A.QbD.WLFe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : Discovering LDAP Services with DNS Author(s) : M. Armijo, L. Esibov, p. Leach, R. Morgan Filename : draft-ietf-ldapext-locate-03.txt Pages : Date : 20-Jul-00 A Lightweight Directory Access Protocol (LDAP) request must be directed to an appropriate server for processing. This document specifies a method for discovering such servers using information in the Domain Name System. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-locate-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapext-locate-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapext-locate-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000720141919.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-locate-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-locate-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141919.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Fri Jul 21 10:49:40 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16324 for ; Fri, 21 Jul 2000 10:49:39 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6LEbWR29240; Fri, 21 Jul 2000 07:37:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6LEkBQ04938; Fri, 21 Jul 2000 07:46:11 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 07:46:11 -0700 (PDT) Sender: Robert.Byrne@france.Sun.COM Message-ID: <3978620D.240D9D10@france.sun.com> Date: Fri, 21 Jul 2000 16:45:33 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: Haripriya S , ietf-ldapext@netscape.com Subject: Re: filters in ldapACI (WAS Re: I-D ACTION:draft-ietf-ldapext-acl-model-06.txt) References: <39783E35.72FB2B25@france.sun.com> Content-Type: multipart/alternative; boundary="------------EBF04AEEBF5CAA14DF65A21B" Resent-Message-ID: <"j8cwZ.A.zMB.yIGe5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --------------EBF04AEEBF5CAA14DF65A21B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Haripriya, You are right that there is no way to do this in the current draft. I think it's a useful feature and should probably be added. It involves adding the capability to specify an LDAP filter (restricted to objectclass only ?) to the ldapACI. Rob. > In the current model of ACL I cannot find how to actually set ACLs for a 'to be created > entry' based on its objectClass. For example, I may want a set of ACLs to be present for all > the objects of type inetorgperson, to expose certain attributes by default to even an > unauthenticated user. It would help in this case, if I have mechanism's to set ACLs for the > objectclass itself, so that any entry of that class created automatically gets these ACLs. > The other alternative would be for me to set these ACLs at one parent with scope subtree and > let all the entries under that parent inherit these ACLs. But this would not let me > distinguish by objectclass ( I may want to expose cn for inetorgperson but not for > residentialperson by default). Does anybody have ideas on this? > > Thanks and Regards, > Haripriya > --------------EBF04AEEBF5CAA14DF65A21B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Haripriya,

You are right that there is no way to do this in the current draft.  I think it's a useful feature and should probably be added.

It involves adding the capability to specify an LDAP filter (restricted to objectclass only ?) to the ldapACI.

Rob. 

 In the current model of ACL I cannot find how to actually set ACLs for a 'to be created
 entry' based on its objectClass. For example, I may want a set of ACLs to be present for all
 the objects of type inetorgperson, to expose certain attributes by default to even an
 unauthenticated user. It would help in this case, if I have mechanism's to set ACLs for the
 objectclass itself, so that any entry of that class created automatically gets these ACLs.
 The other alternative would be for me to set these ACLs at one parent with scope subtree and
 let all the entries under that parent inherit these ACLs. But this would not let me
 distinguish by objectclass ( I may want to expose cn for inetorgperson but not for
 residentialperson by default). Does anybody have ideas on this?
  
 Thanks and Regards,
 Haripriya
--------------EBF04AEEBF5CAA14DF65A21B-- From list@netscape.com Fri Jul 21 11:01:29 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17585 for ; Fri, 21 Jul 2000 11:01:29 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6LEpQR01071; Fri, 21 Jul 2000 07:51:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6LF06211003; Fri, 21 Jul 2000 08:00:06 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 08:00:06 -0700 (PDT) Message-Id: <4.3.2.7.0.20000721075234.00b2dd50@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 07:59:49 -0700 To: Rob Byrne - Sun Microsystems From: "Kurt D. Zeilenga" Subject: Re: filters in ldapACI (WAS Re: I-D ACTION:draft-ietf-ldapext-acl-model-06.txt) Cc: Haripriya S , ietf-ldapext@netscape.com In-Reply-To: <3978620D.240D9D10@france.sun.com> References: <39783E35.72FB2B25@france.sun.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_821845190==_.ALT" Resent-Message-ID: <"IEKG-C.A.GrC.0VGe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=====================_821845190==_.ALT Content-Type: text/plain; charset="us-ascii" Rob, Instead of a filter restricted to object classes, why not reintroduce collections concept, but define collections as being a collection of object classes? The ACI would apply to all attributes allowed by any of the object classes within the collection. Kurt At 04:45 PM 7/21/00 +0200, Rob Byrne - Sun Microsystems wrote: > >Haripriya, > >You are right that there is no way to do this in the current draft. I think it's a useful feature and should probably be added. > >It involves adding the capability to specify an LDAP filter (restricted to objectclass only ?) to the ldapACI. > >Rob. >> >> In the current model of ACL I cannot find how to actually set ACLs for a 'to be created >> entry' based on its objectClass. For example, I may want a set of ACLs to be present for all >> the objects of type inetorgperson, to expose certain attributes by default to even an >> unauthenticated user. It would help in this case, if I have mechanism's to set ACLs for the >> objectclass itself, so that any entry of that class created automatically gets these ACLs. >> The other alternative would be for me to set these ACLs at one parent with scope subtree and >> let all the entries under that parent inherit these ACLs. But this would not let me >> distinguish by objectclass ( I may want to expose cn for inetorgperson but not for >> residentialperson by default). Does anybody have ideas on this? >> >> Thanks and Regards, >> Haripriya --=====================_821845190==_.ALT Content-Type: text/html; charset="us-ascii" Rob,

Instead of a filter restricted to object classes, why not
reintroduce collections concept, but define collections
as being a collection of object classes?  The ACI would apply
to all attributes allowed by any of the object classes within
the collection.

Kurt


At 04:45 PM 7/21/00 +0200, Rob Byrne - Sun Microsystems wrote:
 
Haripriya,

You are right that there is no way to do this in the current draft.  I think it's a useful feature and should probably be added.

It involves adding the capability to specify an LDAP filter (restricted to objectclass only ?) to the ldapACI.

Rob. 

 In the current model of ACL I cannot find how to actually set
ACLs for a 'to be created
 entry' based on its objectClass. For example, I may want a set of
ACLs to be present for all
 the objects of type inetorgperson, to expose certain attributes by
default to even an
 unauthenticated user. It would help in this case, if I have
mechanism's to set ACLs for the
 objectclass itself, so that any entry of that class created
automatically gets these ACLs.
 The other alternative would be for me to set these ACLs at one
parent with scope subtree and
 let all the entries under that parent inherit these ACLs. But this
would not let me
 distinguish by objectclass ( I may want to expose cn for
inetorgperson but not for
 residentialperson by default). Does anybody have ideas on this?
  
 Thanks and Regards,
 Haripriya
--=====================_821845190==_.ALT-- From list@netscape.com Fri Jul 21 11:33:03 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29422 for ; Fri, 21 Jul 2000 11:33:02 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6LFMxR04625; Fri, 21 Jul 2000 08:22:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6LFVdY23809; Fri, 21 Jul 2000 08:31:39 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 08:31:39 -0700 (PDT) Sender: Robert.Byrne@france.Sun.COM Message-ID: <39786CB3.94940751@france.sun.com> Date: Fri, 21 Jul 2000 17:30:59 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Rob Byrne - Sun Microsystems , Haripriya S , ietf-ldapext@netscape.com Subject: Re: filters in ldapACI (WAS Re: I-D ACTION:draft-ietf-ldapext-acl-model-06.txt) References: <39783E35.72FB2B25@france.sun.com> <4.3.2.7.0.20000721075234.00b2dd50@infidel.boolean.net> Content-Type: multipart/alternative; boundary="------------26599C546A1E799F577F385B" Resent-Message-ID: <"n6ppcB.A.hzF.ZzGe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --------------26599C546A1E799F577F385B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt, I think the question was rather how to make an aci grant access as a function of the value of the objectclass attribute in it's entry. In the example, both objectclasses allow the cn attribute but we want the aci to apply in one case but not the other. > distinguish by objectclass ( I may want to expose cn for > inetorgperson but not for > residentialperson by default). > So, I don't see how your suggestion allows that distinction to be made. Rob. "Kurt D. Zeilenga" wrote: > Rob, > > Instead of a filter restricted to object classes, why not > reintroduce collections concept, but define collections > as being a collection of object classes? The ACI would apply > to all attributes allowed by any of the object classes within > the collection. > > Kurt > > > At 04:45 PM 7/21/00 +0200, Rob Byrne - Sun Microsystems wrote: > >> >> Haripriya, >> >> You are right that there is no way to do this in the current draft. >> I think it's a useful feature and should probably be added. >> >> It involves adding the capability to specify an LDAP filter >> (restricted to objectclass only ?) to the ldapACI. >> >> Rob. >> >> > >> > >> > In the current model of ACL I cannot find how to actually set >> > ACLs for a 'to be created >> > entry' based on its objectClass. For example, I may want a set of >> > ACLs to be present for all >> > the objects of type inetorgperson, to expose certain attributes by >> > default to even an >> > unauthenticated user. It would help in this case, if I have >> > mechanism's to set ACLs for the >> > objectclass itself, so that any entry of that class created >> > automatically gets these ACLs. >> > The other alternative would be for me to set these ACLs at one >> > parent with scope subtree and >> > let all the entries under that parent inherit these ACLs. But this >> > would not let me >> > distinguish by objectclass ( I may want to expose cn for >> > inetorgperson but not for >> > residentialperson by default). Does anybody have ideas on this? >> > >> > Thanks and Regards, >> > Haripriya >> > --------------26599C546A1E799F577F385B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Kurt,

I think the question was rather how to make an aci grant access as a function of the value of the objectclass attribute in it's entry. In the example, both objectclasses allow the cn attribute but we want the aci to apply in one case but not the other. 

 distinguish by objectclass ( I may want to expose cn for
     inetorgperson but not for
      residentialperson by default).


So, I don't see how your suggestion allows that distinction to be made.

Rob.
 

"Kurt D. Zeilenga" wrote:

 Rob,

Instead of a filter restricted to object classes, why not
reintroduce collections concept, but define collections
as being a collection of object classes?  The ACI would apply
to all attributes allowed by any of the object classes within
the collection.

Kurt
 

At 04:45 PM 7/21/00 +0200, Rob Byrne - Sun Microsystems wrote:

 
Haripriya,

You are right that there is no way to do this in the current draft.  I think it's a useful feature and should probably be added.

It involves adding the capability to specify an LDAP filter (restricted to objectclass only ?) to the ldapACI.

Rob.

  
 In the current model of ACL I cannot find how to actually set
ACLs for a 'to be created
 entry' based on its objectClass. For example, I may want a set of
ACLs to be present for all
 the objects of type inetorgperson, to expose certain attributes by
default to even an
 unauthenticated user. It would help in this case, if I have
mechanism's to set ACLs for the
 objectclass itself, so that any entry of that class created
automatically gets these ACLs.
 The other alternative would be for me to set these ACLs at one
parent with scope subtree and
 let all the entries under that parent inherit these ACLs. But this
would not let me
 distinguish by objectclass ( I may want to expose cn for
inetorgperson but not for
 residentialperson by default). Does anybody have ideas on this?
  
 Thanks and Regards,
 Haripriya
--------------26599C546A1E799F577F385B-- From list@netscape.com Fri Jul 21 11:39:07 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16325 for ; Fri, 21 Jul 2000 10:49:39 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6LEbuR29476; Fri, 21 Jul 2000 07:37:56 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6LEkYM05408; Fri, 21 Jul 2000 07:46:34 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 07:46:34 -0700 (PDT) Message-Id: <4.2.2.20000721093904.00a4c860@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jul 2000 09:45:20 -0500 To: d.w.chadwick@salford.ac.uk, bgreenblatt@directory-applications.com From: Ellen Stokes Subject: Re: delete permission Cc: ietf-ldapext@netscape.com In-Reply-To: <39777C0C.3873.5C6CB59@localhost> References: <4.2.2.20000718165021.00a38d00@popmail2.austin.ibm.com> <3974A013.24741.73B9E49@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"cgNfsD.A.yTB.IJGe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David, On relating the subtreeACI and subtree operation... My thinking is that if there is a subtreeACI with a delete permission, then when the subtree delete operation is executed on the server, the subtreeACI is checked for delete permission and since it is set the subtree operation succeeds. But this specific case is uninteresting until the time at which both subtreeACI and subtree operation exist. Until then, I see delete used only against leaf entries (as you pointed out that's what X.500 does) and when subtreeACI exists it would have the semantic of stating the delete operation (or any other operation) applies to the subtree until overridden by another ACI (either entry of subtree). Ellen At 10:24 PM 7/20/00 +0100, David Chadwick wrote: >Date sent: Tue, 18 Jul 2000 16:55:52 -0500 >To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com, > bgreenblatt@directory-applications.com >From: Ellen Stokes >Subject: Re: delete permission > > > David / Bruce, > > > > I think the ldap model should use delete in the X.500 sense - the > > object must be a leaf entry. > >agreed > > > > > However, subtree delete becomes interesting if/when we decide to > > surface the scope of ACI (entry/subtree) via your entryACI / > > subtreeACI proposal. At that point in time, then the expired subtree > > drafts become interesting because you have a way actually invoke the > > subtree operation and apply access control to the operation. > > > >Unless I have misunderstood the current model, or you have >misunderstood my proposal, I think the separation out of subtree >ACI into a separate attribute type is irrelevant to the subtree delete >operation. > >David > >*************************************************** > >David Chadwick >IS Institute, University of Salford, Salford M5 4WT >Tel +44 161 295 5351 Fax +44 161 745 8169 >Mobile +44 790 167 0359 >Email D.W.Chadwick@salford.ac.uk >Home Page http://www.salford.ac.uk/its024/chadwick.htm >Understanding X.500 http://www.salford.ac.uk/its024/X500.htm >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm >Entrust key validation string MLJ9-DU5T-HV8J > >*************************************************** From list@netscape.com Fri Jul 21 11:50:43 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07662 for ; Fri, 21 Jul 2000 11:50:22 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6LFe1R06594; Fri, 21 Jul 2000 08:40:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6LFmfM00443; Fri, 21 Jul 2000 08:48:41 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 08:48:41 -0700 (PDT) Message-Id: <4.3.2.7.0.20000721084054.00b24130@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 08:48:18 -0700 To: Rob Byrne - Sun Microsystems From: "Kurt D. Zeilenga" Subject: Re: filters in ldapACI (WAS Re: I-D ACTION:draft-ietf-ldapext-acl-model-06.txt) Cc: Rob Byrne - Sun Microsystems , Haripriya S , ietf-ldapext@netscape.com In-Reply-To: <39786CB3.94940751@france.sun.com> References: <39783E35.72FB2B25@france.sun.com> <4.3.2.7.0.20000721075234.00b2dd50@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"VQOycB.A.kG.XDHe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 05:30 PM 7/21/00 +0200, Rob Byrne - Sun Microsystems wrote: >I think the question was rather how to make an aci grant access as a function of the value of the objectclass attribute in it's entry. Fair enough. >In the example, both objectclasses allow the cn attribute but we want the aci to apply in one case but not the other. Okay. Content based ACIs... hmmm.... seems this might cause a few wrinkles (or at least add a lot of complexity). >> distinguish by objectclass ( I may want to expose cn for >> inetorgperson but not for >> residentialperson by default). From list@netscape.com Fri Jul 21 13:35:41 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29023 for ; Fri, 21 Jul 2000 13:35:40 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6LHOPR22121; Fri, 21 Jul 2000 10:24:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6LHRXE04655; Fri, 21 Jul 2000 10:27:33 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 10:27:33 -0700 (PDT) Message-Id: <200007211716.NAA10595@roadblock.missi.ncsc.mil> From: "Miklos, Sue A." To: "'Ellen Stokes'" , ietf-ldapext@netscape.com Subject: authentication mechanisms question Date: Fri, 21 Jul 2000 13:27:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Resent-Message-ID: <"uHpstD.A.0HB.BgIe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Please excuse this question if it's already been discussed/resolved - In reviewing tha authnLevel options and associated mechanisms, I see references to sasl (LDAP3). In tracing back to RFC 2222, EXTERNAL options are permitted. I would like to confirm that the authors agree that there's nothing in this draft that would preclude the use of an X.509v3 signature certificate as an 'external' authentication mechanism for conveying the DN. the difficulties associated with managing large numbers of passwords, vice allowing role name conventions within a certificate has led us to choose the certificate-based authentication. regards, Sandi From list@netscape.com Fri Jul 21 18:24:04 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29049 for ; Fri, 21 Jul 2000 18:24:02 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6LMCgR04458; Fri, 21 Jul 2000 15:12:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6LMLMI12186; Fri, 21 Jul 2000 15:21:22 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 15:21:22 -0700 (PDT) To: "Kurt D. Zeilenga" Cc: "Michael Armijo" , Subject: Re: Discovering LDAP Services with DNS - draft-ietf-ldapext-locate-03.txt References: <4.3.2.7.0.20000720123032.00b28100@infidel.boolean.net> From: Scott Seligman Date: 21 Jul 2000 15:21:13 -0700 In-Reply-To: "Kurt D. Zeilenga"'s message of Thu, 20 Jul 2000 13:18:27 -0700 Message-ID: Lines: 24 X-Mailer: Gnus v5.3/Emacs 19.34 Resent-Message-ID: <"vWaKaD.A.F-C.hzMe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com "Kurt D. Zeilenga" writes: > > FQDN: > > I noticed the specification now has trailing dots on FQDNs. This > may be inappropriate. IIRC, the trailing dot is a user interface > convention and not part of the actual DNS protocol itself. To be precise the DNS protocol doesn't make use of dots within domain names at all, but that's not really relevant. The same RFC that specifies the protocol (RFC 1035) also specifies a text format to be used for domain names in master files, and it is this format that we generally think of when we think of DNS names. This format does specify the use of trailing dots as follows: Domain names that end in a dot are called absolute, and are taken as complete. Domain names which do not end in a dot are called relative; the actual domain name is the concatenation of the relative part with an origin.... Scott Seligman Java Software Engineering Sun Microsystems From list@netscape.com Fri Jul 21 19:47:41 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00469 for ; Fri, 21 Jul 2000 19:47:37 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6LNbAR16793; Fri, 21 Jul 2000 16:37:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6LNjpY20232; Fri, 21 Jul 2000 16:45:51 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 16:45:51 -0700 (PDT) Message-ID: <3978E09C.969A15FE@software.com> Date: Fri, 21 Jul 2000 16:45:32 -0700 From: sanjay jain Organization: Software.Com X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ldapext Subject: substring filters using DN attributes ? Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"_xTVKB.A.z7E.tCOe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit It looks like from standard LDAP schema that
substring matching is not allowed for DN syntax
attributes.  E.g. for 'member' attribute.
Does it mean from http://www.ietf.org/internet-drafts/draft-just-ldapv3-rescodes-02.txt
section 5.2.2.1.3 that if an LDAP server gets a filter
like: member=*dc=org1,dc=com
it should return 'inappropriateMatching' error code ?

thanks
sanjay From list@netscape.com Fri Jul 21 20:20:39 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09481 for ; Fri, 21 Jul 2000 20:20:38 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6M09PR20585; Fri, 21 Jul 2000 17:09:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6M0I6c01795; Fri, 21 Jul 2000 17:18:06 -0700 (PDT) Resent-Date: Fri, 21 Jul 2000 17:18:06 -0700 (PDT) Message-Id: <4.3.2.7.0.20000721170246.00af2740@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 17:17:56 -0700 To: sanjay jain From: "Kurt D. Zeilenga" Subject: Re: substring filters using DN attributes ? Cc: ldapext In-Reply-To: <3978E09C.969A15FE@software.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"Y1wotD.A.rb.8gOe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 04:45 PM 7/21/00 -0700, sanjay jain wrote: >It looks like from standard LDAP schema that >substring matching is not allowed for DN syntax >attributes. E.g. for 'member' attribute. >Does it mean from http://www.ietf.org/internet-drafts/draft-just-ldapv3-rescodes-02.txt >section 5.2.2.1.3 that if an LDAP server gets a filter >like: member=*dc=org1,dc=com >it should return 'inappropriateMatching' error code ? No. The filter (member=*dc=org1,dc=com) is Undefined. The operation may complete successful with no entries being returned. From list@netscape.com Sat Jul 22 13:21:17 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27853 for ; Sat, 22 Jul 2000 13:21:16 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6MHEdU01296; Sat, 22 Jul 2000 10:14:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6MHJd217011; Sat, 22 Jul 2000 10:19:39 -0700 (PDT) Resent-Date: Sat, 22 Jul 2000 10:19:39 -0700 (PDT) X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: , Cc: Subject: RE: Some comments on model-04 Date: Sun, 23 Jul 2000 03:19:14 +1000 Message-ID: <000001bff400$f5df6960$17448490@vic.bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <39788C61.7721.9EEAC63@localhost> Importance: Normal Resent-Message-ID: <"ORMujD.A.GJE.oede5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Re point i), there may perhaps also be an unintentional limitation in the possibilities for replication agreements by defining a "Replica" as "an instance of a replicated Naming Context" (3.5, p9). Although "sparse" replicas are currently out of scope by 3.3g this refers to the complexity of implementing entry selection filters. It may not have been intended to rule out vertically adjacent replicated areas held by the same DSA in connection with different replication agreements that are themselves contiguous or convex subtrees and not "sparse". The term "Naming Context" does exclude that, as explained in 4.4 of David's book "Understanding X.500", at the URL below. I believe this point may have been raised earlier (by Dieter?), with some mention of the architecture authors following up to correct it in the archives. But it doesn't seem to have been corrected. The only benefit of this limitation that I can see is to ensure that modifyDN operations within an NC can always be performed at any updateable replica. That strikes me as unnecessary since a referral could just be given to a "full" replica that holds replication agreements for the entire NC when a modifyDN is outside the replication areas held by a DSA. A category of "full" replicas, each of which is updatable for every replicated area within the NC could be defined. The "primary" for any replicated area within an NC would then also be the primary for all other replicated areas within the NC and would be one of the "full" replicas. Alternatively it would not be all that difficult to add a slightly more complex calculation of who to send a referral to, when not all updateable replicas that can process modifyDN are "full". Even if this restriction was intentional, I can see no justification for applying it to Read-Only replicas. Why shouldn't they hold vertically adjacent replicated areas as well as disjoint ones? eg Why shouldn't a branch office DSA serving a particular OU for an organization hold read only copies of the top of an organization's tree as well as read only copies for some, but not all, of the other OUs at the same level, any of which might be vertically adjacent to the top area? Why shouldn't another DSA at a different office interested in read only copies of a different set of OUs also be able to do that? The present definition requires that either the top be excluded so that disjoint NCs can be defined, or that a single NC cover them all and every read only replica hold the entire set. I suspect it may have been unintentional, as there is clearly some confusion around about the concept of an NC. The definition on p9 refers to X.501 but does not make it clear that any other NCs encountered down the tree from the context prefix held by a DSA must be context prefixes held in a different DSA. In draft-ietf-ldapext-acl-model-06.txt, there is even a reference to "adjacent naming contexts supported by that directory server" at 3.3, p6 despite the definition that NCs are disjoint, never adjacent within a DSA. I am CCing this to ldapext for that last point, despite still not being subscribed. It isn't just a matter of terminology, but may relate to confusion about the role of subschema and access control administration points and their relations to distribution and replication. In general, attempting to define replication and access controls without having first clarified distribution models and administrative models doesn't seem to have been a good idea. Seeya, Albert -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of David Chadwick Sent: Saturday, July 22, 2000 2:46 AM To: ietf-ldup@imc.org Subject: Some comments on model-04 John & Co I have a few comments to make on the Model doc, most of them minor i) you mention the term context prefix to refer to the root of a naming context, but mostly use the term root. I would prefer that you use context prefix consistently since a) this accords with X.518 and b) it can keep the term root reserved for the root of the DIT ii) last sentence of 4.6.1. I would like some clarification of what this actually means (A CSN is recorded.......). iii) I believe there is a conflict between 8.2 and 10.3 concerning fractional replication. Either the fraction is sent only the attributes it contains (8.2) or the whole modification operation is sent (10.3) but not both. iv) section 12, steps 5 and 6 for DSA2. I believe there is a bug here. In step 5 please state explicitly what the parent entry of the rep agreement NC1R1-R2 is. I believe it should be NC1R1. In step 6 state explicitly what the parent of rep agreement NC1R2-R1. I believe it should be NC1R2. Hence the rep agreements are not siblings, as they dont have the same parent. (otherwise I have misunderstood the model and perhaps some more text somewhere to clarify this) v) It is interesting that step 5 above said take a copy of the rep agreement, whereas in section 14 it states that autentication information should never be replicated between replicas. Perhaps this statements are slightly at odds with each other. Also , if password authentication is being employed, then the password will need to be replicated between the DSAs, thus section 14 is wrong. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sat Jul 22 16:40:58 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19133 for ; Sat, 22 Jul 2000 16:40:57 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6MKUkR16015; Sat, 22 Jul 2000 13:30:46 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6MKdTk23911; Sat, 22 Jul 2000 13:39:29 -0700 (PDT) Resent-Date: Sat, 22 Jul 2000 13:39:29 -0700 (PDT) Date: Sun, 23 Jul 2000 04:47:13 +0800 From: fuglm@solidee.nl Message-Id: <200007222047.EAA10962@rime.> To: cmmjg@ab16@olemail.com Subject: Secrets make $1000.00 a week partime! fjftv Resent-Message-ID: <"JWqFBD.A.H1F._Zge5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com You will recieve $195.00 of Free Reports for responding! Are you fed up NOT making money on the NET? I'm looking for just a few people who want to earn a serious income from a PROVEN legitimate online system. I can PROVE people are earning over a $1000.00 a week working only part-time. I am only interested in working with a handful of people... such as yourself, at this time. This is a first come, first served basis. There is no large commitment and I'm sure you are the type of person who will see why this is exploding so fast. This offer will be the best you ever commit to... I guarantee it! $195.00 of Free Reports for responding! mailto:free38special1@angelfire.com?subject=$195FREE ========================================================= Remove mailto:qwrqwr@angelfire.com?subject=Remove From list@netscape.com Sat Jul 22 19:59:50 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22552 for ; Sat, 22 Jul 2000 19:59:50 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6MNncR24008; Sat, 22 Jul 2000 16:49:38 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6MNwKE26645; Sat, 22 Jul 2000 16:58:20 -0700 (PDT) Resent-Date: Sat, 22 Jul 2000 16:58:20 -0700 (PDT) Message-Id: <200007222358.e6MNwIw01443@xwing.netscape.com> Delivered-To: fixup-ietf-ldapext@netscape.com@fixme Date: Sat, 22 Jul 00 17:02:20 Pacific Daylight Time From: "Liberty Alliance" Subject: Work from Home Using the Internet (low startup)!!! To: X-Bulk-ID: ESHOP928703:16777216 X-Originating-IP: [63.225.169.207] X-Mailer: Email Workshop version 1 from Word Place, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="03AM75AP87EH53DY16GN96BP" Resent-Message-ID: <"kgN6.A.7fG.bUje5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --03AM75AP87EH53DY16GN96BP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable (to be removed scroll to the bottom of email) An Accountability list to ensure that ALL PARTICIPANTS Get paid. You cannot lose. Invest JUST $10 and see a return of $40,000 in 45 DAYS sometimes a little longer. For FREE details DO NOT PRESS REPLY. First email me at Root254@cs.com. **NOTE: put PHASE 1 in subject box. If the first email address is full email me at Gabr254@cs.com Prosperous Regards Aaron Root If you would rather not receive any more email from me and would like to be removed completely from this distribution list, email me back with "remove from distribution list" in the Subject. Send message to: aar826@uswest.net?subject=3DRemove so I can be sure to have you removed promptly! --03AM75AP87EH53DY16GN96BP Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (to be removed scroll to the bottom of email)

An Accountability list to ensure that ALL PARTICIPANTS Get paid. You canno= t lose. Invest JUST $10 and see a return of $40,000 in 45 DAYS sometimes a= little longer. For FREE
details DO NOT PRESS REPLY. First email me at Root254@cs.com

**NOTE: put PHASE 1 in subject box.

If the first email address is full email me at Gabr254@cs.com

Prosperous Regards

Aaron Root


If you would rather not receive any more email from me and would like to be= removed completely from this distribution list, email me back with "= remove from distribution list" in the Subject.
Send message to: aar8= 26@uswest.net?subject=3DRemove so I can be sure
to have you removed promptly!







--03AM75AP87EH53DY16GN96BP-- From list@netscape.com Sun Jul 23 04:30:48 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11007 for ; Sun, 23 Jul 2000 04:30:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6N8OHU07182; Sun, 23 Jul 2000 01:24:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6N8TIU17437; Sun, 23 Jul 2000 01:29:18 -0700 (PDT) Resent-Date: Sun, 23 Jul 2000 01:29:18 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: Rob Byrne - Sun Microsystems , Haripriya S , ietf-ldapext@netscape.com Date: Sun, 23 Jul 2000 09:26:54 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: filters in ldapACI (WAS Re: I-D ACTION:draft-ietf-ldapext-acl-model-06.txt) Reply-to: d.w.chadwick@salford.ac.uk CC: Haripriya S , ietf-ldapext@netscape.com Message-ID: <397ABA5E.13298.41E1213@localhost> Priority: normal In-reply-to: <3978620D.240D9D10@france.sun.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"2njcdB.A.qPE.bzqe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date forwarded: Fri, 21 Jul 2000 07:46:13 -0700 (PDT) Date sent: Fri, 21 Jul 2000 16:45:33 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems Copies to: Haripriya S , ietf-ldapext@netscape.com Subject: Re: filters in ldapACI (WAS Re: I-D ACTION:draft-ietf-ldapext-acl-model-06.txt) To: ietf-ldapext@netscape.com Forwarded by: ietf-ldapext@netscape.com > > Haripriya, > > You are right that there is no way to do this in the current draft. I > think it's a useful feature and should probably be added. > > It involves adding the capability to specify an LDAP filter > (restricted to objectclass only ?) to the ldapACI. This is precisely what X.500 ACI has as a feature. Only in this case the object class filter is not part of the ldapACI attribute but part of the subtree specification attribute that accompanies it in the subentry. (HOwever the two are synonomous. They are just different ways of structuring the same information i.e. one complex attribute vs two simpler attributes that keep their relationship by being together in a subentry. My familier of entries ID further extended this model to be fully general for any entry) David > Rob. > > > In the current model of ACL I cannot find how to actually set ACLs > > for a 'to be created entry' based on its objectClass. For example, > > I may want a set of ACLs to be present for all the objects of type > > inetorgperson, to expose certain attributes by default to even an > > unauthenticated user. It would help in this case, if I have > > mechanism's to set ACLs for the objectclass itself, so that any > > entry of that class created automatically gets these ACLs. The > > other alternative would be for me to set these ACLs at one parent > > with scope subtree and let all the entries under that parent > > inherit these ACLs. But this would not let me distinguish by > > objectclass ( I may want to expose cn for inetorgperson but not for > > residentialperson by default). Does anybody have ideas on this? > > > > Thanks and Regards, > > Haripriya > > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 23 04:30:49 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11024 for ; Sun, 23 Jul 2000 04:30:49 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6N8OWU07345; Sun, 23 Jul 2000 01:24:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6N8TWs17748; Sun, 23 Jul 2000 01:29:32 -0700 (PDT) Resent-Date: Sun, 23 Jul 2000 01:29:32 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: Ellen Stokes , ietf-ldapext@netscape.com Date: Sun, 23 Jul 2000 09:26:50 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: delete permission Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <397ABA5A.22548.41E0205@localhost> Priority: normal In-reply-to: <4.2.2.20000721093904.00a4c860@popmail2.austin.ibm.com> References: <39777C0C.3873.5C6CB59@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"0C_ZNB.A.jTE.mzqe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date forwarded: Fri, 21 Jul 2000 07:46:37 -0700 (PDT) Date sent: Fri, 21 Jul 2000 09:45:20 -0500 To: d.w.chadwick@salford.ac.uk, bgreenblatt@directory-applications.com From: Ellen Stokes Subject: Re: delete permission Copies to: ietf-ldapext@netscape.com Forwarded by: ietf-ldapext@netscape.com > David, > > On relating the subtreeACI and subtree operation... > > My thinking is that if there is a subtreeACI with a delete permission, > then when the subtree delete operation is executed on the server, the > subtreeACI is checked for delete permission and since it is set the > subtree operation succeeds. Not so. There may be an entry somewhere in the subtree that forbids the deletion of that single entry. Therefore the subtree delete should fail, as the client does not have permission to delete the whole tree. This is why I said that separation of the ACI into two attributes made no difference at all. > > But this specific case is uninteresting until the time at which both > subtreeACI and subtree operation exist. > > Until then, I see delete used only against leaf entries (as you > pointed out that's what X.500 does) and when subtreeACI exists it > would have the semantic of stating the delete operation (or any other > operation) applies to the subtree until overridden by another ACI > (either entry of subtree). why would you want to change the above semantics (which I agree with) when a subtree delete operation is introduced. I dont think you should David > > Ellen > > > > At 10:24 PM 7/20/00 +0100, David Chadwick wrote: > >Date sent: Tue, 18 Jul 2000 16:55:52 -0500 > >To: d.w.chadwick@salford.ac.uk, > >ietf-ldapext@netscape.com, > > bgreenblatt@directory-applications.com > >From: Ellen Stokes > >Subject: Re: delete permission > > > > > David / Bruce, > > > > > > I think the ldap model should use delete in the X.500 sense - the > > > object must be a leaf entry. > > > >agreed > > > > > > > > However, subtree delete becomes interesting if/when we decide to > > > surface the scope of ACI (entry/subtree) via your entryACI / > > > subtreeACI proposal. At that point in time, then the expired > > > subtree drafts become interesting because you have a way actually > > > invoke the subtree operation and apply access control to the > > > operation. > > > > > > >Unless I have misunderstood the current model, or you have > >misunderstood my proposal, I think the separation out of subtree ACI > >into a separate attribute type is irrelevant to the subtree delete > >operation. > > > >David > > > >*************************************************** > > > >David Chadwick > >IS Institute, University of Salford, Salford M5 4WT > >Tel +44 161 295 5351 Fax +44 161 745 8169 > >Mobile +44 790 167 0359 > >Email D.W.Chadwick@salford.ac.uk > >Home Page http://www.salford.ac.uk/its024/chadwick.htm > >Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > >Entrust key validation string MLJ9-DU5T-HV8J > > > >*************************************************** > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 23 04:30:51 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11049 for ; Sun, 23 Jul 2000 04:30:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6N8OQU07272; Sun, 23 Jul 2000 01:24:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6N8TQY17615; Sun, 23 Jul 2000 01:29:26 -0700 (PDT) Resent-Date: Sun, 23 Jul 2000 01:29:26 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: ietf-ldapext@netscape.com, mcs@netscape.com Date: Sun, 23 Jul 2000 09:26:55 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Persistent Search Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <397ABA5F.19226.41E16AF@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"F2_hYB.A.1RE.hzqe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Mark I think there is a small bug in Persistent Search. In clause 4b) you state b) The server MUST NOT return a SearchResult message. Instead, the search operation MUST be kept active until it is abandoned by I think this shoud read b) The server MUST NOT return a SearchResultDone message. David the client or until the client unbinds. *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 23 04:31:26 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11300 for ; Sun, 23 Jul 2000 04:31:26 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6N8KRR13419; Sun, 23 Jul 2000 01:20:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6N8TA617275; Sun, 23 Jul 2000 01:29:10 -0700 (PDT) Resent-Date: Sun, 23 Jul 2000 01:29:10 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ldapext Date: Sun, 23 Jul 2000 09:26:52 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: substring filters using DN attributes ? Reply-to: d.w.chadwick@salford.ac.uk CC: ldapext Message-ID: <397ABA5C.12059.41E08EF@localhost> Priority: normal In-reply-to: <4.3.2.7.0.20000721170246.00af2740@infidel.boolean.net> References: <3978E09C.969A15FE@software.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"2oE6xB.A.GNE.Vzqe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date forwarded: Fri, 21 Jul 2000 17:18:07 -0700 (PDT) Date sent: Fri, 21 Jul 2000 17:17:56 -0700 To: sanjay jain From: "Kurt D. Zeilenga" Subject: Re: substring filters using DN attributes ? Copies to: ldapext Forwarded by: ietf-ldapext@netscape.com I think we have an excellent case here for the introduction of a new matching rule that will indeed allow matches of the type required on DNs. David > At 04:45 PM 7/21/00 -0700, sanjay jain wrote: > >It looks like from standard LDAP schema that > >substring matching is not allowed for DN syntax > >attributes. E.g. for 'member' attribute. > >Does it mean from > > >t>http://www.ietf.org/internet-drafts/draft-just-ldapv3-rescodes-02.t > >xt section 5.2.2.1.3 that if an LDAP server gets a filter like: > >member=*dc=org1,dc=com it should return 'inappropriateMatching' error > >code ? > > No. > > The filter (member=*dc=org1,dc=com) is Undefined. The operation > may complete successful with no entries being returned. > > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 23 11:44:19 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28205 for ; Sun, 23 Jul 2000 11:44:19 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6NFatU23154; Sun, 23 Jul 2000 08:36:55 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6NFfug26546; Sun, 23 Jul 2000 08:41:56 -0700 (PDT) Resent-Date: Sun, 23 Jul 2000 08:41:56 -0700 (PDT) Message-ID: <396F3946000AF630@mail.ngi.de> (added by postmaster@mail.ngi.de) From: "Kris Kline" Subject: Your Web Site... #7012 To: on39s@ywing.netscape.com X-Mailer: QUALCOMM Windows Eudora Light Version 4.0 (32) Mime-Version: 1.0 Date: Sun, 23 Jul 2000 10:03:41 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e6NFft126519 Resent-Message-ID: <"pzYdcB.A.deG.DJxe5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit FREE E-COMMERCE WHEN YOU HOST WITH US!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: Sign up for our E-Commerce Package and get a free merchant account + a $200 cash coupon. WE MEAN IT! THIS IS A REAL CASH COUPON! YOU PAY IN FACT $200 DOLLARS LESS DURING THIS SPECIAL PROMOTION. THIS OFFER IS ONLY GOOD FOR 7 DAYS. DON'T MISS THIS OPORTUNITY. NOBODY BEATS OUR PRICE! While others charge you hundreds of dollars to get a merchant account or put you on a 48 months non-cancelable lease agreement we charge you NOTHING for your merchant account when you sign up for one of our e -commerce hosting plans. If you wish to stay with your current hosting company or have already a merchant account our offer is even better. We have 7 different E-Commerce plans to suit your individual needs. We have a solution for U.S. beased merchants and international merchants. Wherever you are on this planet, we get your online store up and running within a few days. Check it out first and make an informed decision. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS , DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * Automated E-mail receipts to your clients * Recurring billing feature with batch uploads * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 75 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That 's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account, real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. In addition you get a FREE listing in our mall and FREE advertising to promote your store. We drive traffic to your site and help you to become a successful .com business. REQUEST OUR FREE E-MAIL INFORMATION IMMEDIATELY! REMEMBER: THIS SPECIAL OFFER IS ONLY GOOD FOR 7 DAYS! Please reply to: mailto:kmmk@alloymail.com?subject=INFO-PLEASE to receive our FREE e-mail information package without obligations. *************************************************** Remove at mailto:abkml@netscape.net?subject=remove *************************************************** From list@netscape.com Sun Jul 23 14:21:57 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07247 for ; Sun, 23 Jul 2000 14:21:56 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6NIFVU29381; Sun, 23 Jul 2000 11:15:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6NIKW624272; Sun, 23 Jul 2000 11:20:32 -0700 (PDT) Resent-Date: Sun, 23 Jul 2000 11:20:32 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: ietf-ldapext@netscape.com, jimse@novell.com Date: Sun, 23 Jul 2000 19:18:07 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Use of criticality in dupent-04 Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <397B44EF.15284.63B612D@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"8t72zD.A.16F.udze5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Jim In your ID you mention the use of the criticality field in a control response. e.g criticality is FALSE (MAY be absent). In fact, RFC2251 says nothing about the use of the criticality field in a response. The functionality has been lifted from X.500(93) and criticality only has meaning in a request sent to a server. I suggest you remove the text about criticality in a response. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 23 14:22:15 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07313 for ; Sun, 23 Jul 2000 14:22:14 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6NIBxR06414; Sun, 23 Jul 2000 11:11:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6NIKhA24506; Sun, 23 Jul 2000 11:20:43 -0700 (PDT) Resent-Date: Sun, 23 Jul 2000 11:20:43 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: jimse@novell.com, ietf-ldapext@netscape.com Date: Sun, 23 Jul 2000 19:18:06 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: partial results in dupent-04.txt Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <397B44EE.6905.63B5F20@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"Ejq_LB.A.C-F.4dze5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Jim, can I ask that the PartialResultsAllowed parameter be renamed to PartialApplicationAllowed or PartialControlAllowed or similar. This is because the term Partial Results has a special meaning i.e. a set of Search Results containing one or more referrals. On initial reading I wondered what referrals had to do with duplicate entries!! thanks David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 23 15:01:36 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16902 for ; Sun, 23 Jul 2000 15:01:35 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6NIt7U01859; Sun, 23 Jul 2000 11:55:07 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6NJ08U02150; Sun, 23 Jul 2000 12:00:08 -0700 (PDT) Resent-Date: Sun, 23 Jul 2000 12:00:08 -0700 (PDT) Message-Id: <4.3.2.7.0.20000723104708.00af3e40@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 23 Jul 2000 11:59:35 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: filters in ldapACI (WAS Re: I-D ACTION:draft-ietf-ldapext-acl-model-06.txt) Cc: ietf-ldapext@netscape.com In-Reply-To: <397ABA5E.13298.41E1213@localhost> References: <3978620D.240D9D10@france.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"znRAZC.A.Bh.3C0e5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 09:26 AM 7/23/00 +0100, David Chadwick wrote: >This is precisely what X.500 ACI has as a feature. Only in this case >the object class filter is not part of the ldapACI attribute but part of >the subtree specification attribute that accompanies it in the >subentry. (HOwever the two are synonomous. They are just >different ways of structuring the same information i.e. one complex >attribute vs two simpler attributes that keep their relationship by >being together in a subentry. Though both X.500 subentry and ldapACI offer sophisticated scoping specification mechanisms, the X.500 subentry is a general mechanism which can be applied to numerous features. That is, a server can implement the subentry complexity once and then apply it to multiple features. ldapACI's mechanism is specific to the feature it provides. Other attributes would have to define it's own scoping mechanisms (or use X.500's subentry provided mechanism). There are, of course, a number of differences in the actual scoping mechanisms. Also, ldapACI could be scoped using ldapACISubentry (or X.500 subentry for that matter). The specification of such is stated as being out of scope of the ACM I-D, which is wise. The LDAPsubentry I-D does not define any scoping semantics and appears to only provide a generic container for operational information. But that's another thread. From list@netscape.com Sun Jul 23 17:51:44 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24088 for ; Sun, 23 Jul 2000 17:51:43 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6NLfUR16237; Sun, 23 Jul 2000 14:41:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6NLoEc00480; Sun, 23 Jul 2000 14:50:14 -0700 (PDT) Resent-Date: Sun, 23 Jul 2000 14:50:14 -0700 (PDT) Message-ID: <397B6AA7.820D1C7C@oracle.com> Date: Sun, 23 Jul 2000 14:59:03 -0700 From: Uppili Srinivasan X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Albert.Langer@directory-designs.org CC: d.w.chadwick@salford.ac.uk, ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: Re: Some comments on model-04 References: <000001bff400$f5df6960$17448490@vic.bigpond.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"6EFE8D.A.LH.Vi2e5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Albert: The "Naming context" definition in the context of replication was meant to avoid two replicas in the same DSA with over lapping or contiguous areas. It does allow multiple agreements associated with the same replica. You are right about some changes that were discussed around the definition of NC. The idea was to alter it as necessary so that the definition is consistent across replication, the ACL model (Ellen) and also for any future sub schema work (Mark Wahl). Let me try to make the necessary modification after some discussion at Pittsburgh with these authors. I would like to re-examine the ambiguities you have highlighted (regarding what is intentionally or unintentionally implied as requirements for read-only replicas) with a modified definition of NC. Thanks, Uppili. Albert Langer wrote: > Re point i), there may perhaps also be an unintentional limitation in the > possibilities for replication agreements by defining a "Replica" as "an > instance of a replicated Naming Context" (3.5, p9). Although "sparse" > replicas are currently out of scope by 3.3g this refers to the complexity of > implementing entry selection filters. It may not have been intended to rule > out vertically adjacent replicated areas held by the same DSA in connection > with different replication agreements that are themselves contiguous or > convex subtrees and not "sparse". The term "Naming Context" does exclude > that, as explained in 4.4 of David's book "Understanding X.500", at the URL > below. > > > I believe this point may have been raised earlier (by Dieter?), with some > mention of the architecture authors following up to correct it in the > archives. But it doesn't seem to have been corrected. > The only benefit of this limitation that I can see is to ensure that > modifyDN operations within an NC can always be performed at any updateable > replica. That strikes me as unnecessary since a referral could just be given > to a "full" replica that holds replication agreements for the entire NC when > a modifyDN is outside the replication areas held by a DSA. A category of > "full" replicas, each of which is updatable for every replicated area within > the NC could be defined. The "primary" for any replicated area within an NC > would then also be the primary for all other replicated areas within the NC > and would be one of the "full" replicas. Alternatively it would not be all > that difficult to add a slightly more complex calculation of who to send a > referral to, when not all updateable replicas that can process modifyDN are > "full". > > Even if this restriction was intentional, I can see no justification for > applying it to Read-Only replicas. Why shouldn't they hold vertically > adjacent replicated areas as well as disjoint ones? > eg Why shouldn't a branch office DSA serving a particular OU for an > organization hold read only copies of the top of an organization's tree as > well as read only copies for some, but not all, of the other OUs at the same > level, any of which might be vertically adjacent to the top area? Why > shouldn't another DSA at a different office interested in read only copies > of a different set of OUs also be able to do that? The present definition > requires that either the top be excluded so that disjoint NCs can be > defined, or that a single NC cover them all and every read only replica hold > the entire set. > > I suspect it may have been unintentional, as there is clearly some confusion > around about the concept of an NC. The definition on p9 refers to X.501 but > does not make it clear that any other NCs encountered down the tree from the > context prefix held by a DSA must be context prefixes held in a different > DSA. In draft-ietf-ldapext-acl-model-06.txt, there is even a reference to > "adjacent naming contexts supported by that directory server" at 3.3, p6 > despite the definition that NCs are disjoint, never adjacent within a DSA. > > I am CCing this to ldapext for that last point, despite still not being > subscribed. > > It isn't just a matter of terminology, but may relate to confusion about the > role of subschema and access control administration points and their > relations to distribution and replication. > > In general, attempting to define replication and access controls without > having first clarified distribution models and administrative models doesn't > seem to have been a good idea. > > Seeya, Albert > > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of David Chadwick > Sent: Saturday, July 22, 2000 2:46 AM > To: ietf-ldup@imc.org > Subject: Some comments on model-04 > > John & Co > > I have a few comments to make on the Model doc, most of them > minor > > i) you mention the term context prefix to refer to the root of a > naming context, but mostly use the term root. I would prefer that > you use context prefix consistently since a) this accords with X.518 > and b) it can keep the term root reserved for the root of the DIT > > ii) last sentence of 4.6.1. I would like some clarification of what this > actually means (A CSN is recorded.......). > > iii) I believe there is a conflict between 8.2 and 10.3 concerning > fractional replication. Either the fraction is sent only the attributes it > contains (8.2) or the whole modification operation is sent (10.3) but > not both. > > iv) section 12, steps 5 and 6 for DSA2. I believe there is a bug > here. In step 5 please state explicitly what the parent entry of the > rep agreement NC1R1-R2 is. I believe it should be NC1R1. In step > 6 state explicitly what the parent of rep agreement NC1R2-R1. I > believe it should be NC1R2. Hence the rep agreements are not > siblings, as they dont have the same parent. (otherwise I have > misunderstood the model and perhaps some more text somewhere > to clarify this) > > v) It is interesting that step 5 above said take a copy of the rep > agreement, whereas in section 14 it states that autentication > information should never be replicated between replicas. Perhaps > this statements are slightly at odds with each other. Also , if > password authentication is being employed, then the password will > need to be replicated between the DSAs, thus section 14 is wrong. > > David > > *************************************************** > > David Chadwick > IS Institute, University of Salford, Salford M5 4WT > Tel +44 161 295 5351 Fax +44 161 745 8169 > Mobile +44 790 167 0359 > Email D.W.Chadwick@salford.ac.uk > Home Page http://www.salford.ac.uk/its024/chadwick.htm > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string MLJ9-DU5T-HV8J > > *************************************************** From list@netscape.com Sun Jul 23 21:51:45 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16339 for ; Sun, 23 Jul 2000 21:51:45 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6O1ieU18906; Sun, 23 Jul 2000 18:44:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6O1ngY11785; Sun, 23 Jul 2000 18:49:42 -0700 (PDT) Resent-Date: Sun, 23 Jul 2000 18:49:42 -0700 (PDT) Message-Id: <4.2.2.20000723204102.00a38ca0@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 23 Jul 2000 20:43:13 -0500 To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com From: Ellen Stokes Subject: Re: delete permission In-Reply-To: <397ABA5A.22548.41E0205@localhost> References: <4.2.2.20000721093904.00a4c860@popmail2.austin.ibm.com> <39777C0C.3873.5C6CB59@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"UD400C.A.W3C.0C6e5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David, response embedded below. Ellen At 09:26 AM 7/23/00 +0100, David Chadwick wrote: >Date forwarded: Fri, 21 Jul 2000 07:46:37 -0700 (PDT) >Date sent: Fri, 21 Jul 2000 09:45:20 -0500 >To: d.w.chadwick@salford.ac.uk, >bgreenblatt@directory-applications.com >From: Ellen Stokes >Subject: Re: delete permission >Copies to: ietf-ldapext@netscape.com >Forwarded by: ietf-ldapext@netscape.com > > > David, > > > > On relating the subtreeACI and subtree operation... > > > > My thinking is that if there is a subtreeACI with a delete permission, > > then when the subtree delete operation is executed on the server, the > > subtreeACI is checked for delete permission and since it is set the > > subtree operation succeeds. > >Not so. There may be an entry somewhere in the subtree that >forbids the deletion of that single entry. Therefore the subtree >delete should fail, as the client does not have permission to delete >the whole tree. This is why I said that separation of the ACI into two >attributes made no difference at all. (EJS) I now see your point. > > > > But this specific case is uninteresting until the time at which both > > subtreeACI and subtree operation exist. > > > > Until then, I see delete used only against leaf entries (as you > > pointed out that's what X.500 does) and when subtreeACI exists it > > would have the semantic of stating the delete operation (or any other > > operation) applies to the subtree until overridden by another ACI > > (either entry of subtree). > >why would you want to change the above semantics (which I agree >with) when a subtree delete operation is introduced. I dont think you >should (EJS) I see your point. >David > > > > > Ellen > > > > > > > > At 10:24 PM 7/20/00 +0100, David Chadwick wrote: > > >Date sent: Tue, 18 Jul 2000 16:55:52 -0500 > > >To: d.w.chadwick@salford.ac.uk, > > >ietf-ldapext@netscape.com, > > > bgreenblatt@directory-applications.com > > >From: Ellen Stokes > > >Subject: Re: delete permission > > > > > > > David / Bruce, > > > > > > > > I think the ldap model should use delete in the X.500 sense - the > > > > object must be a leaf entry. > > > > > >agreed > > > > > > > > > > > However, subtree delete becomes interesting if/when we decide to > > > > surface the scope of ACI (entry/subtree) via your entryACI / > > > > subtreeACI proposal. At that point in time, then the expired > > > > subtree drafts become interesting because you have a way actually > > > > invoke the subtree operation and apply access control to the > > > > operation. > > > > > > > > > >Unless I have misunderstood the current model, or you have > > >misunderstood my proposal, I think the separation out of subtree ACI > > >into a separate attribute type is irrelevant to the subtree delete > > >operation. > > > > > >David > > > > > >*************************************************** > > > > > >David Chadwick > > >IS Institute, University of Salford, Salford M5 4WT > > >Tel +44 161 295 5351 Fax +44 161 745 8169 > > >Mobile +44 790 167 0359 > > >Email D.W.Chadwick@salford.ac.uk > > >Home Page http://www.salford.ac.uk/its024/chadwick.htm > > >Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > > >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > > >Entrust key validation string MLJ9-DU5T-HV8J > > > > > >*************************************************** > > > > > > >*************************************************** > >David Chadwick >IS Institute, University of Salford, Salford M5 4WT >Tel +44 161 295 5351 Fax +44 161 745 8169 >Mobile +44 790 167 0359 >Email D.W.Chadwick@salford.ac.uk >Home Page http://www.salford.ac.uk/its024/chadwick.htm >Understanding X.500 http://www.salford.ac.uk/its024/X500.htm >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm >Entrust key validation string MLJ9-DU5T-HV8J > >*************************************************** From list@netscape.com Sun Jul 23 21:51:58 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16403 for ; Sun, 23 Jul 2000 21:51:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6O1emR26370; Sun, 23 Jul 2000 18:40:48 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6O1nWs11533; Sun, 23 Jul 2000 18:49:32 -0700 (PDT) Resent-Date: Sun, 23 Jul 2000 18:49:32 -0700 (PDT) Message-Id: <4.2.2.20000723203508.00a3d620@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 23 Jul 2000 20:37:45 -0500 To: "Miklos, Sue A." , ietf-ldapext@netscape.com From: Ellen Stokes Subject: Re: authentication mechanisms question In-Reply-To: <200007211716.NAA10596@roadblock.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"wzElpD.A.4zC.qC6e5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Sandi, There is nothing in the draft that would preclude the use of an X.509v3 signature cert as an external authentication mechanism. Perhaps the interesting question is whether we have defined the set of authn levels sufficiently to cover the known specific and general types of authn levels. Perhaps we should list 'SASL EXTERNAL' and also some explicit sasl external mechanisms? Comments, anyone? Ellen At 01:27 PM 7/21/00 -0400, Miklos, Sue A. wrote: >Please excuse this question if it's already been discussed/resolved - > >In reviewing tha authnLevel options and associated mechanisms, I see >references to sasl (LDAP3). In tracing back to RFC 2222, EXTERNAL options >are permitted. > >I would like to confirm that the authors agree that there's nothing in this >draft that would preclude the use of an X.509v3 signature certificate as an >'external' authentication mechanism for conveying the DN. > >the difficulties associated with managing large numbers of passwords, vice >allowing role name conventions within a certificate has led us to choose the >certificate-based authentication. > >regards, >Sandi From list@netscape.com Sun Jul 23 23:41:03 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11304 for ; Sun, 23 Jul 2000 23:40:59 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6O3YNU24846; Sun, 23 Jul 2000 20:34:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6O3dPo02535; Sun, 23 Jul 2000 20:39:25 -0700 (PDT) Resent-Date: Sun, 23 Jul 2000 20:39:25 -0700 (PDT) Message-Id: <4.2.2.20000723223534.00a3dc60@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 23 Jul 2000 22:38:40 -0500 To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com From: Ellen Stokes Subject: Re: Typos, bugs, clarifications for ACI draft (iv) In-Reply-To: <39738FDB.3106.3146556@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"8x5st.A.Sn.rp7e5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David, I didn't intend to have different rules here - add and import both work below as you stated. I'll change the wording in the permissions section to reflect this (when I pulled the words from X.500 I guess I wasn't careful - or should I say perhaps X.500 wasn't careful?). Ellen At 10:59 PM 7/17/00 +0100, David Chadwick wrote: >Ellen > >could you clarify a few points for me please > >iv) add is permission for below an entry, but import appears not to >be ("permissions at the source location", not "below the source >location"). I dont think it is helpful to have different rules here (or >different text). Can we be consistent please as adding or importing >seem to be very similar in where the new entries are placed. > >David > >*************************************************** > >David Chadwick >IS Institute, University of Salford, Salford M5 4WT >Tel +44 161 295 5351 Fax +44 161 745 8169 >Mobile +44 790 167 0359 >Email D.W.Chadwick@salford.ac.uk >Home Page http://www.salford.ac.uk/its024/chadwick.htm >Understanding X.500 http://www.salford.ac.uk/its024/X500.htm >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm >Entrust key validation string MLJ9-DU5T-HV8J > >*************************************************** From list@netscape.com Mon Jul 24 02:24:16 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11538 for ; Mon, 24 Jul 2000 02:24:11 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6O6DhR10304; Sun, 23 Jul 2000 23:13:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6O6MSc03451; Sun, 23 Jul 2000 23:22:28 -0700 (PDT) Resent-Date: Sun, 23 Jul 2000 23:22:28 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Date: Mon, 24 Jul 2000 16:25:05 +1000 Message-ID: <001001bff537$e929f270$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <4.3.2.7.0.20000721014229.00b08540@infidel.boolean.net> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Resent-Message-ID: <"Uq0tIC.A.g1.iC-e5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Kurt, > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Friday, 21 July 2000 19:02 > To: steven.legg@adacel.com.au > Cc: ietf-ldapext@netscape.com > Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt > > > At 03:47 PM 7/21/00 +1000, Steven Legg wrote: > >> >That would be so if server A and server B both had > references to some > >> >third server, but I was talking about the situation where server A > >> >masters the entry, server B has a reference to the entry > in server A, > >> >and server C replicates from both server A and server B. > >> Server A tells > >> >server C that the object class is say, organization, while > >> server B tells > >> >server C that the object class is referral. > >> > >> Yes, this is quite different. This requires C to maintain clear > >> separation of information which A is authority over and information > >> which B is authority over and to restrict updates to accordingly. > > > >You're sort of progressing down the path of X.525's planes > of information, > > Well, I'm trying to understand the referral model were proposing. The referral model is what Roland described except that it needs to be generalized to account for the effects of replication, and some of the details of the distribution knowledge representation could be different to avoid compromising LDUP. > Is it the X.500 model with planes of information with DSAspecific, > DSAshared, distributed operational attributes or something > else. It seems we're mixing in new ideas which are not well > defined. Some of it is well defined and well practiced in X.500 but we still need the new ideas because of the consequences of multi-master replication. > > In particular, the old namedref proposal (and my updated version) > seems much akin to DNS zone delegation model than the X.500 model. > (Which needs to be better specified) > > Rolands proposal seems to mix of the two models which I find > quite confusing. I'm not familiar with DNS zone delegation so Roland's proposal looked to me like it was inspired just by the X.500 distributed knowledge model. It has the same sorts of references in the same sorts of places. > >which is fine for single master replication but isn't meaningful in a > >multi-master environment where servers have joint authority over > >shared data. There really needs to be only one version of > the shared data > >for multi-master replication. > > I think the DNS zone delegation model better support multi-master > environments. However, it has other limitations (such as upon > the types of knowledge information that can be represented). After a quick read of the DNS RFCs I have two, possibly bogus, observations to make. Firstly, DNS doesn't look like a multi-master environment. All name servers holding authoritative data for a particular zone can trace back to the same original configuration file. All changes occur at, and are propagated from, this original file. That's single master replication even though the single master is just a text file. Secondly, the resource records are the same everywhere they are stored regardless of whether they are cached or authoritative, and regardless of what name server holds them. DNS would be messy if the records were represented differently depending on location, just as LDUP/URP will be messy if shared data has different representations depending on the context of the directory server. > > >> When DSE are replicated, receiving server must have a clear > >> mechanism for determining the update is associated with the > >> portion of the DSE. I've suggested one approach, there are others. > > > >To be replication friendly, information in a DSE that is > different from > >one server to another needs to be in DSA-specific attributes if it is > >reflected in any attributes at all. > > Yes, but 'refer' is distributedOperation and, if DSA-specific, why > would your replicate it? In this case the DSA specific data is whether the DSE represents a reference or entry contents. It's one, or the other, or with LDUP it can be both. This varies from server to server. In X.500 that information would be held by the dseType (DSA-specific). For the moment I'm assuming that the presence of the refer attribute tells us the DSE is a reference without it saying anything about whether the DSE has normal entry content. The shareable data is the refer attribute (distributedOperation is appropriate) and any other non-DSA-specific entry contents (including the object class). > > >In X.500 the specialness of DSEs > >containing references to other DSAs is captured in the dseType, > >a DSA-specific operational attribute. It looks to me that LDAP needs > >something like it, though in this case the refer attribute itself > >would be enough. Roland's description of the processing that > takes place > >depends only on the presence of the refer attribute. The object class > >of the entry containing the refer attribute doesn't get a > mention that > >I could see. The definition of the referral object class near the end > >is pretty much incidental. > > Excepting when creating an entry to represent a subordinate > referral... Yes, "near the end". The presence of the referral object class is incidental to the task of generating referrals. > > >> This is my primary concern. I am not sure it makes sense > >> to change an entry into an subordinate reference just by > >> adding a 'refer' attribute. I believe you should have to > >> delete the entry and add a 'referral' entry. I also think > >> that a 'referral' entry MUST have a 'refer' attribute. > > > >If you add a refer attribute to an existing entry then the other > >attributes in the entry become meaningless and might as well > >be removed. > > But the server can hold both the entry and the referral DSE. > Are saying it cannot hold both? Sorry for the confusion. There's important context that I neglected to make explicit. For a DSE that contains both referral information and entry contents; If the DSE is in an area of replication that is singly or jointly mastered and the refer attribute references the server itself, or one of the other masters, then the entry contents are used and the refer attribute is ignored. If the DSE is in an area of replication that is read-only and the refer attribute references the server itself then the refer attribute is ignored. If the refer attribute references some other server it will be a master, so whether the entry contents or a referral is returned will depend on service controls like dontUseCopy. If the DSE is not in an area of replication and the refer attribute references the server itself the refer attribute is ignored. Otherwise the entry contents are ignored. Of course the above would need to be generalized to account for multiple values of the refer attribute. > > >An LDAP DSE type attribute would help if you feel there is a > >need to make a more emphatic display of the fundamental change in the > >nature of the DSE. > > What I think is we either need to follow more closely the X.500 > model (including planes of information) or we describe another > model. Some aspects of the X.500 distribution and/or replication model are worth using for both DISP and LDUP compatibility (like the clean separation between DSA-shared and DSA-specific data) but other aspects don't apply in the multi-master environment (like planes of information). What we need is not quite like anything that has gone before in the directory space. > > > >With LDUP it would be possible for a replica to hold both the > >actual entry contents and the refer attribute, which is > basically what > >you get if you just add a refer attribute to an existing entry. > > Note you just said the entries contents are ignored if a 'refer' > attribute is present. Yeah, sorry again. Regards, Steven > > >We would need to define what that means. > > Exactly. > > >> > >> The implication is that certain DSEtype changes make little > >> (or no) sense and using the presence or lack of presence of > >> an attribute type (or types) to indicate such may not be > >> optimal. > > > >Do I take this to mean that you like the fact that an object class > >definition mandates what can and can't be in a referral DSE? > > This too! I like the fact that referral object class is structural > and disallows certain modifications of the allowed/required > attributes. > > >There are other ways to do that, like writing down the requirements, > >which is how X.500 deals with the permitted usage of most of the > >operational attributes. > > Yes. > > From list@netscape.com Mon Jul 24 04:19:41 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08648 for ; Mon, 24 Jul 2000 04:19:40 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6O8ACU10119; Mon, 24 Jul 2000 01:10:12 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6O8FEY27806; Mon, 24 Jul 2000 01:15:14 -0700 (PDT) Resent-Date: Mon, 24 Jul 2000 01:15:14 -0700 (PDT) Message-Id: <4.3.2.7.0.20000724004506.00b14610@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 01:14:56 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Cc: In-Reply-To: <001001bff537$e929f270$b05508cb@osmium.adacel.com.au> References: <4.3.2.7.0.20000721014229.00b08540@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"p6817C.A.JyG.Qs_e5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com As I think this thread has gone astray and suggest we discontinue it for now. Not to mean that I'm dropping or conceding any particular position, just that I think it will be hard to continue under the current thread. Further clarification is need from the authors. We surely revisit the relevant issues later. For now, I'll defer further discussion until the author has a chance to respond to the specific questions I asked in my first post in this thread. http://www.openldap.org/lists/ietf-ldapext/200007/msg00135.html Regards, Kurt From list@netscape.com Mon Jul 24 04:21:46 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09123 for ; Mon, 24 Jul 2000 04:21:45 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6O894R17176; Mon, 24 Jul 2000 01:09:04 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6O8Hn629028; Mon, 24 Jul 2000 01:17:49 -0700 (PDT) Resent-Date: Mon, 24 Jul 2000 01:17:49 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Ramsay, Ron'" Cc: Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Date: Mon, 24 Jul 2000 18:20:30 +1000 Message-ID: <001101bff548$08cd5cb0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <11981F9F5649D411BC92009027D0D18C74114A@aspams01.cai.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Resent-Message-ID: <"vqbrKD.A.JFH.ru_e5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Ron, > -----Original Message----- > From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com] > Sent: Friday, 21 July 2000 16:36 > To: steven.legg@adacel.com.au; 'Kurt D. Zeilenga' > Cc: ietf-ldapext@netscape.com > Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt > > > Hi, > > I'm having trouble following the bit about replicating the > refer attribute. > I agree that it should be a DSA-specific attribute. I didn't say that. The current usage of distributedOperation is appropriate, at least for the cases of refer;sub, refer;nssr and refer;cross. But refer;sup and refer;me really should be dSAOperation since their values are only useful to the local server (so there is a case for the use of separate attribute types instead of attribute options). > But my > conclusion would > be that it *cannot* be replicated. > > I suppose, under master-slave replication, you could specify that all > entries are copied verbatim (though the refer attribute may > now point to a > DSA which is no longer, eg, local), but for master-master > replication there > would seem to be no situation in which the attribute can be > replicated. (I > should have given a long-sentence alert!) In multi-master replication, > presumably one of the replicas has the actual entry. If this entry is > updated, the updates will be sent to the other masters, so > they now have > (parts of) the whole entry. The refer attribute now seems to be > out-of-place? It does, but we have various ways to deal with this situation. 1) We could choose to never replicate the refer attribute (make it completely DSA-specific). However there are good reasons for replicating sub & nssr. For example, it's not unreasonable for me to want to create a read-only replica of a master server that contains all the same distributed knowledge references. Having to manually maintain the references in the read-only replica would be annoying. 2) We could put special case processing into LDUP to drop the refer attribute in the circumstances where it would be "out of place". Given that the determination of "out of place" is dependent on a changeable replication topology, the propagation delays of same, and the properties of the yet to be defined partial replication, I'm a bit wary of this solution. 3) Allow the refer attribute (except ;me & ;sup) to be replicated like any other DSA-shared attribute and define the semantics so that it is ignored whenever, and for as long as, it is considered "out of place". This is the line I've been following. I think we can define this with more certainty than 2. > > I should think the entry itself is DSA-specific! > > Note that, if NSSRs are retained, the NSSR will actually be > carried in a > real entry. If the NSSR is like the X.500 NSSR then it is carried in the immediate superior entry of the unspecified naming context(s). So yes, replication aside, that is a real entry with a regular object class (i.e. not referral). > I think this complicates Steven's argument. Not too much I think. Any of the unspecified naming contexts could be present as a result of a replication agreement, in which case they are no different from any local subordinate entries that were already present (I'm assuming that refer;nssr allows local subordinates to be present also). The awkward part is that we might not be able to tell whether *all* the unspecified subordinates have been replicated. To be safe referral/continuation references would have to be returned, so a client might end up collecting more duplicates than if the NSSR were absent. I'm not sure that solution 2) could do much better for NSSRs. Neither the supplier nor the consumer can determine with 100% certainty in all cases whether the NSSR should be replicated. Regards, Steven > (I > found the draft a > bit unsatisfactory in the area of NSSRs.) > > Ron. > > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Friday, 21 July 2000 15:48 > To: 'Kurt D. Zeilenga' > Cc: ietf-ldapext@netscape.com > Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt > > > > Kurt, > > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > Sent: Thursday, 20 July 2000 14:29 > > To: steven.legg@adacel.com.au > > Cc: ietf-ldapext@netscape.com > > Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt > > > > > > At 12:16 PM 7/20/00 +1000, Steven Legg wrote: > > >> >> Is an option required? If not, what is the semantics of > > >> an optionless > > >> >> refer attribute? > > > > No answer to this yet. > > I thought that was a question for Roland, but if you want my opinion, > it doesn't mean anything. Optionless refer attributes are ignored. > > > >That would be so if server A and server B both had > references to some > > >third server, but I was talking about the situation where server A > > >masters the entry, server B has a reference to the entry > in server A, > > >and server C replicates from both server A and server B. > > Server A tells > > >server C that the object class is say, organization, while > > server B tells > > >server C that the object class is referral. > > > > Yes, this is quite different. This requires C to maintain clear > > separation of information which A is authority over and information > > which B is authority over and to restrict updates to accordingly. > > You're sort of progressing down the path of X.525's planes of > information, > which is fine for single master replication but isn't meaningful in a > multi-master environment where servers have joint authority over > shared data. There really needs to be only one version of the > shared data > for multi-master replication. > > > > > >Where a DSE is a placeholder for an entry that isn't held > > locally that > > >DSE shouldn't contain shared information that contradicts > the remote > > >master entry. It's painful for replication if it does. > > > > The proposal suggests using named entries to representing > references. > > For a subordinate reference, it proposes that this object have > > an attributes associates with naming, object class referral, and > > object class extensible object. This information my be in > > contradiction with the actual entry DSE it refers to. > > > > When DSE are replicated, receiving server must have a clear > > mechanism for determining the update is associated with the > > portion of the DSE. I've suggested one approach, there are others. > > To be replication friendly, information in a DSE that is > different from > one server to another needs to be in DSA-specific attributes if it is > reflected in any attributes at all. In X.500 the specialness of DSEs > containing references to other DSAs is captured in the dseType, > a DSA-specific operational attribute. It looks to me that LDAP needs > something like it, though in this case the refer attribute itself > would be enough. Roland's description of the processing that > takes place > depends only on the presence of the refer attribute. The object class > of the entry containing the refer attribute doesn't get a mention that > I could see. The definition of the referral object class near the end > is pretty much incidental. > > > > > >> My primary reason of suggesting use of object classes, especially > > >> for subordinate references, is that the semantics need to be > > >> established when the entry is instantiated. > > > > This is my primary concern. I am not sure it makes sense > > to change an entry into an subordinate reference just by > > adding a 'refer' attribute. I believe you should have to > > delete the entry and add a 'referral' entry. I also think > > that a 'referral' entry MUST have a 'refer' attribute. > > If you add a refer attribute to an existing entry then the other > attributes in the entry become meaningless and might as well > be removed. An LDAP DSE type attribute would help if you feel > there is a > need to make a more emphatic display of the fundamental change in the > nature of the DSE. > > With LDUP it would be possible for a replica to hold both the > actual entry contents and the refer attribute, which is basically what > you get if you just add a refer attribute to an existing entry. > We would need to define what that means. A refer attribute in > a read-only > replica is effectively a reference to the server(s) holding the master > entry. Whether you send back a referral in this case would depend > on things like the X.500 dontUseCopy service control. A refer > attribute > in a writeable replica could be a self-reference to the server or a > reference to one of the other mastering servers for that > entry. In either > case the refer attribute is ignored. Anything else is processed as > Roland describes. > > > > > > >The DSEType is not immutable in X.500 > > > > Correct, I should have said that DSEtype is not modifiable by the > > user. > > Not directly, but user actions can affect the DSEType. For example, > adding/removing the administrativeRole attribute changes the admPoint > bit in the DSEType. > > > > > The implication is that certain DSEtype changes make little > > (or no) sense and using the presence or lack of presence of > > an attribute type (or types) to indicate such may not be > > optimal. > > Do I take this to mean that you like the fact that an object class > definition mandates what can and can't be in a referral DSE? > There are other ways to do that, like writing down the requirements, > which is how X.500 deals with the permitted usage of most of the > operational attributes. > > Regards, > Steven > > > > > >That depends on how you interpret clause 19 of X.501:1993. > > It might be > > >legal for a DSE that is not of type "entry", "alias" or > "subentry" to > > >have an objectClass attribute without all the mandatory attributes. > > > > The proposal models references as entries, with object classes, > > with RDN attributes, with musts/may requirements. > > > > > > From list@netscape.com Mon Jul 24 14:41:18 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23342 for ; Mon, 24 Jul 2000 14:41:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6OIUMR14222; Mon, 24 Jul 2000 11:30:33 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6OId8E17243; Mon, 24 Jul 2000 11:39:08 -0700 (PDT) Resent-Date: Mon, 24 Jul 2000 11:39:08 -0700 (PDT) Date: Mon, 24 Jul 2000 13:37:42 -0500 From: Mark Wahl Subject: Re: substring filters using DN attributes ? In-reply-to: "Your message of Fri, 21 Jul 2000 16:45:32 PDT." <3978E09C.969A15FE@software.com> Sender: wahl@austin.innosoft.com To: sanjay jain Cc: ldapext Message-id: <18802.964463862@threadgill.austin.innosoft.com> Resent-Message-ID: <"DO6gi.A.JNE.K1If5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com The default is that the matching rule will not match any values since it doesn't know how to compare. (But the client shouldn't have sent that query in the first place without discovering the schema :-) ) There has been some interest from a number of implementors and users to have matching rules for partial DNs but no I-Ds have yet been published in this ares. Mark Wahl, Directory Architect, Service Provider/Infrastructure Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Mon Jul 24 14:56:58 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28926 for ; Mon, 24 Jul 2000 14:56:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6OIoKU20589; Mon, 24 Jul 2000 11:50:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6OItMU26861; Mon, 24 Jul 2000 11:55:22 -0700 (PDT) Resent-Date: Mon, 24 Jul 2000 11:55:22 -0700 (PDT) Message-Id: <4.3.2.7.0.20000724114442.00afabf0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 11:55:14 -0700 To: Mark Wahl From: "Kurt D. Zeilenga" Subject: Re: substring filters using DN attributes ? Cc: sanjay jain , ldapext In-Reply-To: <18802.964463862@threadgill.austin.innosoft.com> References: <"Your message of Fri, 21 Jul 2000 16:45:32 PDT." <3978E09C.969A15FE@software.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"WgZ4MC.A.bjG.ZEJf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 01:37 PM 7/24/00 -0500, Mark Wahl wrote: >There has been some interest from a number of implementors and users to have >matching rules for partial DNs but no I-Ds have yet been published in this >ares. I've meaning to publish a regexMatch rule I-D which would allow matching of an asserted regular expression against the string representation of attribute values. Of course, to be useful with DNs, we'd have to have to define a canonical string representation of DNs. Given such, you would be able to do DN matching like: (member:regexMatch:=.*,dc=example,dc=com$) Such a matching rule, I believe, would be generally useful in a number of applications. Of course, user applications may not want to expose regular expressions to average Joe. If others concur that this would be generally useful, I'll put up a straw man proposal after IETF#48. Kurt From list@netscape.com Mon Jul 24 17:27:48 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12516 for ; Mon, 24 Jul 2000 17:27:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6OLLKU17037; Mon, 24 Jul 2000 14:21:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6OLQNU05820; Mon, 24 Jul 2000 14:26:23 -0700 (PDT) Resent-Date: Mon, 24 Jul 2000 14:26:23 -0700 (PDT) Message-ID: <00a301bff5b4$c1c5d730$6e00000a@master> Reply-To: "Advertising" From: "Advertising" To: Subject: Best Quality Online Casino on the Internet even better than Download Casinos!!!! Date: Mon, 24 Jul 2000 15:17:02 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009B_01BFF582.390389B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Resent-Message-ID: <"HoEUDD.A.oaB.9RLf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multi-part message in MIME format. ------=_NextPart_000_009B_01BFF582.390389B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FREE NO DOWNLOAD ONLINE CASINO GUARANTEED "BEST QUALITY" ON THE NET Just one click away from YOUR BEST ONLINE CASINO GAMBLING EXPERIENCE Play for free or enjoy=20 5 cent or more Keno 25 cent or more Slots $1 or more Blackjack, Craps, Roulette, or Video Poker. What do you have to loose??? http://www.exclamationpoints-a-cyber-online-casino.com ------=_NextPart_000_009B_01BFF582.390389B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 FREE=20 NO DOWNLOAD ONLINE=20 CASINO
 
GUARANTEED "BEST QUALITY" = ON THE NET
 
Just one click away = from
 
YOUR BEST=20 ONLINE CASINO GAMBLING EXPERIENCE
 
Play for = free
or enjoy
 
5 cent or more=20 Keno
25 cent or more=20 Slots
$1 or more = Blackjack,=20 Craps, Roulette, or Video=20 Poker.
 
What do you have = to=20 loose???
 
http://ww= w.exclamationpoints-a-cyber-online-casino.com
------=_NextPart_000_009B_01BFF582.390389B0-- From list@netscape.com Mon Jul 24 21:15:41 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04607 for ; Mon, 24 Jul 2000 21:15:40 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6P19RU27725; Mon, 24 Jul 2000 18:09:27 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6P1ETQ24465; Mon, 24 Jul 2000 18:14:29 -0700 (PDT) Resent-Date: Mon, 24 Jul 2000 18:14:29 -0700 (PDT) To: Stockpick@aol.com From: Subject: Stock Pick of the Week Message-ID: <0e5581012011970CPIMSSMTPU08@email.msn.com> Date: 24 Jul 2000 18:12:14 -0700 Resent-Message-ID: <"nzMHEB.A._9F.0nOf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com >>> STOCK PICK OF THE WEEK <<< For the week beginning Monday, 07-24-2000 Investment Snapshot - ENET (US) Equalnet Communications http://www.iexchange.com/ii/sl?sidii=5zhn5a29jq.s22av&s=131077&ixname=TAB6&ixvalue=yes&tsym=enet Target Price: $2.00 Current Price: $0.08 Take a close look at this stock, it's going to rise fast! From list@netscape.com Mon Jul 24 21:27:58 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08701 for ; Mon, 24 Jul 2000 21:27:57 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6P1HhR20405; Mon, 24 Jul 2000 18:17:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6P1KuA28404; Mon, 24 Jul 2000 18:20:56 -0700 (PDT) Resent-Date: Mon, 24 Jul 2000 18:20:56 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C7B18B4@aspams01.cai.com> From: "Ramsay, Ron" To: steven.legg@adacel.com.au Cc: ietf-ldapext@netscape.com Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Date: Tue, 25 Jul 2000 11:20:50 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"ZCD56.A.R5G.stOf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Steven, Thank you for your response. I have followed your argument elsewhere regarding interpreting the refer attribute. I find it difficult to travel with you on this one. First, let me review what I have said about the refer attribute. I believe that it should not be replicated except possibly in the situation where you wish to create an identical but read-only copy. You have tried to show how the refer attribute could be interpreted by a replica receiving it. For example, if the reference is (you), discard the attribute and use the normal entry contents. If the reference is not (you), though, we should ask what the reference represents. I may have received it from a colocated DSA but I may receive a more recent value from a DSA on the other side of the world. I guess if it is more recent, I use it? I'm guessing that if I did use it, it would not be appropriate. Maybe I should be using the entry contents that I received from the master. In this case you would look at the 'dontUseCopy' option. (Isn't that DAP-only?) If a refer attribute is updated, will it be replicated? I guess it would, but it is possible that it was only updated to fix a problem with the replication where it was actually given the wrong value. References are the means by which a distributed DIT is created. Allowing them to be replicated means that rules will have to be created outside the LDAP model to handle them. This seems to me to be worse than the problem we are trying to solve. We will probably need more options as well. For example, ;read-only will help with dont-use-copy: refer, refer;sub, refer;sub;read-only. Ron. -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Monday, 24 July 2000 18:21 To: Ramsay, Ron Cc: ietf-ldapext@netscape.com Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Ron, > -----Original Message----- > From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com] > Sent: Friday, 21 July 2000 16:36 > To: steven.legg@adacel.com.au; 'Kurt D. Zeilenga' > Cc: ietf-ldapext@netscape.com > Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt > > > Hi, > > I'm having trouble following the bit about replicating the > refer attribute. > I agree that it should be a DSA-specific attribute. I didn't say that. The current usage of distributedOperation is appropriate, at least for the cases of refer;sub, refer;nssr and refer;cross. But refer;sup and refer;me really should be dSAOperation since their values are only useful to the local server (so there is a case for the use of separate attribute types instead of attribute options). > But my > conclusion would > be that it *cannot* be replicated. > > I suppose, under master-slave replication, you could specify that all > entries are copied verbatim (though the refer attribute may > now point to a > DSA which is no longer, eg, local), but for master-master > replication there > would seem to be no situation in which the attribute can be > replicated. (I > should have given a long-sentence alert!) In multi-master replication, > presumably one of the replicas has the actual entry. If this entry is > updated, the updates will be sent to the other masters, so > they now have > (parts of) the whole entry. The refer attribute now seems to be > out-of-place? It does, but we have various ways to deal with this situation. 1) We could choose to never replicate the refer attribute (make it completely DSA-specific). However there are good reasons for replicating sub & nssr. For example, it's not unreasonable for me to want to create a read-only replica of a master server that contains all the same distributed knowledge references. Having to manually maintain the references in the read-only replica would be annoying. 2) We could put special case processing into LDUP to drop the refer attribute in the circumstances where it would be "out of place". Given that the determination of "out of place" is dependent on a changeable replication topology, the propagation delays of same, and the properties of the yet to be defined partial replication, I'm a bit wary of this solution. 3) Allow the refer attribute (except ;me & ;sup) to be replicated like any other DSA-shared attribute and define the semantics so that it is ignored whenever, and for as long as, it is considered "out of place". This is the line I've been following. I think we can define this with more certainty than 2. > > I should think the entry itself is DSA-specific! > > Note that, if NSSRs are retained, the NSSR will actually be > carried in a > real entry. If the NSSR is like the X.500 NSSR then it is carried in the immediate superior entry of the unspecified naming context(s). So yes, replication aside, that is a real entry with a regular object class (i.e. not referral). > I think this complicates Steven's argument. Not too much I think. Any of the unspecified naming contexts could be present as a result of a replication agreement, in which case they are no different from any local subordinate entries that were already present (I'm assuming that refer;nssr allows local subordinates to be present also). The awkward part is that we might not be able to tell whether *all* the unspecified subordinates have been replicated. To be safe referral/continuation references would have to be returned, so a client might end up collecting more duplicates than if the NSSR were absent. I'm not sure that solution 2) could do much better for NSSRs. Neither the supplier nor the consumer can determine with 100% certainty in all cases whether the NSSR should be replicated. Regards, Steven From list@netscape.com Mon Jul 24 23:18:50 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09940 for ; Mon, 24 Jul 2000 23:18:49 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6P3COU09685; Mon, 24 Jul 2000 20:12:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6P3HRw03261; Mon, 24 Jul 2000 20:17:27 -0700 (PDT) Resent-Date: Mon, 24 Jul 2000 20:17:27 -0700 (PDT) From: harold43@020.co.uk Content-Type: text/plain Message-ID: Subject: I actually eat lunch with my kids EVERY DAY! To: X-Accept-Language: en Date: Mon, 24 Jul 2000 20:23:21 Resent-Message-ID: <"pKUGZC.A.ry.FbQf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Let's cut to the chase... I am a entreprenuer engaged in free enterprise. I am looking for positive, motivated people that want and need to increase their income by a minimum of 10k per month. Do you have a burning desire to change the quality of your existing life? Would you like to live the life that most others only dream about? How would you like to: A. Drastically reduce personal, business and capitol gains taxes? B. Protect all assets from any form of seizure, liens, or judgments? C. Create a six figure income every 4 months? How about: A. Restoring and preserving complete personal and financial privacy? B. Create and amass personal wealth, multiply it and protect it? C. Realize a 3 to 6 times greater returns on your money? D. Legally make yourself and your assets completely judgment-proof, seizure-proof, lien-proof, divorce-proof, attorney-proof, IRS-proof, and become completely insulated? If you answered yes to ANY of these questions we can help you... If you think this is too good to be true or are skeptical then this may not be for you... Many have been conditioned to believe it must be illegal, immoral or unethical to ever earn any real profits from their efforts. The fact is we have many people in our enterprise who earn over 50k per month from the privacy of their own home and are retiring in 2-3 years obviously wealthy and having total freedom both personal and financial. Are you a BIG thinker, BIG dreamer and a person that believes they deserve to have the best in life? Are you capable of recognizing that once in a lifetime opportunity when it's looking right at you? Countless others have missed their shot at the title only to look back years later and wished they should've because they could've. If you are serious about changing your life...and breaking the past chains of financial limitations... Call toll free 1-800-287-7755 (24 hr recorded 2 minute message) HIGH INTEGRITY! - NOT MLM! Best Regards --------------------------------------- This message is being sent to you in compliance with the proposed Federal legislation for commercial e-mail (S.1618 - SECTION 301). "Pursuant to Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this e-mail may be stopped at no cost to you by submitting a request to REMOVE --------------------------------------- ********************************************************************* It may be, then, that the appearance of parasitic gaps in domains relatively inaccessible to ordinary extraction is, apparently, determined by Propp's basic formulation. In respect to specific goals, relational information appears to correlate rather closely with the overall negative profitability. In theory, most of the methodological work in modern linguistics recognizes other systems' importance and the necessity for the profound meaning of "The Raw and the Cooked". Presumably, the independent functional principle is necessary to impose an interpretation on all deeper structuralistic conceptualization. ********************************************************************* From list@netscape.com Tue Jul 25 01:06:24 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08543 for ; Tue, 25 Jul 2000 01:06:23 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6P4xoU16654; Mon, 24 Jul 2000 21:59:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6P54rs27997; Mon, 24 Jul 2000 22:04:53 -0700 (PDT) Resent-Date: Mon, 24 Jul 2000 22:04:53 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C7C194A@aspams01.cai.com> From: "Lloyd, Alan" To: "Ramsay, Ron" , steven.legg@adacel.com.au Cc: ietf-ldapext@netscape.com Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Date: Tue, 25 Jul 2000 15:05:08 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"K-dPzB.A.L1G.0_Rf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Sorry to but in here - but I am also a bit lost with the rationale behind referal stuf - to this detail. At the operational level (not the theoretical - probable situation level) - when one builds a distributed large scale directory service that contains load balancing, fault tolerance, alternate DSA features (implied replica DSAs) anywhere - when one needs a distributed mesh.. and read only, multi master, update only, modes of operations - One realises the knowledge issues are not just referral attributes but back bone control properties.. I think where we are coming from is that we have this stuff operational - eg load balancing, fault tolerant mesh systems supporting WEB TV - V-ISP services - and the details proposed - well they seem to be a liitle extraordinary and rely on very intelligent browser devices to deal with them. Can you imagine my mum on her digital WEB TV looking for her sisters phone number - and a response = "Please follow ref:nssr..." To me refrrals are bad news - directory service users - DONT WANT THEM...one needs to have a distributed / replicated seamless directory service.. Can you see the telephone working this way? "dont try here.. try there"..or try else where - but I dont know where. regards alan -----Original Message----- From: Ramsay, Ron Sent: Tuesday, July 25, 2000 11:21 AM To: steven.legg@adacel.com.au Cc: ietf-ldapext@netscape.com Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Steven, Thank you for your response. I have followed your argument elsewhere regarding interpreting the refer attribute. I find it difficult to travel with you on this one. First, let me review what I have said about the refer attribute. I believe that it should not be replicated except possibly in the situation where you wish to create an identical but read-only copy. You have tried to show how the refer attribute could be interpreted by a replica receiving it. For example, if the reference is (you), discard the attribute and use the normal entry contents. If the reference is not (you), though, we should ask what the reference represents. I may have received it from a colocated DSA but I may receive a more recent value from a DSA on the other side of the world. I guess if it is more recent, I use it? I'm guessing that if I did use it, it would not be appropriate. Maybe I should be using the entry contents that I received from the master. In this case you would look at the 'dontUseCopy' option. (Isn't that DAP-only?) If a refer attribute is updated, will it be replicated? I guess it would, but it is possible that it was only updated to fix a problem with the replication where it was actually given the wrong value. References are the means by which a distributed DIT is created. Allowing them to be replicated means that rules will have to be created outside the LDAP model to handle them. This seems to me to be worse than the problem we are trying to solve. We will probably need more options as well. For example, ;read-only will help with dont-use-copy: refer, refer;sub, refer;sub;read-only. Ron. -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Monday, 24 July 2000 18:21 To: Ramsay, Ron Cc: ietf-ldapext@netscape.com Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Ron, > -----Original Message----- > From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com] > Sent: Friday, 21 July 2000 16:36 > To: steven.legg@adacel.com.au; 'Kurt D. Zeilenga' > Cc: ietf-ldapext@netscape.com > Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt > > > Hi, > > I'm having trouble following the bit about replicating the > refer attribute. > I agree that it should be a DSA-specific attribute. I didn't say that. The current usage of distributedOperation is appropriate, at least for the cases of refer;sub, refer;nssr and refer;cross. But refer;sup and refer;me really should be dSAOperation since their values are only useful to the local server (so there is a case for the use of separate attribute types instead of attribute options). > But my > conclusion would > be that it *cannot* be replicated. > > I suppose, under master-slave replication, you could specify that all > entries are copied verbatim (though the refer attribute may > now point to a > DSA which is no longer, eg, local), but for master-master > replication there > would seem to be no situation in which the attribute can be > replicated. (I > should have given a long-sentence alert!) In multi-master replication, > presumably one of the replicas has the actual entry. If this entry is > updated, the updates will be sent to the other masters, so > they now have > (parts of) the whole entry. The refer attribute now seems to be > out-of-place? It does, but we have various ways to deal with this situation. 1) We could choose to never replicate the refer attribute (make it completely DSA-specific). However there are good reasons for replicating sub & nssr. For example, it's not unreasonable for me to want to create a read-only replica of a master server that contains all the same distributed knowledge references. Having to manually maintain the references in the read-only replica would be annoying. 2) We could put special case processing into LDUP to drop the refer attribute in the circumstances where it would be "out of place". Given that the determination of "out of place" is dependent on a changeable replication topology, the propagation delays of same, and the properties of the yet to be defined partial replication, I'm a bit wary of this solution. 3) Allow the refer attribute (except ;me & ;sup) to be replicated like any other DSA-shared attribute and define the semantics so that it is ignored whenever, and for as long as, it is considered "out of place". This is the line I've been following. I think we can define this with more certainty than 2. > > I should think the entry itself is DSA-specific! > > Note that, if NSSRs are retained, the NSSR will actually be > carried in a > real entry. If the NSSR is like the X.500 NSSR then it is carried in the immediate superior entry of the unspecified naming context(s). So yes, replication aside, that is a real entry with a regular object class (i.e. not referral). > I think this complicates Steven's argument. Not too much I think. Any of the unspecified naming contexts could be present as a result of a replication agreement, in which case they are no different from any local subordinate entries that were already present (I'm assuming that refer;nssr allows local subordinates to be present also). The awkward part is that we might not be able to tell whether *all* the unspecified subordinates have been replicated. To be safe referral/continuation references would have to be returned, so a client might end up collecting more duplicates than if the NSSR were absent. I'm not sure that solution 2) could do much better for NSSRs. Neither the supplier nor the consumer can determine with 100% certainty in all cases whether the NSSR should be replicated. Regards, Steven From list@netscape.com Tue Jul 25 01:23:47 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18959 for ; Tue, 25 Jul 2000 01:23:46 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6P5DUR07345; Mon, 24 Jul 2000 22:13:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6P5MFw01885; Mon, 24 Jul 2000 22:22:16 -0700 (PDT) Resent-Date: Mon, 24 Jul 2000 22:22:16 -0700 (PDT) Message-ID: <397D241C.7B4E9559@netscape.com> Date: Tue, 25 Jul 2000 01:22:36 -0400 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Subject: Re: Persistent Search References: <397ABA5F.19226.41E16AF@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ScvjL.A.Ld.FQSf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit David Chadwick wrote: > > Mark > I think there is a small bug in Persistent Search. In clause 4b) you > state > > b) The server MUST NOT return a SearchResult message. > Instead, the search operation MUST be kept active until it is > abandoned by the client or until the client unbinds. > > I think this shoud read > b) The server MUST NOT return a SearchResultDone message. You are correct. I will fix this in the next revision of the I-D. Thanks. When you have a chance, please review the LCUP I-D as well: http://www.ietf.org/internet-drafts/draft-natkovich-ldap-lcup-01.txt -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? From list@netscape.com Tue Jul 25 08:57:52 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05265 for ; Tue, 25 Jul 2000 08:57:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PCldR02382; Tue, 25 Jul 2000 05:47:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PCuQk18692; Tue, 25 Jul 2000 05:56:26 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 05:56:26 -0700 (PDT) From: email@postd.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-Id: <5fir8bcih0op6n.nql47s855s5y73yi3@webcom.com> Subject: ADV - 10 MILLION ADDRESSES! To: fed@%domain.netscape.com Reply-To: emailingnow@post.com Date: Sat, 20 Nov 1999 05:56:04 -0800 Resent-Message-ID: <"1DlQtB.A.yjE.35Yf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8BIT 10 MILLION EMAIL ADDRESSES FOR ONLY $99 You want to make some money? we can put you in touch with over 10 million people at virtually no cost. Can you make one cent from each of theses names? If you can you have a profit of over $250,000.00 That's right, we have 10 Million Fresh email addresses that we will sell for only $99. These are all fresh addresses with no duplications. They are all sorted and ready to be mailed. That is the best deal anywhere today! Imagine selling a product for only $5 and getting only a 1/10% response. That's $1,350,000 in your pocket !!! Don't believe it? People are making that kind of money right now by doing the same thing, that is why you get so much email from people selling you their product....it works! we will even include, a FREE demo copy of the worlds leading BULK MAILING SOFTARE! These 10 Million email addresses and software are yours to keep, so you can use them over and over and they come on 1 CD. This offer is not for everyone. If you can not see just how excellent the risk / reward ratio in this offer is then there is nothing we can do for you. To make money you must stop dreaming and TAKE ACTION. **************************************** 10 MILLION email addresses on CD These name are all in text files ready to mail!!! (includes bulk mailing sotware) $99.00 ************************************************************* VISA/MC ONLY STEP 1: Print out the below ORDER FORM STEP 2: Type or Print your order information into the form STEP 3: FAX Your order to us. FAX TO: 415-704-3071 (Order with confidence. This is a secure fax area. Only our qualified sales team will have access to your order information) ORDER FORM(Print clearly with DARK pen) ************************************************************************************************ Name: ________________________________ Address: ________________________________ * *BILLING ADDRESS ONLY City, State, ZIP: ________________________________ Country: ______________ (International Orders) Phone Number: ______________ (In case we can't make out your order) METHOD OF PAYMENT- CREDIT CARD ONLY [ ]Visa [ ]MasterCard Credit Card #: __________________________________ Exp Date: _______________ Signature: ____________________________ (Required) E-Mail Address: ____________________________ *(PRINT CLEARLY!!) ************************************************************************************************ WE WILL BILL 99.00 to your account plus the following shipping costs SHIPPING COST OF 4.85 FIRST CLASS MAIL INTERNATIOMAL ORDERS ADD 25.00 U.S. DOLLARS ALL INFORMATION NECESSARY FOR YOU TO SUCCESSFULLY MAIL, QUICKLY, PROPERLY, LEGALLY PROVIDED WITH ORDER Copyright 2000 All rights reserved From list@netscape.com Tue Jul 25 09:55:50 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22927 for ; Tue, 25 Jul 2000 09:55:49 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PDjSR07003; Tue, 25 Jul 2000 06:45:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PDsFk04531; Tue, 25 Jul 2000 06:54:15 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 06:54:15 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: mcs@netscape.com (Mark C Smith) Date: Tue, 25 Jul 2000 14:53:06 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Persistent Search Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <397DA9D2.16002.1330A2D@localhost> Priority: normal In-reply-to: <397D241C.7B4E9559@netscape.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"2mH8QB.A.EGB.EwZf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date sent: Tue, 25 Jul 2000 01:22:36 -0400 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions > When you have a chance, please review the LCUP I-D as well: > > http://www.ietf.org/internet-drafts/draft-natkovich-ldap-lcup-01.txt > > -- Have done. I did not find any bugs in it. Though there are a lot of questions that are raised in the later sections. I dont really feel very strongly either way about any of them David > Mark Smith > Directory Product Development / iPlanet E-Commerce Solutions > My words are my own, not my employer's. Got LDAP? > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Tue Jul 25 09:56:13 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23068 for ; Tue, 25 Jul 2000 09:56:12 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PDjeR07141; Tue, 25 Jul 2000 06:45:40 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PDsRY04863; Tue, 25 Jul 2000 06:54:27 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 06:54:27 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" Date: Tue, 25 Jul 2000 14:53:07 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: filters in ldapACI (WAS Re: I-D ACTION:draft-ietf-ldapext-acl-model-06.txt) Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <397DA9D3.13775.1330CC2@localhost> Priority: normal In-reply-to: <4.3.2.7.0.20000723104708.00af3e40@infidel.boolean.net> References: <397ABA5E.13298.41E1213@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"uSzoeC.A.LKB.OwZf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Kurt said > Though both X.500 subentry and ldapACI offer sophisticated > scoping specification mechanisms, the X.500 subentry is a general > mechanism which can be applied to numerous features. That is, a > server can implement the subentry complexity once and then apply it to > multiple features. ldapACI's mechanism is specific to the feature it > provides. Other attributes would have to define it's own scoping > mechanisms (or use X.500's subentry provided mechanism). > Kurt I am not sure whether you are arguing for or against the X.500 subentry type of mechanism in your statements above? Or was it just an observation? David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Tue Jul 25 09:56:22 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23130 for ; Tue, 25 Jul 2000 09:56:22 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PDmoU20517; Tue, 25 Jul 2000 06:48:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PDrso04104; Tue, 25 Jul 2000 06:53:54 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 06:53:54 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Ramsay, Ron" , ietf-ldapext@netscape.com Date: Tue, 25 Jul 2000 14:53:05 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <397DA9D1.30196.1330582@localhost> Priority: normal In-reply-to: <11981F9F5649D411BC92009027D0D18C74114A@aspams01.cai.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"F-J7r.A.0_.wvZf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT > Hi, > > I'm having trouble following the bit about replicating the refer > attribute. I agree that it should be a DSA-specific attribute. But my > conclusion would be that it *cannot* be replicated. I would disagree. Both X.500 and DNS allow references to be replicated. > > I suppose, under master-slave replication, you could specify that all > entries are copied verbatim (though the refer attribute may now point > to a DSA which is no longer, eg, local), but for master-master > replication there would seem to be no situation in which the attribute > can be replicated. (I should have given a long-sentence alert!) In > multi-master replication, presumably one of the replicas has the > actual entry. Not necessarily so. Image the case of a country level LDAP referral server with a subordinate reference to an organisation LDAP server. If the country level server is now part of a pan-European (say) set of country level multi-masters, then the organisation entry still is not held by any of them, and the sub ref is still valid when held by all the country LDAP servers. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Tue Jul 25 09:59:01 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24054 for ; Tue, 25 Jul 2000 09:59:01 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PDqEU22206; Tue, 25 Jul 2000 06:52:14 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PDsfc05221; Tue, 25 Jul 2000 06:54:41 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 06:54:41 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Steven Legg" , , "'Kurt D. Zeilenga'" Date: Tue, 25 Jul 2000 14:53:04 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: refer-00.txt - separate attributes or options or object classes Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <397DA9D0.18899.133009B@localhost> Priority: normal In-reply-to: <001801bff15d$5814bd70$b05508cb@osmium.adacel.com.au> References: <4.3.2.7.0.20000714091302.00b48510@infidel.boolean.net> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"DGVArD.A._PB.cwZf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Steven said > > I'd prefer to use separate attributes instead of separate options to > convey the semantics but that's not critical. > In fact the two can be the same to my mind. An option is an attribute subclass, and by defining an OID for the option/subclass, you achieve the same thing. (Similar to name and commonName) > > > 2.1 The refer attribute > > > The refer attribute can be further specified by the use > > of options as > > > defined in section 4.1.5 of [RFC2251]. This document defines > > > five options and their use. Future documents might defined > > other options. In fact it defines six. If just forgot to describe refer;other at the start of the ID > > > > Is an option required? If not, what is the semantics of an > > optionless refer attribute? Good question. In fact, I would say that the attribute should always have an option defined. (just as we never use the name attribute on its own, but always a subtype of it) However, there is one problem with the option/subtype route, and that is the DSAOperation vs. DistributedOperation question. I believe that some (sup, me) are for local DSAOperation use, whilst others (cross, sub, other) are domain replicable i.e. for DistributedOperation use. This is why in my 1998 ID I had TWO attribute types, named sharedRef and privateRef. I still think this requirement exists. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Tue Jul 25 10:57:47 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15469 for ; Tue, 25 Jul 2000 10:57:43 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PEoKU28310; Tue, 25 Jul 2000 07:50:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PEtNo23952; Tue, 25 Jul 2000 07:55:23 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 07:55:23 -0700 (PDT) Message-Id: <4.3.2.7.0.20000725074549.00b4d520@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jul 2000 07:55:05 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: filters in ldapACI (WAS Re: I-D ACTION:draft-ietf-ldapext-acl-model-06.txt) Cc: ietf-ldapext@netscape.com In-Reply-To: <397DA9D3.13775.1330CC2@localhost> References: <4.3.2.7.0.20000723104708.00af3e40@infidel.boolean.net> <397ABA5E.13298.41E1213@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"sg2v_.A.-1F.apaf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 02:53 PM 7/25/00 +0100, David Chadwick wrote: >Kurt said > >> Though both X.500 subentry and ldapACI offer sophisticated >> scoping specification mechanisms, the X.500 subentry is a general >> mechanism which can be applied to numerous features. That is, a >> server can implement the subentry complexity once and then apply it to >> multiple features. ldapACI's mechanism is specific to the feature it >> provides. Other attributes would have to define it's own scoping >> mechanisms (or use X.500's subentry provided mechanism). >> > >I am not sure whether you are arguing for or against the X.500 >subentry type of mechanism in your statements above? Or was it >just an observation? I making a argument for a common scoping mechanism that can be applied to multiple attributes. I believe having per attribute scoping mechanisms, such as ldapACI's subtree mechanism, is a bad idea. Kurt From list@netscape.com Tue Jul 25 11:32:32 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28653 for ; Tue, 25 Jul 2000 11:32:31 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PFQ2U02687; Tue, 25 Jul 2000 08:26:03 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PFV6207614; Tue, 25 Jul 2000 08:31:06 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 08:31:06 -0700 (PDT) Message-Id: <3.0.5.32.20000725083032.008f5100@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 25 Jul 2000 08:30:32 -0700 To: Ellen Stokes , d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com From: Bruce Greenblatt Subject: Re: delete permission In-Reply-To: <4.2.2.20000723204102.00a38ca0@popmail2.austin.ibm.com> References: <397ABA5A.22548.41E0205@localhost> <4.2.2.20000721093904.00a4c860@popmail2.austin.ibm.com> <39777C0C.3873.5C6CB59@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"tee1m.A.q2B.4Kbf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com >> >> > David, >> > >> > On relating the subtreeACI and subtree operation... >> > >> > My thinking is that if there is a subtreeACI with a delete permission, >> > then when the subtree delete operation is executed on the server, the >> > subtreeACI is checked for delete permission and since it is set the >> > subtree operation succeeds. >> >>Not so. There may be an entry somewhere in the subtree that >>forbids the deletion of that single entry. Therefore the subtree >>delete should fail, as the client does not have permission to delete >>the whole tree. This is why I said that separation of the ACI into two >>attributes made no difference at all. > >(EJS) I now see your point. > > A seperate but related issue to how the delete permission overrides the delete subtree permission, is the more general problems of how to treat overlapping permissions. I don't know that there needs to be a general treatment, but when a new permission that is defined overlaps with a previously defined permission, there should be some discussion of the relationship. Any thoughts? Bruce ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html From list@netscape.com Tue Jul 25 12:35:35 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19519 for ; Tue, 25 Jul 2000 12:35:35 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PGPMR25641; Tue, 25 Jul 2000 09:25:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PGY9E04089; Tue, 25 Jul 2000 09:34:09 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 09:34:09 -0700 (PDT) Sender: Robert.Byrne@france.Sun.COM Message-ID: <397DC154.E2E564B3@france.sun.com> Date: Tue, 25 Jul 2000 18:33:24 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Subject: Re: rename permission References: <3973746B.27387.2A93047@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"7SKv_.A.b_.AGcf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit David, Thanks for teasing out all the cases--that helps understanding of what it means to grant rename in the modifyDN operation I think the reason we felt it would be acceptable to let "n" imply the "o" and "w" permissions on the affected attributes was that we felt that the rename permission was was special enough to allow this--I would venture that it's mostly granted to only a few, pretty well trusted users (ie. can be trusted not to fool around with their "w" and "o" implied permissions). Also, there is schema checking which should help stop truly bizzarre attributes showing up as the rdn. However, although this kind of "permission implication" simplifies the spec I think it's big drawback is that it introduces a kind of side effect that makes it harder at aci configure time to understand exactly what policy it is that you have configured. For example, you might think you have locked down access to the sn attribute by carefully controlling the "o" and "w" permissions to it, but you need to remember that an aci that grants "n" to an entry could also grant "o" and "w" type access to the sn attribute of that entry. So, I think your suggestion of also checking "o" and "w" permissions on this operation is good. There is one other operation where this kind of "implication" occurs--it's the Delete operation (section 5.5). We take "d" on an entry as implying "o" on all the attributes of that entry. Given the above this kind of needles me though I think the getout is that the Delete operation is alot more straightforward than the modifyDN operation. So that when an admin sees "d" on an entry, he will probably not be surprised that this grants "o" on all the attributes of the entry. Rob. David Chadwick wrote: > Ellen and co > > there are many different variants of the ModifyDN operation, and > you have only captured some of them in your text in section 5.6. > Specifically one can > > i) Rename an entry by moving the conceptual RDN flag between > two existing attribute values, without altering any attribute values at > all > > ii) rename an entry by adding a new attribute value > > iii) rename an entry using an existing attribute value and delete the > current attribute value > > iv) rename an entry adding a new attribute value and deleting the > current attribute value > > v) move an entry to a new place in the DIT, keeping its existing > RDN as is > > vi) move an entry to a new place coupled with i) above > vii) move coupled with ii) above > viii) move coupled with iii) above > ix) move coupled with iv) above > > Now we already have all the component permissions for each of the > above, in the write, obliterate, import, export and renameDN > permissions. We use write and obliterate when adding and deleting > attribute values with the Modify operation. To be consistent with the > Modify operation, this would mean that permissions for ModifyDN > would become > > i) needs renameDN only > ii) needs renameDN and write > iii) needs renameDN and obliterate > iv) needs renameDN, write and obliterate > v) needs import and export > vi) needs import, export and renameDN > vii) needs import, export, renameDN and write > viii) needs import, export, renameDN and obliterate > ix) needs import, export, renameDN, write and obliterate > > This seems sensible to me, as each permission keeps its logical > meaning, and it should make it a lot easier to explain the operation > as no special cases then exist. I think your NoteB is slightly > spurious, since renameDN clearly gives ModifyDN permission and > without it you cannot effect a change of DN (other than to import > and export). renameDN does not effect Modify operation > permission. Also when you give o and w (Modify) permission you > give it to attributes, not to the entire entry. Therefore if you do not > want someone to have Modify permission but you want them to > have only ModifyDN permission with the scheme above you can > give them precisely how much DN modification you want. I contend > that if you are happy to allow someone to modify a RDN, you must > be happy for them to update (modify) the attribute(s) comprising the > RDN (its illogical to say otherwise). Further, with the scheme as it > stands RenameDN is given to the whole entry, without limiting > attribute types, so you have no means of controlling how much or > little renaming they can do. They could for instance change the RDN > from CN=Ellen Stokes to TelNo=1234, and the access controls as > they stand cannot stop this. With the proposed scheme above they > can. > > Comments? > > David > > *************************************************** > > David Chadwick > IS Institute, University of Salford, Salford M5 4WT > Tel +44 161 295 5351 Fax +44 161 745 8169 > Mobile +44 790 167 0359 > Email D.W.Chadwick@salford.ac.uk > Home Page http://www.salford.ac.uk/its024/chadwick.htm > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string MLJ9-DU5T-HV8J > > *************************************************** From list@netscape.com Tue Jul 25 14:13:53 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18763 for ; Tue, 25 Jul 2000 14:13:52 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PI2FR11972; Tue, 25 Jul 2000 11:02:16 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PIB2k02254; Tue, 25 Jul 2000 11:11:02 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 11:11:02 -0700 (PDT) Message-ID: <28560036253BD41191A10000F8BCBD11841BD1@zcard00g.ca.nortel.com> From: "Mircea Pana" To: ietf-ldapext@netscape.com, "'mcs@netscape.com'" Subject: RE: Persistent Search Date: Tue, 25 Jul 2000 14:07:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF663.301B1660" X-Orig: Resent-Message-ID: <"6VNajB.A.Ri.0gdf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFF663.301B1660 Content-Type: text/plain; charset="iso-8859-1" Mark, LCUP does not describe any specific behavior for continuation references. The document only states that "the server returns a set of SearchResultEntries that fits the client's specification.". No mention of SearchResultReferences. Was this the intent of the authors? Assuming that for a search operation, the server would normally return continuation references, what is supposed to happen when the same search request contains a clientUpdate control that indicates the client's intent to initiate a synchronization session? What is supposed to happen when the server acquires knowledge of a subordinated naming context on a different server, while synchronizing a client? What should happen in the opposite case: when knowledge of a subordinates naming context is removed from the server? etc. Should the ManageDsaIT control be used when the client has interest in the knowledge information and its evolution? ...quite limiting, this sounds more like a work-around than a solution. Thanks, Mircea. ------_=_NextPart_001_01BFF663.301B1660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Persistent Search

Mark,

LCUP does not describe any specific behavior for = continuation references. The document only states that "the server = returns a set of SearchResultEntries that fits the client's = specification.". No mention of SearchResultReferences.

Was this the intent of the authors?

Assuming that for a search operation, the server = would normally return continuation references, what is supposed to = happen when the same search request contains a clientUpdate control = that indicates the client's intent to initiate a synchronization = session?

What is supposed to happen when the server acquires = knowledge of a subordinated naming context on a different server, while = synchronizing a client? What should happen in the opposite case: when = knowledge of a subordinates naming context is removed from the server? = etc.

Should the ManageDsaIT control be used when the = client has interest in the knowledge information and its evolution? = ...quite limiting, this sounds more like a work-around than a = solution.

Thanks,
Mircea.

------_=_NextPart_001_01BFF663.301B1660-- From list@netscape.com Tue Jul 25 14:24:14 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21996 for ; Tue, 25 Jul 2000 14:24:14 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PIH4U02690; Tue, 25 Jul 2000 11:17:04 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PIM7U08490; Tue, 25 Jul 2000 11:22:07 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 11:22:07 -0700 (PDT) Sender: Robert.Byrne@france.Sun.COM Message-ID: <397DCC86.47B256EE@france.sun.com> Date: Tue, 25 Jul 2000 19:21:10 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Subject: Re: Authentication Level References: <39744012.26353.5C48E09@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"eIia4B.A.YEC.Ordf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit David, This still seems like a security "feature" rather than a logical or security "MUST". What I mean is the deny/authnlevel behaviour you are proposing seems to be a shorthand for a behaviour that can be expressed without making a special case of deny/authnlevel. So, where you would "deny Rob Byrne with authnlevel TLS + certificate" I would "deny Rob Byrne with authnlevel TLS + certificate" _and_ "deny ALL with any other authnlevel". If your proposal is just a shorthand then I'm wondering if having the two policies stated explicitly isn't better. If you're proposal is required by the model...then I guess you are going to tell me so... Rob. David Chadwick wrote: > Date sent: Tue, 18 Jul 2000 10:50:03 +0200 > From: Rob Byrne - Sun Microsystems > Organization: Sun Microsystems > To: d.w.chadwick@salford.ac.uk > Copies to: ietf-ldapext-acm@OpenLDAP.org > Subject: Re: Authentication Level > > > > > David, > > > > I think the behaviour of authnLevel is a mattter of definition and I > > do not see why we need to make a special case of the authnLevel > > subject setting when a deny() is present. > > Rob > > Its a matter of security. Say I want to deny Rob Byrne, who must > be authenticated with TLS + certificate, then everyone who is NOT > TLS + certificate authenticated MUST be denied access as well, > otherwise Rob Byrne can log in unauthenticated and not be denied > access. > > In other words, to prove that I am not denied access I must log in > with TLS + certificate to prove I am David Chadwick and not Rob > Byrne. In this way, deny works differently to grant access. > > David > > > > > The other thing is I don't think there is an ordering defined on the > > values of this keyword--so that you could even say something like "at > > least the level specified". Maybe it's just a badly named keyword ? > > > > Rob. > > > > David Chadwick wrote: > > > > > Ellen] > > > > > > An important point about the authentication level (which I could not > > > find in the draft) is that for the permission to be granted the > > > subject must have been authenticated to at least the level > > > specified, but that if the right is a deny, then EVERYONE is denied > > > access unless they have been authenticated to at least the level > > > specified in authnLevel. > > > > > > David > > > > > > *************************************************** > > > > > > David Chadwick > > > IS Institute, University of Salford, Salford M5 4WT > > > Tel +44 161 295 5351 Fax +44 161 745 8169 > > > Mobile +44 790 167 0359 > > > Email D.W.Chadwick@salford.ac.uk > > > Home Page http://www.salford.ac.uk/its024/chadwick.htm > > > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > > > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > > > Entrust key validation string MLJ9-DU5T-HV8J > > > > > > *************************************************** > > > > > > *************************************************** > > David Chadwick > IS Institute, University of Salford, Salford M5 4WT > Tel +44 161 295 5351 Fax +44 161 745 8169 > Mobile +44 790 167 0359 > Email D.W.Chadwick@salford.ac.uk > Home Page http://www.salford.ac.uk/its024/chadwick.htm > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string MLJ9-DU5T-HV8J > > *************************************************** From list@netscape.com Tue Jul 25 14:49:31 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28723 for ; Tue, 25 Jul 2000 14:49:31 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PIh0U08907; Tue, 25 Jul 2000 11:43:00 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PIm2Y22809; Tue, 25 Jul 2000 11:48:03 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 11:48:03 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: Ellen Stokes , ietf-ldapext@netscape.com, Bruce Greenblatt Date: Tue, 25 Jul 2000 19:46:59 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: delete permission Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <397DEEB3.6126.2402040@localhost> Priority: normal In-reply-to: <3.0.5.32.20000725083032.008f5100@pop.walltech.com> References: <4.2.2.20000723204102.00a38ca0@popmail2.austin.ibm.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"hzifs.A.TjF.fDef5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT > A seperate but related issue to how the delete permission overrides > the delete subtree permission, is the more general problems of how to > treat overlapping permissions. I don't know that there needs to be a > general treatment, but when a new permission that is defined overlaps > with a previously defined permission, there should be some discussion > of the relationship. Any thoughts? The document is already starting to do this by giving precedence to the different elements such as subject. Therefore I think that if everthing can be given a pecking order/precedence, and this can be described fully in the model doc, then everything should fall out in the wash, shouldn't it? David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Tue Jul 25 15:53:31 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17322 for ; Tue, 25 Jul 2000 15:53:31 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PJhAR28688; Tue, 25 Jul 2000 12:43:11 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PJpwQ20635; Tue, 25 Jul 2000 12:51:58 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 12:51:58 -0700 (PDT) Message-ID: <397DC1EE.3024C2AD@netscape.com> Date: Tue, 25 Jul 2000 09:35:58 -0700 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Mark Wahl , sanjay jain , ldapext Subject: Re: substring filters using DN attributes ? References: <"Your message of Fri, 21 Jul 2000 16:45:32 PDT." <3978E09C.969A15FE@software.com> <4.3.2.7.0.20000724114442.00afabf0@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"aXcMN.A.FCF.d_ef5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > I've meaning to publish a regexMatch rule I-D which would allow > matching of an asserted regular expression against the string > representation of attribute values. Of course, to be useful with > DNs, we'd have to have to define a canonical string representation > of DNs. Given such, you would be able to do DN matching like: > > (member:regexMatch:=.*,dc=example,dc=com$) > > Such a matching rule, I believe, would be generally useful in > a number of applications. Of course, user applications may > not want to expose regular expressions to average Joe. > > If others concur that this would be generally useful, I'll put > up a straw man proposal after IETF#48. It would be interesting to see examples of the kinds of LDAP application problems that would be more easily addressed if such a matching rule was available. If all we really need is a way to anchor the start and end of strings (i.e., ^ and $ from regex), I'd rather see a more narrow proposal. Why? Because general regular expression matching will be quite difficult to support using indexes, etc. -- Mark Smith Directory Product Development / Netscape Communications My words are my own, not my employer's. Got LDAP? From list@netscape.com Tue Jul 25 16:44:44 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00727 for ; Tue, 25 Jul 2000 16:44:44 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PKaKU26390; Tue, 25 Jul 2000 13:36:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PKfOM11194; Tue, 25 Jul 2000 13:41:24 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 13:41:24 -0700 (PDT) Message-Id: <4.3.2.7.0.20000725131714.00b191a0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jul 2000 13:41:17 -0700 To: mcs@netscape.com (Mark C Smith) From: "Kurt D. Zeilenga" Subject: regexMatch (Was: substring filters using DN attributes ?) Cc: ldapext In-Reply-To: <397DC1EE.3024C2AD@netscape.com> References: <"Your message of Fri, 21 Jul 2000 16:45:32 PDT." <3978E09C.969A15FE@software.com> <4.3.2.7.0.20000724114442.00afabf0@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"bWZ2YC.A.ouC.ztff5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 09:35 AM 7/25/00 -0700, Mark C Smith wrote: >"Kurt D. Zeilenga" wrote: >> >> I've meaning to publish a regexMatch rule I-D which would allow >> matching of an asserted regular expression against the string >> representation of attribute values. Of course, to be useful with >> DNs, we'd have to have to define a canonical string representation >> of DNs. Given such, you would be able to do DN matching like: >> >> (member:regexMatch:=.*,dc=example,dc=com$) >> >> Such a matching rule, I believe, would be generally useful in >> a number of applications. Of course, user applications may >> not want to expose regular expressions to average Joe. >> >> If others concur that this would be generally useful, I'll put >> up a straw man proposal after IETF#48. > >It would be interesting to see examples of the kinds of LDAP application >problems that would be more easily addressed if such a matching rule was >available. I agree. In fact, I wouldn't attempt to write such an I-D without decent examples. In general, such a rule would be useful to applications which required very specific, complex matching which cannot easily be decomposed into a substrings assertion. I'll try to come up with some examples, hopefully ones which are not too contrived. >If all we really need is a way to anchor the start and end >of strings (i.e., ^ and $ from regex), I'd rather see a more narrow >proposal. Why? Because general regular expression matching will be >quite difficult to support using indexes, etc. I concur that general regular expressions are quite difficult to to support using indexing. I also concur that applications wanting to make an assertion should use an appropriate matching rule. I fully agree that applications wanting to simply assert start/end text should use a substrings matching rules. Kurt From list@netscape.com Tue Jul 25 18:17:20 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26863 for ; Tue, 25 Jul 2000 18:17:19 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PM75R20080; Tue, 25 Jul 2000 15:07:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PMFqE26680; Tue, 25 Jul 2000 15:15:52 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 15:15:52 -0700 (PDT) Message-ID: <397E115E.70A2FEFD@netscape.com> Date: Tue, 25 Jul 2000 15:14:54 -0700 From: olga@netscape.com (Olga Natkovich) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mircea Pana CC: ietf-ldapext@netscape.com, "'mcs@netscape.com'" , lcup@netscape.com Subject: Re: Persistent Search References: <28560036253BD41191A10000F8BCBD11841BD1@zcard00g.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------6C76F1B02D2A920610C49FCD" Resent-Message-ID: <"TzQUmD.A.kgG.WGhf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --------------6C76F1B02D2A920610C49FCD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Mircea, Thank you for your comments. The lack of the discussion about the referrals in the LCUP draft was not intentional but an oversight. I will add a discussion on this to the next revision of the document. I think that, because the intent of the protocol is for the clients to contain exactly the same data as the servers, the protocol should act as though ManageDsaIT control is attached. We can require that clients attach the ManageDsaIT control to the search operation. Alternatively we can require that servers treat synchronization requests as though there is a ManageDsaIT control attached. Olga Mircea Pana wrote: > > > Mark, > > LCUP does not describe any specific behavior for continuation > references. The document only states that "the server returns a set of > SearchResultEntries that fits the client's specification.". No mention > of SearchResultReferences. > > Was this the intent of the authors? > > Assuming that for a search operation, the server would normally return > continuation references, what is supposed to happen when the same > search request contains a clientUpdate control that indicates the > client's intent to initiate a synchronization session? > > What is supposed to happen when the server acquires knowledge of a > subordinated naming context on a different server, while synchronizing > a client? What should happen in the opposite case: when knowledge of a > subordinates naming context is removed from the server? etc. > > Should the ManageDsaIT control be used when the client has interest in > the knowledge information and its evolution? ...quite limiting, this > sounds more like a work-around than a solution. > > Thanks, > Mircea. --------------6C76F1B02D2A920610C49FCD Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Mircea,

Thank you for your comments. The lack of the discussion about the referrals in the LCUP draft was not intentional but an oversight. I will add a discussion on this to the next revision of the document.

I think that, because the intent of the protocol is for the clients to contain exactly the same data as the servers, the protocol should act as though ManageDsaIT control is attached. We can require that clients attach the ManageDsaIT control to the search operation. Alternatively we can require that servers treat synchronization requests as though there is a ManageDsaIT control attached.

Olga
 

Mircea Pana wrote:

 

Mark,

LCUP does not describe any specific behavior for continuation references. The document only states that "the server returns a set of SearchResultEntries that fits the client's specification.". No mention of SearchResultReferences.

Was this the intent of the authors?

Assuming that for a search operation, the server would normally return continuation references, what is supposed to happen when the same search request contains a clientUpdate control that indicates the client's intent to initiate a synchronization session?

What is supposed to happen when the server acquires knowledge of a subordinated naming context on a different server, while synchronizing a client? What should happen in the opposite case: when knowledge of a subordinates naming context is removed from the server? etc.

Should the ManageDsaIT control be used when the client has interest in the knowledge information and its evolution? ...quite limiting, this sounds more like a work-around than a solution.

Thanks,
Mircea.

--------------6C76F1B02D2A920610C49FCD-- From list@netscape.com Tue Jul 25 18:28:18 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01279 for ; Tue, 25 Jul 2000 18:28:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6PMLiU14479; Tue, 25 Jul 2000 15:21:45 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6PMQmQ01417; Tue, 25 Jul 2000 15:26:48 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 15:26:48 -0700 (PDT) Date: Tue, 25 Jul 2000 15:26:37 -0700 (PDT) Message-Id: <200007252226.e6PMQbM06104@ywing.netscape.com> From: titanic2000@home.com To: YOU@netscape.com Subject: All Hands on Deck! Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"1uk5ZB.A.1V.nQhf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit It was a splendid ship! Everything a ship designer could imagine was built into it. It was beautiful, magnificent, TITANIC! Not only was it the biggest, it was sleek, fast.and absolutely unsinkable. Did not the designers guarantee it? Every proven safety feature and several new ones went into it's construction. It slid out of sea from Liverpool, England, on a serene April morning. Gleaming against the sky, it was majestic. The pride lf Britannia rode out to sea. New York was it's next harbor. The notables of society were it's passengers, and they basked in the splendor of it's luxury. Elegance was the word for Titanic's interior. Lavish in it's decor, menus, and entertainment, it surpassed the highest expectations of it's passengers.Three- quarters into it's maiden voyage, on the fringe of Newfoundland's frigid banks, the Titanic became a catastrophic nightmare. A deceptively large iceburg, detached from the polar ice fields, was drifting into the North Atlantic shipping lanes, destined to keep a predetermined encounter with the fabulous Titanic. Within two hours, before the dawn of April 15,1912, the unsinkable Titanic plunged to it's death, four miles beneath the icy surface taking it's 1500 passengers with it, and most of it's crew, and all it's treasure! Here's some awesome parallels:(1) " Not even God could sink the Titanic", was the designer's boast. We also have the deadly tendency to have excess pride in our resources. (2) Even when the Titanic struck the iceburg, the crew and passengers were confident that the "small iceburg could do little damage. We also are deceived into thinking that sin is minor, and of little importance. (3) This drama of the sea illustrates the uncertainty of life, and our need to be ready to stand before our Maker , and Judge! (4) It teaches us the lesson of obedient response. Those aboard the doomed Titanic who responded quickly, were saved! Those who flippantly ignored the warning, perished! My friend, what would your fate be in a similar situation? The Bible say's " Now is the day of salvation, behold now is the accepted time" it also ask's this question, " How shall we escape if we neglect so great salvation? Turn your heart to the Lord God of heaven and seek His forgiveness. Pray that He might save you from eternal damnation by giving you a heart that will trust the Lord Jesus Christ as your Savior, for there is NO OTHER WAY! The iceburg of eternity is fast approaching my friend, all hands on deck! From list@netscape.com Tue Jul 25 21:34:52 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23021 for ; Tue, 25 Jul 2000 21:34:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6Q1ONR17124; Tue, 25 Jul 2000 18:24:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6Q1XBs14288; Tue, 25 Jul 2000 18:33:11 -0700 (PDT) Resent-Date: Tue, 25 Jul 2000 18:33:11 -0700 (PDT) Subject: Commute from upstairs to downstairs! X-Accept-Language: en To: From: Date: Tue, 25 Jul 2000 18:35:42 MIME-Version: 1.0 Message-ID: Sensitivity: Personal Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.21 [en] (WinNT; A) Content-Type: text/plain References: 0F9371BA8 Resent-Message-ID: <"OFnONC.A.-eD.W_jf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Let's cut to the chase... I am a entreprenuer engaged in free enterprise. I am looking for positive, motivated people that want and need to increase their income by a minimum of 10k per month. Do you have a burning desire to change the quality of your existing life? Would you like to live the life that most others only dream about? How would you like to: A. Drastically reduce personal, business and capitol gains taxes? B. Protect all assets from any form of seizure, liens, or judgments? C. Create a six figure income every 4 months? How about: A. Restoring and preserving complete personal and financial privacy? B. Create and amass personal wealth, multiply it and protect it? C. Realize a 3 to 6 times greater returns on your money? D. Legally make yourself and your assets completely judgment-proof, seizure-proof, lien-proof, divorce-proof, attorney-proof, IRS-proof, and become completely insulated? If you answered yes to ANY of these questions we can help you... If you think this is too good to be true or are skeptical then this may not be for you... Many have been conditioned to believe it must be illegal, immoral or unethical to ever earn any real profits from their efforts. The fact is we have many people in our enterprise who earn over 50k per month from the privacy of their own home and are retiring in 2-3 years obviously wealthy and having total freedom both personal and financial. Are you a BIG thinker, BIG dreamer and a person that believes they deserve to have the best in life? Are you capable of recognizing that once in a lifetime opportunity when it's looking right at you? Countless others have missed their shot at the title only to look back years later and wished they should've because they could've. If you are serious about changing your life...and breaking the past chains of financial limitations... Call toll free 1-800-287-7755 (24 hr recorded 2 minute message) HIGH INTEGRITY! - NOT MLM! Best Regards --------------------------------------- This message is being sent to you in compliance with the proposed Federal legislation for commercial e-mail (S.1618 - SECTION 301). "Pursuant to Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this e-mail may be stopped at no cost to you by submitting a request to REMOVE --------------------------------------- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Obviously, a case of semigrammaticalness of a different sort necessitates that urgent consideration be applied to the postulated use of dialog management technology. Specifically, relational information is functionally equivalent and parallel to Krapp's Last Tape. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From list@netscape.com Wed Jul 26 03:12:54 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14814 for ; Wed, 26 Jul 2000 03:12:53 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6Q761j03572; Wed, 26 Jul 2000 00:06:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6Q7B5223289; Wed, 26 Jul 2000 00:11:05 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 00:11:05 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 26 Jul 2000 01:09:47 -0600 From: "Jim Sermersheim" To: , Subject: Re: Use of criticality in dupent-04 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e6Q7B2123191 Resent-Message-ID: <"kDQ5lC.A.ArF.H8of5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit I wouldn't mind removing this, but... 2251 is ambiguous in this area. If 2251 were to state that the criticality field is only valid and checked in requests, and ignored for responses, I'd feel more comfortable. Note also that there are a number of other drafts that have the same language (see SSS and VLV). Jim >>> "David Chadwick" 7/23/00 12:18:07 PM >>> Jim In your ID you mention the use of the criticality field in a control response. e.g criticality is FALSE (MAY be absent). In fact, RFC2251 says nothing about the use of the criticality field in a response. The functionality has been lifted from X.500(93) and criticality only has meaning in a request sent to a server. I suggest you remove the text about criticality in a response. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Wed Jul 26 03:15:09 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15326 for ; Wed, 26 Jul 2000 03:15:09 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6Q77Bj03845; Wed, 26 Jul 2000 00:07:12 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6Q7CFM24081; Wed, 26 Jul 2000 00:12:15 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 00:12:15 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 26 Jul 2000 01:11:47 -0600 From: "Jim Sermersheim" To: , Subject: Re: partial results in dupent-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e6Q7CE124057 Resent-Message-ID: <"GdpvBD.A._3F.O9of5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit Yes, I like PartialApplicationAllowed for what the flag actually means. >>> "David Chadwick" 7/23/00 12:21:15 PM >>> Jim, can I ask that the PartialResultsAllowed parameter be renamed to PartialApplicationAllowed or PartialControlAllowed or similar. This is because the term Partial Results has a special meaning i.e. a set of Search Results containing one or more referrals. On initial reading I wondered what referrals had to do with duplicate entries!! thanks David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Wed Jul 26 06:31:41 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29410 for ; Wed, 26 Jul 2000 06:31:41 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6QAP7j16477; Wed, 26 Jul 2000 03:25:07 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6QAUBE13307; Wed, 26 Jul 2000 03:30:11 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 03:30:11 -0700 (PDT) Sender: Robert.Byrne@france.Sun.COM Message-ID: <397EBD89.384C9448@france.sun.com> Date: Wed, 26 Jul 2000 12:29:29 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ldapext Subject: Re: regexMatch (Was: substring filters using DN attributes ?) References: <"Your message of Fri, 21 Jul 2000 16:45:32 PDT." <3978E09C.969A15FE@software.com> <4.3.2.7.0.20000724114442.00afabf0@infidel.boolean.net> <4.3.2.7.0.20000725131714.00b191a0@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"KhZs8C.A.nPD.w2rf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Kurt, Is there a standard definition of what a regular expression actually is ? I ask this because if you work on Solaris for example, there are n different libraries and functions for doing regular expression matching so the meaning of "regular expression" is not so obvious. Rob. "Kurt D. Zeilenga" wrote: > At 09:35 AM 7/25/00 -0700, Mark C Smith wrote: > >"Kurt D. Zeilenga" wrote: > >> > >> I've meaning to publish a regexMatch rule I-D which would allow > >> matching of an asserted regular expression against the string > >> representation of attribute values. Of course, to be useful with > >> DNs, we'd have to have to define a canonical string representation > >> of DNs. Given such, you would be able to do DN matching like: > >> > >> (member:regexMatch:=.*,dc=example,dc=com$) > >> > >> Such a matching rule, I believe, would be generally useful in > >> a number of applications. Of course, user applications may > >> not want to expose regular expressions to average Joe. > >> > >> If others concur that this would be generally useful, I'll put > >> up a straw man proposal after IETF#48. > > > >It would be interesting to see examples of the kinds of LDAP application > >problems that would be more easily addressed if such a matching rule was > >available. > > I agree. In fact, I wouldn't attempt to write such an I-D > without decent examples. In general, such a rule would be useful > to applications which required very specific, complex matching > which cannot easily be decomposed into a substrings assertion. > I'll try to come up with some examples, hopefully ones which > are not too contrived. > > >If all we really need is a way to anchor the start and end > >of strings (i.e., ^ and $ from regex), I'd rather see a more narrow > >proposal. Why? Because general regular expression matching will be > >quite difficult to support using indexes, etc. > > I concur that general regular expressions are quite difficult to > to support using indexing. I also concur that applications wanting > to make an assertion should use an appropriate matching rule. I > fully agree that applications wanting to simply assert start/end > text should use a substrings matching rules. > > Kurt From list@netscape.com Wed Jul 26 07:16:19 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09997 for ; Wed, 26 Jul 2000 07:16:19 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6QB5DR21786; Wed, 26 Jul 2000 04:05:13 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6QBE2w23132; Wed, 26 Jul 2000 04:14:02 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 04:14:02 -0700 (PDT) Date: Wed, 26 Jul 2000 04:13:56 -0700 (PDT) Message-Id: <200007261113.e6QBDsM07913@ywing.netscape.com> From: otn2001@yahoo.com To: ietf-ldapext@netscape.com Subject: LEARN HOW WE EARN UP TO 50% RETURN ON OUR ACCOUNT TRADING OPTIONS! -YUOK X-Reply-To: otn2001@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ITYeHD.A.KpF.4fsf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Dear ietf-ldapext, YOU CAN NOW EARN UP TO 10 TIMES MORE THAN IN THE BANK TRADING OPTIONS FROM HOME!!! Ask for your AMAZING FREE current daily OPTION TRADER'S NOTEBOOK newsletter, learn how we trade options PROFITABLY with LESS RISK. Relaxed, no intraday watching is necessary. BEST BUSINESS IN THE WORLD. We trade with a STATISTICAL ADVANTAGE, the only way to achieve long-term success. It is easy to follow along, we'll tell you what we do exactly. ASK NOW for your FREE Report and FREE Current Issue – simply email to otn2001@yahoo.com and put "OPTIONS [YOUR EMAIL ADDRESS]" in the subject line. You'll be on your way to consistent profits. Support provided. Phil Trader P.S. This is the most consistent money making opportunity ANYWHERE. Find out why. -------------------------------------------------------------------------- ------------------- This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, http://www.senate.gov/~murkowski/commercialemail/S771index.html Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address: otn2001@yahoo.com with the word "remove [your email address]" in the subject line. -------------------------------------------------------------------------------------- --------------------- From list@netscape.com Wed Jul 26 07:47:38 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17028 for ; Wed, 26 Jul 2000 07:47:00 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6QBaYR23690; Wed, 26 Jul 2000 04:36:34 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6QBjNg29864; Wed, 26 Jul 2000 04:45:23 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 04:45:23 -0700 (PDT) Message-Id: <3.0.3.32.20000726123709.007114d8@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 26 Jul 2000 12:37:09 +0100 To: Rob Byrne - Sun Microsystems , "Kurt D. Zeilenga" From: Chris Harding Subject: (a.josey 14931) Re: (c.harding 44333) Re: regexMatch (Was: substring filters using DN attributes ?) Cc: ldapext , a.josey@opengroup.org In-Reply-To: <397EBD89.384C9448@france.sun.com> References: <"Your message of Fri, 21 Jul 2000 16:45:32 PDT." <3978E09C.969A15FE@software.com> <4.3.2.7.0.20000724114442.00afabf0@infidel.boolean.net> <4.3.2.7.0.20000725131714.00b191a0@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Comments: (a.josey 14931) Resent-Message-ID: <"-RExwC.A.8RH.R9sf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com >Is there a standard definition of what a regular expression actually is ? > There certainly is. It is part of the standard definition of the UNIX(TM) operating system which is available (foc) from The Open Group, see http://www.opengroup.org/publications/catalog/t912.htm#medium2 The definition of regular expressions is at http://www.opengroup.org/onlinepubs/007908799/xbd/re.html >I ask this because if you work on Solaris for example, there are n different >libraries and functions for doing regular expression matching so the meaning >of "regular expression" is not so obvious. > >Rob. > >"Kurt D. Zeilenga" wrote: > >> At 09:35 AM 7/25/00 -0700, Mark C Smith wrote: >> >"Kurt D. Zeilenga" wrote: >> >> >> >> I've meaning to publish a regexMatch rule I-D which would allow >> >> matching of an asserted regular expression against the string >> >> representation of attribute values. Of course, to be useful with >> >> DNs, we'd have to have to define a canonical string representation >> >> of DNs. Given such, you would be able to do DN matching like: >> >> >> >> (member:regexMatch:=.*,dc=example,dc=com$) >> >> >> >> Such a matching rule, I believe, would be generally useful in >> >> a number of applications. Of course, user applications may >> >> not want to expose regular expressions to average Joe. >> >> >> >> If others concur that this would be generally useful, I'll put >> >> up a straw man proposal after IETF#48. >> > >> >It would be interesting to see examples of the kinds of LDAP application >> >problems that would be more easily addressed if such a matching rule was >> >available. >> >> I agree. In fact, I wouldn't attempt to write such an I-D >> without decent examples. In general, such a rule would be useful >> to applications which required very specific, complex matching >> which cannot easily be decomposed into a substrings assertion. >> I'll try to come up with some examples, hopefully ones which >> are not too contrived. >> >> >If all we really need is a way to anchor the start and end >> >of strings (i.e., ^ and $ from regex), I'd rather see a more narrow >> >proposal. Why? Because general regular expression matching will be >> >quite difficult to support using indexes, etc. >> >> I concur that general regular expressions are quite difficult to >> to support using indexing. I also concur that applications wanting >> to make an assertion should use an appropriate matching rule. I >> fully agree that applications wanting to simply assert start/end >> text should use a substrings matching rules. >> >> Kurt > > > Regards, Chris +++++ ======================================================================== Chris Harding T H E Directory Program Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Mobile: +44 771 8588820 ======================================================================== From list@netscape.com Wed Jul 26 11:24:02 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28828 for ; Wed, 26 Jul 2000 11:24:01 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6QFDgR10355; Wed, 26 Jul 2000 08:13:42 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6QFMVU26728; Wed, 26 Jul 2000 08:22:31 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 08:22:31 -0700 (PDT) X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Uppili Srinivasan'" Cc: , , Subject: RE: Some comments on model-04 Date: Thu, 27 Jul 2000 01:22:15 +1000 Message-ID: <000601bff715$48b41ac0$17448490@vic.bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <397B6AA7.820D1C7C@oracle.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Resent-Message-ID: <"hZ3iD.A.WhG.2Iwf5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Uppili, Fine. When you do review it, if you decide to permit (vertically) adjacent non-overlapping areas, please use a different term than "Naming Context" as this has a precisely standardized meaning defined in X.500. I would suggest "replication area" as already used in the protocol draft. Also, I suggest using the word "adjacent" (or non-adjacent), as in the ACL draft, and giving a precise definition of that word. "Contiguous" is commonly used, but I find it slightly confusing (eg see my even more confusing use of "convex" below ;-) PS I should now be able to complete the responses to Steve in the next couple of days, as I've just managed to not let a daughter depart for Japan with a non-functional laptop, thus avoiding the classic "cobbler's family with no shoes" syndrome, and can therefore do some LDUP work :-) Hope it's not too late for people already on their way to IETF meeting. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Uppili Srinivasan Sent: Monday, July 24, 2000 7:59 AM To: Albert.Langer@directory-designs.org Cc: d.w.chadwick@salford.ac.uk; ietf-ldup@imc.org; ietf-ldapext@netscape.com Subject: Re: Some comments on model-04 Albert: The "Naming context" definition in the context of replication was meant to avoid two replicas in the same DSA with over lapping or contiguous areas. It does allow multiple agreements associated with the same replica. You are right about some changes that were discussed around the definition of NC. The idea was to alter it as necessary so that the definition is consistent across replication, the ACL model (Ellen) and also for any future sub schema work (Mark Wahl). Let me try to make the necessary modification after some discussion at Pittsburgh with these authors. I would like to re-examine the ambiguities you have highlighted (regarding what is intentionally or unintentionally implied as requirements for read-only replicas) with a modified definition of NC. Thanks, Uppili. Albert Langer wrote: > Re point i), there may perhaps also be an unintentional limitation in the > possibilities for replication agreements by defining a "Replica" as "an > instance of a replicated Naming Context" (3.5, p9). Although "sparse" > replicas are currently out of scope by 3.3g this refers to the complexity of > implementing entry selection filters. It may not have been intended to rule > out vertically adjacent replicated areas held by the same DSA in connection > with different replication agreements that are themselves contiguous or > convex subtrees and not "sparse". The term "Naming Context" does exclude > that, as explained in 4.4 of David's book "Understanding X.500", at the URL > below. > > > I believe this point may have been raised earlier (by Dieter?), with some > mention of the architecture authors following up to correct it in the > archives. But it doesn't seem to have been corrected. > The only benefit of this limitation that I can see is to ensure that > modifyDN operations within an NC can always be performed at any updateable > replica. That strikes me as unnecessary since a referral could just be given > to a "full" replica that holds replication agreements for the entire NC when > a modifyDN is outside the replication areas held by a DSA. A category of > "full" replicas, each of which is updatable for every replicated area within > the NC could be defined. The "primary" for any replicated area within an NC > would then also be the primary for all other replicated areas within the NC > and would be one of the "full" replicas. Alternatively it would not be all > that difficult to add a slightly more complex calculation of who to send a > referral to, when not all updateable replicas that can process modifyDN are > "full". > > Even if this restriction was intentional, I can see no justification for > applying it to Read-Only replicas. Why shouldn't they hold vertically > adjacent replicated areas as well as disjoint ones? > eg Why shouldn't a branch office DSA serving a particular OU for an > organization hold read only copies of the top of an organization's tree as > well as read only copies for some, but not all, of the other OUs at the same > level, any of which might be vertically adjacent to the top area? Why > shouldn't another DSA at a different office interested in read only copies > of a different set of OUs also be able to do that? The present definition > requires that either the top be excluded so that disjoint NCs can be > defined, or that a single NC cover them all and every read only replica hold > the entire set. > > I suspect it may have been unintentional, as there is clearly some confusion > around about the concept of an NC. The definition on p9 refers to X.501 but > does not make it clear that any other NCs encountered down the tree from the > context prefix held by a DSA must be context prefixes held in a different > DSA. In draft-ietf-ldapext-acl-model-06.txt, there is even a reference to > "adjacent naming contexts supported by that directory server" at 3.3, p6 > despite the definition that NCs are disjoint, never adjacent within a DSA. > > I am CCing this to ldapext for that last point, despite still not being > subscribed. > > It isn't just a matter of terminology, but may relate to confusion about the > role of subschema and access control administration points and their > relations to distribution and replication. > > In general, attempting to define replication and access controls without > having first clarified distribution models and administrative models doesn't > seem to have been a good idea. > > Seeya, Albert > > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of David Chadwick > Sent: Saturday, July 22, 2000 2:46 AM > To: ietf-ldup@imc.org > Subject: Some comments on model-04 > > John & Co > > I have a few comments to make on the Model doc, most of them > minor > > i) you mention the term context prefix to refer to the root of a > naming context, but mostly use the term root. I would prefer that > you use context prefix consistently since a) this accords with X.518 > and b) it can keep the term root reserved for the root of the DIT > > ii) last sentence of 4.6.1. I would like some clarification of what this > actually means (A CSN is recorded.......). > > iii) I believe there is a conflict between 8.2 and 10.3 concerning > fractional replication. Either the fraction is sent only the attributes it > contains (8.2) or the whole modification operation is sent (10.3) but > not both. > > iv) section 12, steps 5 and 6 for DSA2. I believe there is a bug > here. In step 5 please state explicitly what the parent entry of the > rep agreement NC1R1-R2 is. I believe it should be NC1R1. In step > 6 state explicitly what the parent of rep agreement NC1R2-R1. I > believe it should be NC1R2. Hence the rep agreements are not > siblings, as they dont have the same parent. (otherwise I have > misunderstood the model and perhaps some more text somewhere > to clarify this) > > v) It is interesting that step 5 above said take a copy of the rep > agreement, whereas in section 14 it states that autentication > information should never be replicated between replicas. Perhaps > this statements are slightly at odds with each other. Also , if > password authentication is being employed, then the password will > need to be replicated between the DSAs, thus section 14 is wrong. > > David > > *************************************************** > > David Chadwick > IS Institute, University of Salford, Salford M5 4WT > Tel +44 161 295 5351 Fax +44 161 745 8169 > Mobile +44 790 167 0359 > Email D.W.Chadwick@salford.ac.uk > Home Page http://www.salford.ac.uk/its024/chadwick.htm > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string MLJ9-DU5T-HV8J > > *************************************************** From list@netscape.com Wed Jul 26 16:23:15 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08339 for ; Wed, 26 Jul 2000 16:23:14 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6QKGYj05860; Wed, 26 Jul 2000 13:16:35 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6QKHp627451; Wed, 26 Jul 2000 13:17:51 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 13:17:51 -0700 (PDT) Message-Id: <4.3.2.7.0.20000726122155.00afb7e0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2000 13:17:45 -0700 To: mcs@netscape.com (Mark C Smith) From: "Kurt D. Zeilenga" Subject: regexMatch examples Cc: ldapext In-Reply-To: <397DC1EE.3024C2AD@netscape.com> References: <"Your message of Fri, 21 Jul 2000 16:45:32 PDT." <3978E09C.969A15FE@software.com> <4.3.2.7.0.20000724114442.00afabf0@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"XB5CvD.A.qsG.td0f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Example A User wants to return all entries which contain uid values shorter than 5 characters. (uid:regexMatch:=^.{,5}$) Example B User wants to find all entries which contain name attributes with start or end with trailing white space or contain duplicate spaces. (name:regexMatch:=\28^[:space:]|[:space:]{2,}|[:space:]$\29) Note required escaping. Example C User wants to match all names which contain a common immediately after the first word (such as "Smith, John" but not "John Smith, Jr.". That is, match the the regex "^ *[^ ]*," or the filter: is (name:regexMatch:=^ \2a[^ ]\2a,). Example D User wants to match all values which start with A or B and end with C or D. That is: should match the regex ^(A|B).*(C|D)$ This should match as follows: # value match 1 A X false 2 A X C true 3 A X D true 4 B X false 5 B X C true 6 B X D true 7 X C false 8 X D false Now, lets say in within scope entries with attribute 'attr' each of which contains a subset of the following values and we want to return just those which contain a matching value, that is: (attr:regexMatch:=^\28A|B\29.\2a\28C|D\29$). This rather simple regex cannot be decomposed into a single substrings assertion, but could be decomposed into a complex filter: (|(attr=A*C)(attr=A*D)(attr=B*C)(attr=B*D)) Remarks: I do believe that most assertions made by Joe User can be (and should be) expressed without the need for extensible matching and, in particular, regexMatch. However, regular expressions offer immense amount of power which can be applied to any string value and, as demonstrated above, can be used to make assertions which are not supported by existing rules. Of course, as Mark pointed out, such power comes at a price. From list@netscape.com Wed Jul 26 20:08:37 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00226 for ; Wed, 26 Jul 2000 20:08:37 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6QNwMR03352; Wed, 26 Jul 2000 16:58:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6R07BY09295; Wed, 26 Jul 2000 17:07:11 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 17:07:11 -0700 (PDT) Date: Wed, 26 Jul 2000 19:05:06 -0500 From: Mark Wahl Subject: IETF LDAPEXT WG draft agenda Sender: wahl@austin.innosoft.com To: ietf-ldapext@netscape.com Cc: paf@swip.net Cc: ned.freed@innosoft.com Cc: agenda@ietf.org Reply-to: Mark Wahl Message-id: <10383.964656306@threadgill.austin.innosoft.com> Resent-Message-ID: <"H87p0.A.zOC.p03f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Here is the draft agenda for the LDAPEXT meeting. If you have any requests, please let me know! Thanks, Mark LDAP Extension Working Group (LDAPEXT) Monday, July 31, 2000 1300-1500 CHAIR: Mark Wahl AGENDA: 1. Introduction and Agenda Bashing LDUP, LDAPBIS, Bar BOFs meeting this week 2. Status of WG draft-ietf-ldapext-ldapv3-vlv-04.txt: Approved by IESG draft-ietf-ldapext-sorting-03.txt: Approved by IESG draft-ietf-ldapext-ldap-taxonomy-02.txt: Completed WG Last Call 3. Duplicate Entries [In WG Last Call] draft-ietf-ldapext-ldapv3-dupent-04.txt *UPDATED* 4. Java API [In WG Last Call] draft-ietf-ldapext-ldap-java-api-11.txt *UPDATED* draft-ietf-ldapext-ldap-java-api-asynch-ext-05.txt 5. Server discovery [In WG Last Call] draft-ietf-ldapext-locate-03.txt *UPDATED* 6. Access Control Model draft-ietf-ldapext-acl-model-06.txt *UPDATED* 7. Referral and knowledge reference maintenance draft-ietf-ldapext-refer-00.txt *NEW* 8. CLDAP draft-ietf-ldapext-cldap-00.txt *NEW* 9. Subentries draft-ietf-ldup-subentry-03.txt *UPDATED* 10. Charter review draft-ietf-ldapext-x509-sasl-03.txt draft-ietf-ldapext-ldap-c-api-04.txt draft-just-ldapv3-rescodes-02.txt *UPDATED* draft-hodges-ldapv3-as-00.txt *NEW* draft-rharrison-ldap-extpartresp-01.txt *UPDATED* draft-armijo-ldap-control-error-00.txt *NEW* draft-zeilenga-ldapv3bis-*.txt *NEW* draft-smith-ldapv3-*.txt *NEW* draft-wahl-ldapv3-*.txt *NEW* 11. Matched Values draft-ietf-ldapext-matchedval-02.txt *UPDATED* 12. Passwords draft-zeilenga-ldap-passwd-exop-04.txt *UPDATED* draft-zeilenga-ldap-authpasswd-03.txt *UPDATED* draft-behera-ldap-password-policy-02.txt *UPDATED* 13. LDAP Controls for Reply Signatures draft-salzr-ldap-repsig-00.txt *NEW* Mark Wahl, Directory Architect, Service Provider/Infrastructure Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Wed Jul 26 21:22:35 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10076 for ; Wed, 26 Jul 2000 21:22:34 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6R1BxR11352; Wed, 26 Jul 2000 18:11:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6R1Kn204823; Wed, 26 Jul 2000 18:20:49 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 18:20:49 -0700 (PDT) Message-ID: <397F8F69.2F78DE4@netscape.com> Date: Wed, 26 Jul 2000 18:24:57 -0700 From: rweltman@netscape.com (Rob Weltman) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: Mark Wahl CC: ietf-ldapext@netscape.com, paf@swip.net, ned.freed@innosoft.com, agenda@ietf.org Subject: Re: IETF LDAPEXT WG draft agenda References: <10383.964656306@threadgill.austin.innosoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"AzRcBC.A.FLB.v54f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Mark Wahl wrote: > > Here is the draft agenda for the LDAPEXT meeting. If you have any > requests, please let me know! Thanks, Mark > > LDAP Extension Working Group (LDAPEXT) > > Monday, July 31, 2000 1300-1500 > > CHAIR: Mark Wahl > > AGENDA: > > 1. Introduction and Agenda Bashing > LDUP, LDAPBIS, Bar BOFs meeting this week > > 2. Status of WG > draft-ietf-ldapext-ldapv3-vlv-04.txt: Approved by IESG > draft-ietf-ldapext-sorting-03.txt: Approved by IESG > draft-ietf-ldapext-ldap-taxonomy-02.txt: Completed WG Last Call > > 3. Duplicate Entries [In WG Last Call] > draft-ietf-ldapext-ldapv3-dupent-04.txt *UPDATED* > > 4. Java API [In WG Last Call] > draft-ietf-ldapext-ldap-java-api-11.txt *UPDATED* > draft-ietf-ldapext-ldap-java-api-asynch-ext-05.txt draft-ietf-ldapext-ldap-java-api-11.txt now includes the content of draft-ietf-ldapext-ldap-java-api-asynch-ext.txt (i.e. the former draft defines both the synchronous and the asynchronous APIs), so the latter is redundant. > > 5. Server discovery [In WG Last Call] > draft-ietf-ldapext-locate-03.txt *UPDATED* > > 6. Access Control Model > draft-ietf-ldapext-acl-model-06.txt *UPDATED* > > 7. Referral and knowledge reference maintenance > draft-ietf-ldapext-refer-00.txt *NEW* > > 8. CLDAP > draft-ietf-ldapext-cldap-00.txt *NEW* > > 9. Subentries > draft-ietf-ldup-subentry-03.txt *UPDATED* > > 10. Charter review > draft-ietf-ldapext-x509-sasl-03.txt > draft-ietf-ldapext-ldap-c-api-04.txt > draft-just-ldapv3-rescodes-02.txt *UPDATED* > draft-hodges-ldapv3-as-00.txt *NEW* > draft-rharrison-ldap-extpartresp-01.txt *UPDATED* > draft-armijo-ldap-control-error-00.txt *NEW* > draft-zeilenga-ldapv3bis-*.txt *NEW* > draft-smith-ldapv3-*.txt *NEW* > draft-wahl-ldapv3-*.txt *NEW* draft-weltman-ldapv3-proxy-04.txt draft-weltman-ldapv3-auth-response-01.txt Rob > > 11. Matched Values > draft-ietf-ldapext-matchedval-02.txt *UPDATED* > > 12. Passwords > draft-zeilenga-ldap-passwd-exop-04.txt *UPDATED* > draft-zeilenga-ldap-authpasswd-03.txt *UPDATED* > draft-behera-ldap-password-policy-02.txt *UPDATED* > > 13. LDAP Controls for Reply Signatures > draft-salzr-ldap-repsig-00.txt *NEW* > > Mark Wahl, Directory Architect, Service Provider/Infrastructure > Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Wed Jul 26 21:30:19 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11041 for ; Wed, 26 Jul 2000 21:30:19 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6R1Ncj21156; Wed, 26 Jul 2000 18:23:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6R1Si607760; Wed, 26 Jul 2000 18:28:44 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 18:28:44 -0700 (PDT) Message-Id: <4.3.2.7.0.20000726182725.00b042f0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2000 18:28:36 -0700 To: rweltman@netscape.com (Rob Weltman) From: "Kurt D. Zeilenga" Subject: Re: IETF LDAPEXT WG draft agenda Cc: Mark Wahl , ietf-ldapext@netscape.com, paf@swip.net, ned.freed@innosoft.com, agenda@ietf.org In-Reply-To: <397F8F69.2F78DE4@netscape.com> References: <10383.964656306@threadgill.austin.innosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"CPkA3C.A.-4B.KB5f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 06:24 PM 7/26/00 -0700, Rob Weltman wrote: >> 4. Java API [In WG Last Call] >> draft-ietf-ldapext-ldap-java-api-11.txt *UPDATED* >> draft-ietf-ldapext-ldap-java-api-asynch-ext-05.txt > > draft-ietf-ldapext-ldap-java-api-11.txt now includes the content of draft-ietf-ldapext-ldap-java-api-asynch-ext.txt (i.e. the former draft defines both the synchronous and the asynchronous APIs), so the latter is redundant. And I don't recall a WG last call being issued regarding this revised work. From list@netscape.com Wed Jul 26 21:43:09 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15711 for ; Wed, 26 Jul 2000 21:43:09 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6R1WmR14042; Wed, 26 Jul 2000 18:32:48 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6R1fco12755; Wed, 26 Jul 2000 18:41:38 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 18:41:38 -0700 (PDT) Date: Wed, 26 Jul 2000 20:39:36 -0500 From: Mark Wahl Subject: Re: IETF LDAPEXT WG draft agenda In-reply-to: "Your message of Wed, 26 Jul 2000 18:28:36 PDT." <4.3.2.7.0.20000726182725.00b042f0@infidel.boolean.net> Sender: wahl@austin.innosoft.com To: "Kurt D. Zeilenga" Cc: rweltman@netscape.com (Rob Weltman), ietf-ldapext@netscape.com Message-id: <11551.964661976@threadgill.austin.innosoft.com> Resent-Message-ID: <"MBna9C.A.fFD.ON5f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com The update for issues found during the WG last call was received by the I-D editor just before the deadline. We try to avoid having WG last calls started that would overlap with the run-up week for IETF. Therefore the WG last call on revised drafts are announced at or immediately following the LDAPEXT meeting. Mark Wahl, Directory Architect, Service Provider/Infrastructure Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Wed Jul 26 22:06:57 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20808 for ; Wed, 26 Jul 2000 22:06:57 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6R1uiR16515; Wed, 26 Jul 2000 18:56:44 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6R25Yw20617; Wed, 26 Jul 2000 19:05:34 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 19:05:34 -0700 (PDT) Message-Id: <4.3.2.7.0.20000726182853.00aefa10@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2000 19:05:27 -0700 To: Mark Wahl From: "Kurt D. Zeilenga" Subject: Re: IETF LDAPEXT WG draft agenda Cc: ietf-ldapext@netscape.com In-Reply-To: <10383.964656306@threadgill.austin.innosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"V1VoV.A.1BF.tj5f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I'd like to discuss these new drafts: draft-zeilenga-ldap-namedref-00.txt draft-zeilenga-ldap-grouping-00.txt The former is relevant to existing charter work and likely should be discussed with 7. The latter is new, but likely of interest to the WG. To make room, I would recommend dropping discussion on passwd-exop (which was previously discussed and currently submitted to our AD) and authPassword (which was previously discussed and not yet ready for submission). Maybe just a status update would be appropriate. I also have submitted a one other I-Ds which are not being covered under either LDAPext or LDAPbis... but likely not of significant impact upon the community to warrant bumping of other discussions. draft-zeilenga-ldap-root-00.txt (Experimental) Regards, Kurt At 07:05 PM 7/26/00 -0500, Mark Wahl wrote: >Here is the draft agenda for the LDAPEXT meeting. If you have any >requests, please let me know! Thanks, Mark > > >LDAP Extension Working Group (LDAPEXT) > >Monday, July 31, 2000 1300-1500 > >CHAIR: Mark Wahl > >AGENDA: > >1. Introduction and Agenda Bashing > LDUP, LDAPBIS, Bar BOFs meeting this week > >2. Status of WG > draft-ietf-ldapext-ldapv3-vlv-04.txt: Approved by IESG > draft-ietf-ldapext-sorting-03.txt: Approved by IESG > draft-ietf-ldapext-ldap-taxonomy-02.txt: Completed WG Last Call > >3. Duplicate Entries [In WG Last Call] > draft-ietf-ldapext-ldapv3-dupent-04.txt *UPDATED* > >4. Java API [In WG Last Call] > draft-ietf-ldapext-ldap-java-api-11.txt *UPDATED* > draft-ietf-ldapext-ldap-java-api-asynch-ext-05.txt > >5. Server discovery [In WG Last Call] > draft-ietf-ldapext-locate-03.txt *UPDATED* > >6. Access Control Model > draft-ietf-ldapext-acl-model-06.txt *UPDATED* > >7. Referral and knowledge reference maintenance > draft-ietf-ldapext-refer-00.txt *NEW* > >8. CLDAP > draft-ietf-ldapext-cldap-00.txt *NEW* > >9. Subentries > draft-ietf-ldup-subentry-03.txt *UPDATED* > >10. Charter review > draft-ietf-ldapext-x509-sasl-03.txt > draft-ietf-ldapext-ldap-c-api-04.txt > draft-just-ldapv3-rescodes-02.txt *UPDATED* > draft-hodges-ldapv3-as-00.txt *NEW* > draft-rharrison-ldap-extpartresp-01.txt *UPDATED* > draft-armijo-ldap-control-error-00.txt *NEW* > draft-zeilenga-ldapv3bis-*.txt *NEW* > draft-smith-ldapv3-*.txt *NEW* > draft-wahl-ldapv3-*.txt *NEW* > >11. Matched Values > draft-ietf-ldapext-matchedval-02.txt *UPDATED* > >12. Passwords > draft-zeilenga-ldap-passwd-exop-04.txt *UPDATED* > draft-zeilenga-ldap-authpasswd-03.txt *UPDATED* > draft-behera-ldap-password-policy-02.txt *UPDATED* > >13. LDAP Controls for Reply Signatures > draft-salzr-ldap-repsig-00.txt *NEW* > > >Mark Wahl, Directory Architect, Service Provider/Infrastructure >Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Wed Jul 26 22:45:41 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26909 for ; Wed, 26 Jul 2000 22:45:36 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6R2Z4R19820; Wed, 26 Jul 2000 19:35:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6R2hsw02399; Wed, 26 Jul 2000 19:43:54 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 19:43:54 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C83E7E7@aspams01.cai.com> From: "Ramsay, Ron" To: Chris Harding Cc: ldapext Subject: RE: (a.josey 14931) Re: (c.harding 44333) Re: regexMatch (Was: su bstring filters using DN attributes ?) Date: Thu, 27 Jul 2000 12:44:04 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"V4VDBB.A.Nl.pH6f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Chris, Interesting. On reading re.html below I found no less than three 'standards' in the first paragraph. Mention of locales later completed the picture for me. I guess in the conformance statement for the directory we say which RE 'standard' we are following. We also need an attribute inb the root DSE which specifies what our locale is. Ron. -----Original Message----- From: Chris Harding [mailto:c.harding@opengroup.org] Sent: Wednesday, 26 July 2000 21:37 To: Rob Byrne - Sun Microsystems; Kurt D. Zeilenga Cc: ldapext; a.josey@opengroup.org Subject: (a.josey 14931) Re: (c.harding 44333) Re: regexMatch (Was: substring filters using DN attributes ?) >Is there a standard definition of what a regular expression actually is ? > There certainly is. It is part of the standard definition of the UNIX(TM) operating system which is available (foc) from The Open Group, see http://www.opengroup.org/publications/catalog/t912.htm#medium2 The definition of regular expressions is at http://www.opengroup.org/onlinepubs/007908799/xbd/re.html >I ask this because if you work on Solaris for example, there are n different >libraries and functions for doing regular expression matching so the meaning >of "regular expression" is not so obvious. > >Rob. > >"Kurt D. Zeilenga" wrote: > >> At 09:35 AM 7/25/00 -0700, Mark C Smith wrote: >> >"Kurt D. Zeilenga" wrote: >> >> >> >> I've meaning to publish a regexMatch rule I-D which would allow >> >> matching of an asserted regular expression against the string >> >> representation of attribute values. Of course, to be useful with >> >> DNs, we'd have to have to define a canonical string representation >> >> of DNs. Given such, you would be able to do DN matching like: >> >> >> >> (member:regexMatch:=.*,dc=example,dc=com$) >> >> >> >> Such a matching rule, I believe, would be generally useful in >> >> a number of applications. Of course, user applications may >> >> not want to expose regular expressions to average Joe. >> >> >> >> If others concur that this would be generally useful, I'll put >> >> up a straw man proposal after IETF#48. >> > >> >It would be interesting to see examples of the kinds of LDAP application >> >problems that would be more easily addressed if such a matching rule was >> >available. >> >> I agree. In fact, I wouldn't attempt to write such an I-D >> without decent examples. In general, such a rule would be useful >> to applications which required very specific, complex matching >> which cannot easily be decomposed into a substrings assertion. >> I'll try to come up with some examples, hopefully ones which >> are not too contrived. >> >> >If all we really need is a way to anchor the start and end >> >of strings (i.e., ^ and $ from regex), I'd rather see a more narrow >> >proposal. Why? Because general regular expression matching will be >> >quite difficult to support using indexes, etc. >> >> I concur that general regular expressions are quite difficult to >> to support using indexing. I also concur that applications wanting >> to make an assertion should use an appropriate matching rule. I >> fully agree that applications wanting to simply assert start/end >> text should use a substrings matching rules. >> >> Kurt > > > Regards, Chris +++++ ======================================================================== Chris Harding T H E Directory Program Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Mobile: +44 771 8588820 ======================================================================== From list@netscape.com Thu Jul 27 01:12:17 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24643 for ; Thu, 27 Jul 2000 01:12:16 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6R51sR28368; Wed, 26 Jul 2000 22:01:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6R5Aj206765; Wed, 26 Jul 2000 22:10:45 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 22:10:45 -0700 (PDT) From: ReduceDebt@2von.fsnet.co.uk Message-Id: <200007270507.CAA25437@marlin.com.br> Date: Wed, 26 Jul 00 23:54:27 EST To: ReduceDebt@2von.fsnet.co.uk Subject: FREE! Confidential Debt Reduction Analysis Resent-Message-ID: <"RY_ctD.A.SpB.TR8f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Sign-up for a Completely FREE, Confidential Debt Reduction Analysis. ***Limited Time FREE Offer.*** http://216.141.227.67/members/debt/debts.html Our Non-Profit Organization can do the following JUST BY ASKING YOUR CREDITORS: (*)Cut your bills in half. (*)Consolidate your bills into ONE LOW monthly payment. (*)Eliminate interest and late fee charges. (*)Improve your credit rating. (*)NO Need To Own Any Property A trained professional negotiates with your creditors to: 1)Lower your monthly debt payments by 40-60% 2)End creditor harassment 3)Save thousands of dollars in interest and late charges 4)Start improving your credit rating. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ If you have received this message in error and would like to be removed from future mailings, please reply with the word remove in the subject. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From list@netscape.com Thu Jul 27 01:12:47 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24928 for ; Thu, 27 Jul 2000 01:12:46 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6R56Bj07266; Wed, 26 Jul 2000 22:06:11 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6R5BGo07391; Wed, 26 Jul 2000 22:11:16 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 22:11:16 -0700 (PDT) Message-Id: <4.3.2.7.0.20000726203719.00b26750@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2000 22:10:56 -0700 To: rweltman@netscape.com From: "Kurt D. Zeilenga" Subject: proxy comments Cc: ietf-ldapext@netscape.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"3p8b8C.A.9xB.wR8f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Rob, a few comments: First, I like to note that one of the intended application of my grouping I-D is proxing. We should discuss the pros and cons of this approach... likely best over a beer. Abstract: "The Proxied Authorization Control allows a connection with sufficient privileges to assume the identity of another entry for the duration of an LDAP request." "duration of an LDAP request" ? duration is a poor choice of words as it implies the control may affect unrelated operations. "of another entry" ? this assumes that the identity refers to an entry. An authorization identity does have to refer to an entry (let alone be a DN). 2. Publishing support for the Proxied Authorization Control s/supportedExtensions/supportedControl/ 3. Proxied Authorization Control This control may be included in any bind, unbind, search, compare, abandon, modify, delete, or modrdn request message as part of the controls field of the LDAPMessage, as defined in [1]. This control should be disallowed on bind as the session is returned to anonymous upon receipt of request and anonymous should not be allowed to assert an authorization identity for the control. Also, the control should have no impact upon the session as a whole and hence should be disallowed on any operation which has direct impact upon the session. If provided with bind and marked critical, unsupportedCriticalExtension should be returned. The control, IMO, should be inappropriate to provided with abandon and unbind. The control should be allowed with extended operations, excepting those which affect the session as a whole (such as startTLS). The syntax of controlType should be LDAPOID and it should have the value of the OID. I suggest you make specific mention that servers recognizing this control MUST return an error if the control is not marked as being critical. The controlValue contains the BER encoding of a DN used for evaluating the requested rights: Suggest (needs work): The control value is a BER encoded proxyAuthValue which contains the DN representing the authorization identity who's rights are requests. Note again authorized DN vs authzId issue. 4. Permission to execute as proxy "This means that fewer results, or no results, may be returned" I assume you meant fewer entry and references responses, not results. That is, the search should still have one result response. 5. Security Considerations A more detailed security analysis may be appropriate. From list@netscape.com Thu Jul 27 02:18:21 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04022 for ; Thu, 27 Jul 2000 02:18:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6R67nR02332; Wed, 26 Jul 2000 23:07:49 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6R6GcQ20029; Wed, 26 Jul 2000 23:16:38 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 23:16:38 -0700 (PDT) X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Christopher Apple'" , , Cc: , Subject: RE: LDUP Working Group Agenda - Summary of objections to requirements draft Date: Thu, 27 Jul 2000 16:16:21 +1000 Message-ID: <000201bff792$2f8e3d00$17448490@vic.bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Resent-Message-ID: <"LvEU-.A.r4E.FP9f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit [Chris] I. WG Deliverables Review "LDAP Replication Requirements" http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-03.txt Editor(s): Russ Weiser, Ellen Stokes [...] III. Discussion of LDUP Requirements Document [Albert] I am also sending this to LDAPEXT as the direction taken by LDUP could have major consequences for LDAPEXT (eg the current proposals for ACL simply will not replicate correctly and future support for transactions will be difficult if not impossible). Above link shows: *** This Internet-Draft has expired and is no longer available. Unrevised documents placed in the Internet-Drafts directories have a maximum life of six months. After that time, they must be updated, or they will be deleted. This document was deleted on July 17, 2000. *** A copy of the "final" version, which expired on 21 April 2000, is in the LDUP email archive at: http://www.imc.org/ietf-ldup/mail-archive/msg00471.html Despite assurances from at least one person who should know, I remain quite convinced that members of the LDUP WG have NOT read it carefully. It is especially unlikely that anybody else has read it recently, since it expired two months ago and has now been deleted. In view of agenda item III, I strongly urge that you do read it again, carefully. As I cannot attend the discussion, I have included a summary of my formal objection to it below. SUMMARY OF OBJECTIONS TO REQUIREMENTS DRAFT The three key points are: 1) There is no requirement for convergence or "eventual consistency". This looks like just poor expression, but in fact the LDUP architecture and Update Reconciliation Procedures do specify proposed standards that guarantee long term divergence by relying on timestamps and allowing DSAs to transmit changes out of order and drop changes when clocks are out of sync. This is easily fixed, once a requirement to fix it is agreed on. Details on how to fix it based on the Coda replication protocols also adopted by Active Directory, and a semi-formal proof that the fix would be robust in the face of DSAs crashing and being restored from backups, network partitioning etc etc, is included in my draft below. That fix is also consistent with the rest of the current architecture and URP and would not require major re-work of existing drafts. 2) There is no requirement for atomic operations. Again this is obscured by poor expression and nonsensical definitions, but in fact the architecture and URP drafts merge changes to individual attribute values made concurrently at different replicas. The fact that this obviously breaks the ACL standards being developed in LDUP, despite an overlap in authorship between the two documents, strongly confirms that the consequences for existing applications are simply not understand and should be studied through a requirements analysis by actively explaining the implications and soliciting input from other areas (operations etc) that may be affected. Fixing this would require substantial changes to the current architecture and URP. I have sketched one possible way to do so in the draft below. 3) There is no requirement to support mandatory operational attributes of LDAP. The operational attribute "modifiersName" cannot be supported meaningfully as nobody in particular can be said to be responsible for a change that has in fact been merged from two or more concurrent changes made independently and without knowledge of each other. This severely complicates system administration as the first thing anybody would want to know after receiving a problem report is "who changed what". I believe that point 1) would be taken for granted by anybody thinking about LDUP requirements. Until somebody presents an argument against convergence or "eventual consistency" I see no point in even trying to present an argument for it. The current approach is simply absurd. Point 3) is also pretty obvious and is just one of many consequences of point 2. On point 2, there are plausible arguments (which I disagree with) for breaking the current LDAP/X.500 data model. If the WG does intend to do that, it has an obligation to clearly explain its intentions in a requirements draft and actively solicit input. I cannot express the argument against doing so more clearly than has already been done, long ago, without adequate response, in the following comments "Re: LDUP warmup exercise: atomicity in LDAPv3", from Tim Howes (16 December 1998): *** "Each LDAP operation (add, modify, delete, moddn) as a whole is atomic. The whole operation either happens or it doesn't. Changes cannot be half-applied to any single LDAP server. The replication consistency model must assume and build on this basic fact to define how multiple LDAP replicas converge to the same state over time, in the absence of additional changes. This kind of loose consistency model is pretty fundamental to the notion of a directory. My two cents on what's important in a replication consistency model are that it must be 1) predictable, and that it should 2) make some kind of sense to people using the system. All this talk of consistency at different levels (e.g., between applications using the directory at the same time) is a red herring. Our job is to define a consistency model for the directory itself. Some applications may find this model sufficient for their needs. Others may have to build more elaborate models on top. But let's start with the basics. -- Tim" http://www.imc.org/ietf-ldup/mail-archive/msg00214.html *** In my view, both an explicit requirement for atomic operations and a requirement that the results be 1) predictable and 2) make some kind of sense to users, should be in the final requirements draft. The consistency model of URP, was summarized in Alison's "Contribution to Profiles Document (Consistency Discussion)": http://www.imc.org/ietf-ldup/mail-archive/msg00548.html The attached Word version, with more easily read tables, is: http://www.imc.org/ietf-ldup/mail-archive/doc00000.doc In my view it is: 1) Unpredictable. See the explanation of "Extraordinary States" and "Transient Extraordinary States" above. 2) Preposterously complex. See the extensive use of procedural pseudo code for a protocol that simply defies plain description, in the URP draft: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.txt In reviewing the LDUP archives I noted that a number of people had expressed various reservations, especially concerning the consistency model for replication, but subsequently ceased active participation. Hopefully some of them may still be involved in LDAP-EXT and could therefore see this and decide to take part in the discussion. See also my individual submission to LDUP: http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt and my response to the WG chair's request for status reports, which contains links to all relevant discussion of that objection prior to the document expiring: http://www.imc.org/ietf-ldup/mail-archive/msg00561.html Subsequent discussion can be seen by following from the thread of that message in the archive. From list@netscape.com Thu Jul 27 02:35:30 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09499 for ; Thu, 27 Jul 2000 02:35:25 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6R6PCR03497; Wed, 26 Jul 2000 23:25:12 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6R6Y2Q23494; Wed, 26 Jul 2000 23:34:02 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 23:34:02 -0700 (PDT) Message-Id: <4.3.2.7.0.20000726233331.00b35520@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2000 23:33:57 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: auth-response comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"hK8TsC.A.0uF.Yf9f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Rob/Mark, Here are some comments, some new, some old... all provided to ensure completeness. First, please note my general aversion to unsolicited controls. IMO, controls should only be sent to clients which are known to be able to make use of the information. 2. Publishing support for the Authentication Response Control s/supportedExtensions/supportedControl/ 3. Authentication Response >The criticality field is not used. I would suggest "The criticality of this control SHALL be FALSE. Servers SHOULD not provide the criticality field." Not also that the controlType is determined, its the value of the field which is TBD. You do not specify how AuthResponseValue is to be encoded. I do not see the need for authMechanism? The client knows the method and, if applicable, the SASL mechanism used. However, what might be useful is source of credential used to in to complete a SASL/EXTERNAL authentication. I note you specify the return of a DN and not an authzID. You assume that if an userzID is provided (or implied) by the client that it must be mapped to a DN and if a DN is provided (or implied) that it is not mapped to a userzID. JeffH has made arguments that authzId should be the general form of LDAP authorization information. In fact, LDAP ACM allows authzID as subjects. You likely should consider changing authDN to authzID. 4. Security Considerations Please make specific mention that the control is not protected by SASL integrity and privacy services negotiated by the bind operation it is provided with. Due to this, I suggest use of a separate (extended) operation instead of a bind control to request/return this information. Kurt From list@netscape.com Thu Jul 27 03:00:03 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17281 for ; Thu, 27 Jul 2000 03:00:02 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6R6qfj14192; Wed, 26 Jul 2000 23:52:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6R6vkI28569; Wed, 26 Jul 2000 23:57:46 -0700 (PDT) Resent-Date: Wed, 26 Jul 2000 23:57:46 -0700 (PDT) Sender: Robert.Byrne@france.Sun.COM Message-ID: <397FDD39.5033AAD4@france.sun.com> Date: Thu, 27 Jul 2000 08:56:57 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com Subject: Re: regexMatch examples References: <"Your message of Fri, 21 Jul 2000 16:45:32 PDT." <3978E09C.969A15FE@software.com> <4.3.2.7.0.20000724114442.00afabf0@infidel.boolean.net> <4.3.2.7.0.20000726122155.00afb7e0@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"cRDWOC.A.H-G.p19f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Kurt, For regex on a dn, here's an example to say "match any value of a particular RDN attribute". eg. match each dn like "cn=admin,ou=X,o=sun.com" where the X will match any, though just, the value of ou (which in particular may contain an escaped comma). A Unix extended regular expression for this matching is "^uid=admin,ou=\([^,]*\\,\)*[^,]*,o=sun.com$" Rob. "Kurt D. Zeilenga" wrote: > Example A > > User wants to return all entries which contain > uid values shorter than 5 characters. > > (uid:regexMatch:=^.{,5}$) > > Example B > > User wants to find all entries which contain name > attributes with start or end with trailing white > space or contain duplicate spaces. > (name:regexMatch:=\28^[:space:]|[:space:]{2,}|[:space:]$\29) > > Note required escaping. > > Example C > > User wants to match all names which contain > a common immediately after the first word (such as > "Smith, John" but not "John Smith, Jr.". That is, > match the the regex "^ *[^ ]*," or the filter: > is (name:regexMatch:=^ \2a[^ ]\2a,). > > Example D > > User wants to match all values which start with A or B > and end with C or D. That is: should match the regex > ^(A|B).*(C|D)$ > > This should match as follows: > # value match > 1 A X false > 2 A X C true > 3 A X D true > 4 B X false > 5 B X C true > 6 B X D true > 7 X C false > 8 X D false > > Now, lets say in within scope entries with attribute 'attr' > each of which contains a subset of the following values > and we want to return just those which contain a matching > value, that is: (attr:regexMatch:=^\28A|B\29.\2a\28C|D\29$). > > This rather simple regex cannot be decomposed into a single > substrings assertion, but could be decomposed into a complex > filter: > (|(attr=A*C)(attr=A*D)(attr=B*C)(attr=B*D)) > > Remarks: > > I do believe that most assertions made by Joe User can be > (and should be) expressed without the need for extensible > matching and, in particular, regexMatch. However, regular > expressions offer immense amount of power which can be applied > to any string value and, as demonstrated above, can be used > to make assertions which are not supported by existing > rules. Of course, as Mark pointed out, such power comes at > a price. From list@netscape.com Thu Jul 27 04:35:35 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17841 for ; Thu, 27 Jul 2000 04:35:34 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6R8NZR11086; Thu, 27 Jul 2000 01:23:35 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6R8WPA24483; Thu, 27 Jul 2000 01:32:25 -0700 (PDT) Resent-Date: Thu, 27 Jul 2000 01:32:25 -0700 (PDT) Message-Id: <3.0.3.32.20000727092308.0070dd20@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 27 Jul 2000 09:23:08 +0100 To: "Ramsay, Ron" From: Chris Harding Subject: Re: (c.harding 44382) RE: (a.josey 14931) Re: (c.harding 44333) Re: regexMatch (Was: substring filters using DN attributes ?) Cc: ldapext In-Reply-To: <11981F9F5649D411BC92009027D0D18C83E7E7@aspams01.cai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"lvKZT.A.R-F.XO_f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hi, Ron - There are several variants on the definition of regular expression, for historical reasons. There is one UNIX(TM) standard, though, which says that all of the versions must be supported by a UNIX system, each being applied in the appropriate contexts as defined by the standard. Internationalization is a very tricky - but extremely important - area. The standards (even the UNIX ones) should not be followed blindly, you need to look carefuly at what implications they would have before referencing them in a matching rule RFC or draft. When dealing with multiple character sets and languages, collating sequences and regular expressions clearly become more difficult. A great deal of very good work went into the definition of internationalized regular expressions. However, that work pre-dates the deployment of UNICODE, which removes some but by no means all of the problems. So far as I know, it has not been re-evaluated in the light of UNICODE, but it certainly should be. Should there be locale attributes and if so where they should go? People must be able to put entries using different languages and character sets in the same directory. This is in fact supported by LDAP language tagging (RFC 2596), and the first question has to be whether any mechanism beyond RFC 2596 is needed. For the sake of simplicity, I would hope not. >Chris, > >Interesting. On reading re.html below I found no less than three 'standards' >in the first paragraph. Mention of locales later completed the picture for >me. > >I guess in the conformance statement for the directory we say which RE >'standard' we are following. We also need an attribute inb the root DSE >which specifies what our locale is. > >Ron. > >-----Original Message----- >From: Chris Harding [mailto:c.harding@opengroup.org] >Sent: Wednesday, 26 July 2000 21:37 >To: Rob Byrne - Sun Microsystems; Kurt D. Zeilenga >Cc: ldapext; a.josey@opengroup.org >Subject: (a.josey 14931) Re: (c.harding 44333) Re: regexMatch (Was: >substring filters using DN attributes ?) > > >>Is there a standard definition of what a regular expression actually is ? >> >There certainly is. > >It is part of the standard definition of the UNIX(TM) operating system >which is available (foc) from The Open Group, see >http://www.opengroup.org/publications/catalog/t912.htm#medium2 > >The definition of regular expressions is at >http://www.opengroup.org/onlinepubs/007908799/xbd/re.html > >>I ask this because if you work on Solaris for example, there are n >different >>libraries and functions for doing regular expression matching so the >meaning >>of "regular expression" is not so obvious. >> >>Rob. >> >>"Kurt D. Zeilenga" wrote: >> >>> At 09:35 AM 7/25/00 -0700, Mark C Smith wrote: >>> >"Kurt D. Zeilenga" wrote: >>> >> >>> >> I've meaning to publish a regexMatch rule I-D which would allow >>> >> matching of an asserted regular expression against the string >>> >> representation of attribute values. Of course, to be useful with >>> >> DNs, we'd have to have to define a canonical string representation >>> >> of DNs. Given such, you would be able to do DN matching like: >>> >> >>> >> (member:regexMatch:=.*,dc=example,dc=com$) >>> >> >>> >> Such a matching rule, I believe, would be generally useful in >>> >> a number of applications. Of course, user applications may >>> >> not want to expose regular expressions to average Joe. >>> >> >>> >> If others concur that this would be generally useful, I'll put >>> >> up a straw man proposal after IETF#48. >>> > >>> >It would be interesting to see examples of the kinds of LDAP application >>> >problems that would be more easily addressed if such a matching rule was >>> >available. >>> >>> I agree. In fact, I wouldn't attempt to write such an I-D >>> without decent examples. In general, such a rule would be useful >>> to applications which required very specific, complex matching >>> which cannot easily be decomposed into a substrings assertion. >>> I'll try to come up with some examples, hopefully ones which >>> are not too contrived. >>> >>> >If all we really need is a way to anchor the start and end >>> >of strings (i.e., ^ and $ from regex), I'd rather see a more narrow >>> >proposal. Why? Because general regular expression matching will be >>> >quite difficult to support using indexes, etc. >>> >>> I concur that general regular expressions are quite difficult to >>> to support using indexing. I also concur that applications wanting >>> to make an assertion should use an appropriate matching rule. I >>> fully agree that applications wanting to simply assert start/end >>> text should use a substrings matching rules. >>> >>> Kurt >> >> >> > >Regards, > >Chris >+++++ > >======================================================================== > Chris Harding > T H E Directory Program Manager > O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 > WWW: http://www.opengroup.org Mobile: +44 771 8588820 >======================================================================== > > Regards, Chris +++++ ======================================================================== Chris Harding T H E Directory Program Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Mobile: +44 771 8588820 ======================================================================== From list@netscape.com Thu Jul 27 04:49:20 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22204 for ; Thu, 27 Jul 2000 04:49:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6R8gkj22533; Thu, 27 Jul 2000 01:42:46 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6R8lqA27629; Thu, 27 Jul 2000 01:47:52 -0700 (PDT) Resent-Date: Thu, 27 Jul 2000 01:47:52 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C867FA5@aspams01.cai.com> From: "Ramsay, Ron" To: Chris Harding Cc: ldapext Subject: RE: (c.harding 44382) RE: (a.josey 14931) Re: (c.harding 44333) R e: regexMatch (Was: substring filters using DN attributes ?) Date: Thu, 27 Jul 2000 18:47:28 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"1_8PzB.A.bvG.3c_f5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Thank you, Chris. Actually, I was trying to say that I thought that this might be more than a server would wish to do. I think you are saying (are you?) that, where an attribute is marked with a language tag, the RE should be applied in a locale appropriate to *that* language. This implies that filter processing is attribute ;option dependent? Another problem I see is that re.html defines the syntax but not the semantics of REs. How an RE is constructed is committed to BNF, but how it is interpreted is ambiguous. I mention the handling of ^ in subexpressions and the meaning (not) given to "**". Ron. -----Original Message----- From: Chris Harding [mailto:c.harding@opengroup.org] Sent: Thursday, 27 July 2000 18:23 To: Ramsay, Ron Cc: ldapext Subject: Re: (c.harding 44382) RE: (a.josey 14931) Re: (c.harding 44333) Re: regexMatch (Was: substring filters using DN attributes ?) Hi, Ron - There are several variants on the definition of regular expression, for historical reasons. There is one UNIX(TM) standard, though, which says that all of the versions must be supported by a UNIX system, each being applied in the appropriate contexts as defined by the standard. Internationalization is a very tricky - but extremely important - area. The standards (even the UNIX ones) should not be followed blindly, you need to look carefuly at what implications they would have before referencing them in a matching rule RFC or draft. When dealing with multiple character sets and languages, collating sequences and regular expressions clearly become more difficult. A great deal of very good work went into the definition of internationalized regular expressions. However, that work pre-dates the deployment of UNICODE, which removes some but by no means all of the problems. So far as I know, it has not been re-evaluated in the light of UNICODE, but it certainly should be. Should there be locale attributes and if so where they should go? People must be able to put entries using different languages and character sets in the same directory. This is in fact supported by LDAP language tagging (RFC 2596), and the first question has to be whether any mechanism beyond RFC 2596 is needed. For the sake of simplicity, I would hope not. >Chris, > >Interesting. On reading re.html below I found no less than three 'standards' >in the first paragraph. Mention of locales later completed the picture for >me. > >I guess in the conformance statement for the directory we say which RE >'standard' we are following. We also need an attribute inb the root DSE >which specifies what our locale is. > >Ron. > >-----Original Message----- >From: Chris Harding [mailto:c.harding@opengroup.org] >Sent: Wednesday, 26 July 2000 21:37 >To: Rob Byrne - Sun Microsystems; Kurt D. Zeilenga >Cc: ldapext; a.josey@opengroup.org >Subject: (a.josey 14931) Re: (c.harding 44333) Re: regexMatch (Was: >substring filters using DN attributes ?) > > >>Is there a standard definition of what a regular expression actually is ? >> >There certainly is. > >It is part of the standard definition of the UNIX(TM) operating system >which is available (foc) from The Open Group, see >http://www.opengroup.org/publications/catalog/t912.htm#medium2 > >The definition of regular expressions is at >http://www.opengroup.org/onlinepubs/007908799/xbd/re.html > >>I ask this because if you work on Solaris for example, there are n >different >>libraries and functions for doing regular expression matching so the >meaning >>of "regular expression" is not so obvious. >> >>Rob. >> >>"Kurt D. Zeilenga" wrote: >> >>> At 09:35 AM 7/25/00 -0700, Mark C Smith wrote: >>> >"Kurt D. Zeilenga" wrote: >>> >> >>> >> I've meaning to publish a regexMatch rule I-D which would allow >>> >> matching of an asserted regular expression against the string >>> >> representation of attribute values. Of course, to be useful with >>> >> DNs, we'd have to have to define a canonical string representation >>> >> of DNs. Given such, you would be able to do DN matching like: >>> >> >>> >> (member:regexMatch:=.*,dc=example,dc=com$) >>> >> >>> >> Such a matching rule, I believe, would be generally useful in >>> >> a number of applications. Of course, user applications may >>> >> not want to expose regular expressions to average Joe. >>> >> >>> >> If others concur that this would be generally useful, I'll put >>> >> up a straw man proposal after IETF#48. >>> > >>> >It would be interesting to see examples of the kinds of LDAP application >>> >problems that would be more easily addressed if such a matching rule was >>> >available. >>> >>> I agree. In fact, I wouldn't attempt to write such an I-D >>> without decent examples. In general, such a rule would be useful >>> to applications which required very specific, complex matching >>> which cannot easily be decomposed into a substrings assertion. >>> I'll try to come up with some examples, hopefully ones which >>> are not too contrived. >>> >>> >If all we really need is a way to anchor the start and end >>> >of strings (i.e., ^ and $ from regex), I'd rather see a more narrow >>> >proposal. Why? Because general regular expression matching will be >>> >quite difficult to support using indexes, etc. >>> >>> I concur that general regular expressions are quite difficult to >>> to support using indexing. I also concur that applications wanting >>> to make an assertion should use an appropriate matching rule. I >>> fully agree that applications wanting to simply assert start/end >>> text should use a substrings matching rules. >>> >>> Kurt >> >> >> > >Regards, > >Chris >+++++ > >======================================================================== > Chris Harding > T H E Directory Program Manager > O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 > WWW: http://www.opengroup.org Mobile: +44 771 8588820 >======================================================================== > > Regards, Chris +++++ ======================================================================== Chris Harding T H E Directory Program Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Mobile: +44 771 8588820 ======================================================================== From list@netscape.com Thu Jul 27 16:00:19 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18493 for ; Thu, 27 Jul 2000 16:00:18 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6RJqFj05337; Thu, 27 Jul 2000 12:52:15 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6RJvLQ06517; Thu, 27 Jul 2000 12:57:21 -0700 (PDT) Resent-Date: Thu, 27 Jul 2000 12:57:21 -0700 (PDT) From: officialpolltaker7@hotmail.com Date: Sat, 26 Jun 99 04:51:25 EST To: officialpolltaker7@hotmail.com Subject: Enter The I Love/Hate SpamMail Opinion Poll -Pro Leads 3-1 Message-ID: Reply-To: officialpolltaker7@hotmail.com Comments: Authenticated sender is Resent-Message-ID: <"7K49mB.A.WlB.gQJg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hi, A Poll is being taken to settle the issue whether commercial e-mail or SPAM is a good form of advertisement, which you would like more of or it's a bad form of advertisement which you are against. The arguments go more or less as follows: Pro: Commercial E-mail is a very efficient, cost effective means of informing people about new goods and services. This translates into substantial savings to the consumer. That the vast majority of internet users don't mind Spam and want to hear about new goods and services. That for Years now, more advanced bulk mailing software has allowed bulk mailers to shoulder the full cost of Spamming. This cost has increased and access has become much more difficult due to unfair and illegal practices by the big providers (the later day Robber Barons) Who have a vested interest in keeping Costs and Profits high for as long as possible, and with the news media with whom most have formed alliances, have and continue to wage a war of misinformation, deceptions, and out and out lies. That through an unholy alliance with vix.com, individuals and companies have been targeted by cyber terrorists who have attacked their equipment, programming and subjected people to threats of violence by posting personal information on these legitimate companies employees and individuals home addresses, phone numbers, which leads to threats against them, there families and children. Lastly, that the Robber Barons (Big Internet Providers) use special identification programs in their efforts to stop free trade that invades the privacy of all individuals by identifying, reading, and then determining whether or not you will get your mail or not (ask yourself this question, if AOL or SPRINT or AT&T or MicroSoftNetwork, (MSN), sent someone to your house to intercept your mail, open it, read it, and then arbitrarily decide whether they will put it in your mail box or not. Would you put up with that?) They call it filtering, we know it by its more insidious name, CENSORSHIP. Why in the world should you be subjected to this, and have to pay higher prices ! Anti SPAM: Anti Spam arguments go something like this: They don't like it. Some genuinely want to be isolated fromthe world, others it seems are simply being mislead. Spammers steal services and don't really pay for access, Spammers are evil because the big, rich, powerful, largeinternet service providers say so, and it's OK to targetthem for all kinds of bad things, legal or not. They don't like it. And would rather have themselves and consumers everywhere continue to pay high inflated pricesso that the Robber Barons may grow even richer and morepowerful. And finally, much like the Nazi's final solution to the Jewish problem, they are willing to act as the RobberBaron's Gestapo, ready to report for termination any Spammers or Spam sympathizers. SIMPLE SOLUTION: Press the delete key, STUPID ! Have a different opinion, give us a call because, your opinion on how to make this kind of advertisement better & to increase its use, is vital. Or if this is a terrible form of advertisement and how it should be curtailed, regulated or ended all together. Please call, 1-900-226-0388 and tell us. The charges for registering your opinion are as follows: Of the $1.99 per minute charge, 1-dollar goes to the telephone service Bureau 19 cents to retrieve your opinion 79 cents to transcribe this information into a viable format Leaving a total of 2 cents. So do call if you wish to get your 2 cents worth in ! Attention both Pro and Anti Spam Advocates and those of you who may have sought removal from any number of bulk mailing lists. If you have received this e-mail it is because it is a conscious decision on our part to try and include everyone in this important poll. To not have included those who profess a dislike for this form of advertisement would have eliminated those individuals from the process and provide an unfair advantage to one side of the poll. We sincerely hope that all interested individuals or entity's understand the necessity of inclusion. ******************************************************** This message is sent in compliance of the proposed bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word remove in the subject line. This message is not intended for residents in the State of Washington, screening of addresses has been done to the best of our technical ability. If you are a Washington, Virginia, or California resident or otherwise wish to be removed from this list, further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to mstrsrvcs@mailme.org with the word remove in the subject line. ********************************************************* 11-a-54 From list@netscape.com Thu Jul 27 17:54:04 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15617 for ; Thu, 27 Jul 2000 17:53:56 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6RLfKR04366; Thu, 27 Jul 2000 14:41:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6RLoCM01499; Thu, 27 Jul 2000 14:50:12 -0700 (PDT) Resent-Date: Thu, 27 Jul 2000 14:50:12 -0700 (PDT) X-Lotus-FromDomain: TIVOLI SYSTEMS From: George_Robert_Blakley_III@tivoli.com To: d.w.chadwick@salford.ac.uk cc: ietf-ldapext@netscape.com Message-ID: <86256929.0077F092.00@tivmta4.tivoli.com> Date: Thu, 27 Jul 2000 16:36:42 -0500 Subject: Re: delete permission Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Resent-Message-ID: <"bJOnw.A.JX.T6Kg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Yes it should; in fact I believe it does. If someone thinks there's an undefined case we should discuss it. --bob Bob Blakley Chief Scientist Tivoli SecureWay Business Unit "David Chadwick" on 07/25/2000 01:46:59 PM Please respond to d.w.chadwick@salford.ac.uk To: Ellen Stokes , ietf-ldapext@netscape.com, Bruce Greenblatt cc: (bcc: George Robert Blakley III/Tivoli Systems) Subject: Re: delete permission > A seperate but related issue to how the delete permission overrides > the delete subtree permission, is the more general problems of how to > treat overlapping permissions. I don't know that there needs to be a > general treatment, but when a new permission that is defined overlaps > with a previously defined permission, there should be some discussion > of the relationship. Any thoughts? The document is already starting to do this by giving precedence to the different elements such as subject. Therefore I think that if everthing can be given a pecking order/precedence, and this can be described fully in the model doc, then everything should fall out in the wash, shouldn't it? David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Jul 27 21:32:24 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16349 for ; Thu, 27 Jul 2000 21:32:19 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6S1LXR09632; Thu, 27 Jul 2000 18:21:33 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6S1UOE06904; Thu, 27 Jul 2000 18:30:24 -0700 (PDT) Resent-Date: Thu, 27 Jul 2000 18:30:24 -0700 (PDT) Message-ID: <3980E22C.7C04486A@netscape.com> Date: Thu, 27 Jul 2000 18:30:20 -0700 From: rweltman@netscape.com (Rob Weltman) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,sv,ja MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: auth-response comments References: <4.3.2.7.0.20000726233331.00b35520@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"aJUmpB.A.MrB.uIOg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Darn - I wrote up a revision of the document in April, taking into account all the input from you and others, but I was waiting for the other authors to sign. Well, here it is, anyway. Rob "Kurt D. Zeilenga" wrote: > Rob/Mark, > > Here are some comments, some new, some old... all provided to > ensure completeness. > > First, please note my general aversion to unsolicited controls. > IMO, controls should only be sent to clients which are known to > be able to make use of the information. > > 2. Publishing support for the Authentication Response Control > > s/supportedExtensions/supportedControl/ > > 3. Authentication Response > > >The criticality field is not used. > I would suggest "The criticality of this control SHALL be > FALSE. Servers SHOULD not provide the criticality field." > > Not also that the controlType is determined, its the value > of the field which is TBD. > > You do not specify how AuthResponseValue is to be encoded. > > I do not see the need for authMechanism? The client knows > the method and, if applicable, the SASL mechanism used. However, > what might be useful is source of credential used to in > to complete a SASL/EXTERNAL authentication. > > I note you specify the return of a DN and not an authzID. > You assume that if an userzID is provided (or implied) > by the client that it must be mapped to a DN and if a > DN is provided (or implied) that it is not mapped to > a userzID. JeffH has made arguments that authzId should > be the general form of LDAP authorization information. > In fact, LDAP ACM allows authzID as subjects. You likely > should consider changing authDN to authzID. > > 4. Security Considerations > > Please make specific mention that the control is not > protected by SASL integrity and privacy services > negotiated by the bind operation it is provided with. > Due to this, I suggest use of a separate (extended) > operation instead of a bind control to request/return > this information. > > Kurt Network Working Group Rob Weltman INTERNET-DRAFT Netscape Communications Corp. Mark Smith Netscape Communications Corp. Mark Wahl Sun Microsystems, Inc. April, 2000 LDAP Authentication Response Control draft-weltman-ldapv3-auth-response-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet 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. Abstract This document defines support for the Authentication Request Control and the Authentication Response Control. Controls are an LDAP protocol version 3 extension, to allow passing arbitrary control information along with a standard request to a server, and to receive arbitrary information back with a standard result. The Authentication Request Control may be submitted by a client in a bind request if authenticating with version 3 of the LDAP protocol. In the LDAP server's bind response, it may then include an Authentication Response Control. The response control contains the identity assumed by the client. This is useful when there is a mapping step or other indirection during the bind, so that the client can be told what LDAP identity was granted. Client authentication with certificates is the primary situation where this applies. Also, some SASL authentication mechanisms may not involve the client explicitly providing a DN. 1. Introduction Expires October 2000 [Page 1] AUTHENTICATION RESPONSE CONTROL April, 2000 Version 3 of the LDAP protocol provides a means of supplying arbitrary additional information along with a request to an LDAP server, and receiving arbitrary additional response information. The Control protocol extension is described in [LDAPv3], section 4.1.12. This document defines a way for a server to return the identity assumed by a client on binding using the Control mechanism. The key words "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [RFCKeyWords]. 2. Publishing support for the Authentication Request Control and the Authentication Response Control Support for the Authentication Request Control and the Authentication Response Control is indicated by the presence of the OIDs 2.16.840.1.113730.3.4.16 and 2.16.840.1.113730.3.4.15, respectively, in the supportedExtensions attribute of a server's root DSE. 3. Authentication Request Control This control MAY be included in any bind request which specifies protocol version 3, as part of the controls field of the LDAPMessage as defined in [LDAPv3]. AuthRequestControl ::= SEQUENCE { controlType 2.16.840.1.113730.3.4.16, criticality BOOLEAN DEFAULT FALSE, controlValue NULL } The criticality field is false or absent. 4. Authentication Response Control This control may be included in any final bind response where the bind request included an Authentication Request Control, as part of the controls field of the LDAPMessage as defined in [LDAPv3]. AuthResponseControl ::= SEQUENCE { controlType 2.16.840.1.113730.3.4.15, criticality BOOLEAN DEFAULT FALSE, controlValue AuthDN LDAPDN } If the bind request failed, the control is not included in the bind response. If the bind request resulted in anonymous authentication, the controlValue field is a string of zero length. Expires October 2000 [Page 2 AUTHENTICATION RESPONSE CONTROL April, 2000 During client authentication with certificates [AUTH], a client may possess more than one certificate and not be able to determine which one was ultimately selected for authentication to the server. The subject DN field in the selected certificate may not correspond exactly to a DN in the directory, but rather have gone through a mapping process controlled by the server. On completing the certificate-based authentication, the client may issue a SASL [SASL] bind request, specifying the EXTERNAL mechanism and including an Authentication Request Control. The bind response MAY include an authentication response control indicating the DN in the server's DIT which the certificate was mapped to. 5. Security Considerations The Authentication Response Control is subject to standard LDAP security considerations. The control may be passed over a secure as well as over an insecure channel. No additional confidential information is passed in the control. 6. Copyright Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 7. Bibliography Expires October 2000 [Page 3 AUTHENTICATION RESPONSE CONTROL April, 2000 [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", Internet Draft draft-ietf-asid-ldapv3-protocol- 06.txt, July 1997. [RFCKeyWords] Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement Levels", draft-bradner-key-words-03.txt, January, 1997. [AUTH] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan, "Authentication Methods for LDAP", draft-ietf-ldapext-authmeth- 04.txt, June, 1999. [SASL] J. Myers, "Simple Authentication and Security Layer (SASL", RFC 2222, October, 1997. [ASN.1] X.680 : ITU-T Recommendation X.680 (1997) | ISO/IEC 8824- 1:1998, Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation 8. Author's Addresses Rob Weltman Netscape Communications Corp. MV-068 501 E. Middlefield Rd. Mountain View, CA 94043 USA +1 650 937-3301 rweltman@netscape.com Mark Smith Netscape Communications Corp. MV-068 501 E. Middlefield Rd. Mountain View, CA 94043 USA +1 650 937-3477 mcs@netscape.com Mark Wahl Sun Microsystems, Inc. 911 Capital of Texas Hwy, Suite 4140 Austin, TX 78759 USA +1 512 231 1600 Mark.Wahl@innosoft.com Expires October 2000 [Page 4 AUTHENTICATION RESPONSE CONTROL April, 2000 9. Changes from draft-weltman-ldapv3-auth-response-01.txt 9.1 Authentication Request Control An Authentication Response Control is now only returned if the client requested one by submitting an Authentication Request Control. 9.2 Contents of Authentication Response Control Rather than returning both the authentication DN and the authentication mechanism, the control only returns the authentication DN. 10. Changes from draft-weltman-ldapv3-auth-response-00.txt 10.1 Capitalization of ASN.1 macros AuthResponseControl and AuthResponseValue are capitalized. 10.2 Clarifications Added sentence on behavior for anonymous binds. Expires October 2000 [Page 5 From list@netscape.com Thu Jul 27 22:25:14 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28884 for ; Thu, 27 Jul 2000 22:24:59 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6S2IHj07709; Thu, 27 Jul 2000 19:18:17 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6S2NOc23236; Thu, 27 Jul 2000 19:23:24 -0700 (PDT) Resent-Date: Thu, 27 Jul 2000 19:23:24 -0700 (PDT) Message-ID: <39804274.C671E751@netscape.com> Date: Thu, 27 Jul 2000 07:08:52 -0700 From: rweltman@netscape.com (Rob Weltman) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: auth-response comments References: <4.3.2.7.0.20000726233331.00b35520@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"37mvAD.A.uqF.a6Og5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Darn. I had accomodated (or at least taken into account) all of your comments and written a new draft two months ago, but I was waiting for comments from Mark Wahl before republishing it. Well, anyway, I'm attaching it now. Rob "Kurt D. Zeilenga" wrote: > > Rob/Mark, > > Here are some comments, some new, some old... all provided to > ensure completeness. > > First, please note my general aversion to unsolicited controls. > IMO, controls should only be sent to clients which are known to > be able to make use of the information. > > 2. Publishing support for the Authentication Response Control > > s/supportedExtensions/supportedControl/ > > 3. Authentication Response > > >The criticality field is not used. > I would suggest "The criticality of this control SHALL be > FALSE. Servers SHOULD not provide the criticality field." > > Not also that the controlType is determined, its the value > of the field which is TBD. > > You do not specify how AuthResponseValue is to be encoded. > > I do not see the need for authMechanism? The client knows > the method and, if applicable, the SASL mechanism used. However, > what might be useful is source of credential used to in > to complete a SASL/EXTERNAL authentication. > > I note you specify the return of a DN and not an authzID. > You assume that if an userzID is provided (or implied) > by the client that it must be mapped to a DN and if a > DN is provided (or implied) that it is not mapped to > a userzID. JeffH has made arguments that authzId should > be the general form of LDAP authorization information. > In fact, LDAP ACM allows authzID as subjects. You likely > should consider changing authDN to authzID. > > 4. Security Considerations > > Please make specific mention that the control is not > protected by SASL integrity and privacy services > negotiated by the bind operation it is provided with. > Due to this, I suggest use of a separate (extended) > operation instead of a bind control to request/return > this information. > > Kurt From list@netscape.com Thu Jul 27 23:08:05 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04774 for ; Thu, 27 Jul 2000 23:07:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6S2veR17630; Thu, 27 Jul 2000 19:57:40 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6S36VM04732; Thu, 27 Jul 2000 20:06:31 -0700 (PDT) Resent-Date: Thu, 27 Jul 2000 20:06:31 -0700 (PDT) Date: Thu, 27 Jul 2000 20:03:06 -0700 (PDT) Message-Id: <200007280303.e6S336w27300@xwing.netscape.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=200007271950=" To: ietf-ldapext@netscape.com From: Home Net Profits X-Mailer: 36788DEE.32C7ABFC.b09287838817e05c8ad9840818d22e93 Subject: FREE - Your Fastest Vehicle to Internet Income Organization: Home Net Profits Resent-Message-ID: <"UUHRpD.A.qJB.2iPg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=200007271950= Content-Type: text/plain;charset=US-ASCII Hi, I'm going to help you get started making money on the Internet from home - for FREE! I'll give you your own, fully functional, FREE Affiliate Programs website. No hype. No obligation to buy ANYTHING. It's FREE. For details, send email to: HomeNetProfits@usa.com?subject=FreeWebsite4Me To be removed from our Netrepreneurs list, simply reply to this opportunity, put REMOVE in the subject line, and your address will be promptly removed. Thanks. --=200007271950=-- From list@netscape.com Fri Jul 28 00:37:41 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21399 for ; Fri, 28 Jul 2000 00:37:40 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6S4V3j16691; Thu, 27 Jul 2000 21:31:03 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6S4aAI26751; Thu, 27 Jul 2000 21:36:10 -0700 (PDT) Resent-Date: Thu, 27 Jul 2000 21:36:10 -0700 (PDT) Date: Thu, 27 Jul 2000 21:36:02 -0700 (PDT) Message-Id: <200007280436.e6S4a2w16393@xwing.netscape.com> From: metroelectronics@yahoo.com To: @netscape.com Subject: Cable Descramblers - Cheap!!! X-Reply-To: metroelectronics@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"5J_X-D.A.hhG.42Qg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit CABLE DESCRAMBLERS For Sale Save $100's on your cable bill!! Just subscribe to "basic cable" and our descramblers will let you watch everything else! Get Wrestling Pay Per Views ! Get Boxing Pay Per Views ! Get Movie Channels ! "If your cable company offers it, we'll descramble it!" Low Prices!! Now Only $99.00 ! ! or 2 for $180.00 ! ! plus $15.00 shipping & handling. All orders shipped C.O.D. Hurry, less than 10 left at this price! (301) 893-1683 or email MetroElectronics@yahoo.com Seller assumes no responsibility for the manner in which this product is used. From list@netscape.com Fri Jul 28 03:18:27 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02382 for ; Fri, 28 Jul 2000 03:18:25 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6S7Bhj27829; Fri, 28 Jul 2000 00:11:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6S7Gow06721; Fri, 28 Jul 2000 00:16:50 -0700 (PDT) Resent-Date: Fri, 28 Jul 2000 00:16:50 -0700 (PDT) Reply-To: From: "Steven Legg" To: Cc: , Subject: RE: LDUP Working Group Agenda - Summary of objections to requirements draft Date: Fri, 28 Jul 2000 17:15:56 +1000 Message-ID: <000101bff864$28c7e430$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <000201bff792$2f8e3d00$17448490@vic.bigpond.net.au> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Resent-Message-ID: <"xG2KxB.A.voB.hNTg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Albert, > -----Original Message----- > From: Albert Langer [mailto:Albert.Langer@Directory-Designs.org] > Sent: Thursday, 27 July 2000 16:16 > To: 'Christopher Apple'; ietf-ldup@imc.org; ietf-ldapext@netscape.com > Cc: agenda@ietf.org; johns@cisco.com > Subject: RE: LDUP Working Group Agenda - Summary of objections to > requirements draft [snip] > III. Discussion of LDUP Requirements Document > > [Albert] > I am also sending this to LDAPEXT as the direction taken by > LDUP could have > major consequences for LDAPEXT (eg the current proposals for > ACL simply will > not replicate correctly Servers that don't store access controls as values of the ldapACI attribute will have to give the appearance that they do for the purposes of LDUP. Having done that, the access controls will replicate as any other attribute values would. > and future support for transactions will be > difficult if not impossible). I've outlined an extension to LDUP for providing strong transactional consistency with a configurable degree of availability. Though you might not agree with the philosophy, no one has yet pointed out any fatal flaw in the procedure. [snip] > SUMMARY OF OBJECTIONS TO REQUIREMENTS DRAFT > > The three key points are: > > 1) There is no requirement for convergence or "eventual consistency". > > This looks like just poor expression, but in fact the LDUP > architecture and > Update Reconciliation Procedures do specify proposed standards that > guarantee long term divergence by relying on timestamps The timestamp in the CSN is just a version number that happens to increment without visible update activity. A version number scheme that leaves gaps in the runs of version numbers isn't broken as long as the version numbers from a server are monotonically increasing. The LDUP CSN is monotonically increasing too. The only difference with the LDUP CSN is that the gaps just happen to have a correlation to elapsed time. > and > allowing DSAs to > transmit changes out of order and drop changes when clocks > are out of sync. > This is easily fixed, once a requirement to fix it is agreed on. > > Details on how to fix it based on the Coda replication protocols also > adopted by Active Directory, and a semi-formal proof that the > fix would be > robust in the face of DSAs crashing and being restored from > backups, network > partitioning etc etc, is included in my draft below. Your proof neglects the effects of the purging mechanism. Restoring a crashed DSA from a backup works if no change information is ever removed. However if a backup restores a DSA to a state prior to the purge point of any of the other replicas there exists the possibility that the other DSAs have forgotten changes that the restored DSA needs to bring it up to date and consistent with the others. I have a procedure for solving the replica consistency problems of restored replicas and rejoined partitions but it is written in terms of a log-based implementation using a different purging mechanism. I'm still in the process of recasting it in state-based terms with an update vector. [snip] > 2) There is no requirement for atomic operations. > > Again this is obscured by poor expression and nonsensical > definitions, but > in fact the architecture and URP drafts merge changes to individual > attribute values made concurrently at different replicas. The > fact that this > obviously breaks the ACL standards being developed in LDUP, URP doesn't merge changes to individual values. The current ldapACI attribute type definition equates two values if they are semantically the same, so URP will only have the effect of changing the meaning of a collection of ACIs because of an explicit user change request to remove ACIs. On the other hand, MDCR will arbitrarily throw away previously accepted ACIs because of a potential, but probably non-existent, semantic conflict between the original change requests. MDCR assumes that changes to the same entry at different replicas are automatically in conflict and one of them has to lose. I contend that URP does less damage and therefore has a better chance of achieving a favourable final AC state than MDCR. > despite an > overlap in authorship between the two documents, strongly > confirms that the > consequences for existing applications are simply not > understand and should > be studied through a requirements analysis by actively explaining the > implications and soliciting input from other areas > (operations etc) that may > be affected. > > Fixing this would require substantial changes to the current > architecture > and URP. I have sketched one possible way to do so in the draft below. > > 3) There is no requirement to support mandatory operational > attributes of > LDAP. > > The operational attribute "modifiersName" cannot be supported > meaningfully > as nobody in particular can be said to be responsible for a > change that has > in fact been merged from two or more concurrent changes made > independently > and without knowledge of each other. Even though we talk about changes being "merged" the reality is that one of them will take precedence over the others. The operational attribute updates from that one change also take precedence, so the value of modifiersName corresponds to the latest apparent change to the entry, which is exactly what you'd expect from the single master case. > This severely complicates system > administration as the first thing anybody would want to know > after receiving > a problem report is "who changed what". You've over estimated the utility of the modifiersName attribute. It only tells you who last changed something, not what they changed. [snip] > In my view, both an explicit requirement for atomic operations and a > requirement that the results be 1) predictable and 2) make some kind of > sense to users, should be in the final requirements draft. I don't think obliterating all trace of a user's previously accepted change to an entry because someone else changed some unrelated information in the same entry qualifies as either predictable or sensible to users. [snip] Regards, Steven From list@netscape.com Fri Jul 28 03:25:20 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04570 for ; Fri, 28 Jul 2000 03:25:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6S7J8j28563; Fri, 28 Jul 2000 00:19:08 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6S7OFw08955; Fri, 28 Jul 2000 00:24:15 -0700 (PDT) Resent-Date: Fri, 28 Jul 2000 00:24:15 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Ellen Stokes'" , Cc: Subject: Syntax Issues in Date: Fri, 28 Jul 2000 17:26:58 +1000 Message-ID: <000701bff865$37570b60$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Resent-Message-ID: <"KRnI4B.A.pLC.eUTg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Ellen, Rob, et al, In perusing I noticed some problems with the ASN.1 usage. > 4. The Access Control Information Attribute (ldapACI) > > The access control information attribute, ldapACI, is > defined as: > > ( > NAME 'ldapACI' > DESC 'ldap access control information' > EQUALITY caseIgnoreMatch > SYNTAX directoryString > USAGE directoryOperation > ) The ldapACI SYNTAX and the binary representation of values are not compatible. Values of any attribute declared to be of DirectoryString syntax would be expected to have a BER encoding of a CHOICE of string types rather than a SEQUENCE. Also, the caseIgnoreMatch matching rule is meaningless if applied to a SEQUENCE type. Either define a new syntax OID and find/define a compatible matching rule, or lose the binary representation. I'd prefer the former to the latter. The SYNTAX field should also be an OID rather than a type name. > 4.1.2 ACI Binary Representation > > The following ASN.1 data type is used to represent this > syntax when transferred in binary form: > > ldapACI ::= SEQUENCE { ASN.1 type names must start with an uppercase letter so ldapACI should be LDAPACI or LdapACI. > scope ENUMERATED { > entry (0), > subtree (1) }, > rights SEQUENCE OF CHOICE { > grant [0] Permissions, > deny [1] Permissions }, > attr CHOICE { > all [0] NULL, > entry [1] NULL, > attributes [2] SEQUENCE OF Attribute }, > subject SEQUENCE { > authnLevel CHOICE { > any [0] NULL, > simple [1] NULL, > sasl [2] CHOICE { > any [0] NULL, > mechanism [1] LDAPString -- from [LDAPv3] > } > }, > subject CHOICE { > dn [0] DN, > user [1] utf8String The type name "utf8String" can't be right. I would guess that it should be UTF8String but I haven't got the relevant standard handy to confirm this. > 11.1.1 Request Control > getEffectiveRightsRequest ::= SEQUENCE { Should read: GetEffectiveRightsRequest ::= SEQUENCE { > effectiveRightsRequest SEQUENCE OF SEQUENCE { > whichObject ENUMERATED { > LDAP_ENTRY (1), > LDAP_SUBTREE (2) Identifiers in ENUMERATED lists must start with lowercase letters and cannot contain underscores. Try, ldap-entry (1), ldap-subtree (2) or just, entry (1), subtree (2) like in the BNF. > }, > subject in BNF> | "*" This is meaningless as an ASN.1 type definition. I assume it is intended to be a UTF8String whose contents are the string encoding of a subject according to the BNF, or "*". Otherwise, expose the subject CHOICE as a named ASN.1 type and use that. > 11.1.2 Response Control > getEffectiveRightsResponse ::= { Should read: GetEffectiveRightsResponse ::= SEQUENCE { > result ENUMERATED { > success (0), > operationsError (1), > unavailableCriticalExtension (12), > noSuchAttribute (16), > undefinedAttributeType (17), > invalidAttributeSyntax (21), > insufficientRights (50), > unavailable (52), > unwillingToPerform (53), > other (80) > } > } > PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE { > rights in BNF>, > whichObject ENUMERATED { > LDAP_ENTRY (1), > LDAP_SUBTREE (2) > }, > subject < see in BNF > > } ... has the same problems as previously mentioned. > 12.1 LDAP Get Effective Rights Operation > > ldapGetEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE > { > requestName [0] , > requestValue [1] OCTET STRING OPTIONAL } I suggest describing the extended operation the way draft-ietf-ldup-framing-00.txt does it. I've paraphrased below. An LDAPv3 Extended Request is defined in [LDAPv3] as follows: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL } The requestName portion of the GetEffectiveRightsRequest must be the OID . The requestValue of the GetEffectiveRightsRequest must be set to the BER-encoding of the following: > requestValue ::= SEQUENCE { GetEffectiveRightsRequestValue ::= SEQUENCE { > targetDN LDAPDN, > updates SEQUENCE OF SEQUENCE { > whichObject ENUMERATED { > LDAP_ENTRY (1), > LDAP_SUBTREE (2) > }, > attr SEQUENCE { > attr in BNF > > }, > subject < see in BNF > | "*" > } > } Ditto the usual problems. > The server will respond to this with an LDAPMessage > containing the ExtendedResponse which is a rights list. > > ldapGetEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE > { > COMPONENTS OF LDAPResult, > responseName [10] OPTIONAL, > effectiveRights [11] OCTET STRING OPTIONAL } > I suggest ... An LDAPv3 Extended Response is defined in [LDAPv3] as follows: ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS of LDAPResult, responseName [10] LDAPOID OPTIONAL, response [11] OCTET STRING OPTIONAL } The responseName of the GetEffectiveRightsResponse must be the OID . The response of the GetEffectiveRightsResponse is set to the BER- encoding of: > effectiveRights ::= SEQUENCE OF SEQUENCE { > rights in BNF>, > whichObject ENUMERATED { > LDAP_ENTRY (1), > LDAP_SUBTREE (2) > }, > subject < see in BNF > > } Ditto the usual problems. Regards, Steven From list@netscape.com Fri Jul 28 10:28:54 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00590 for ; Fri, 28 Jul 2000 10:28:52 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6SEI9R28587; Fri, 28 Jul 2000 07:18:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6SER2E28257; Fri, 28 Jul 2000 07:27:02 -0700 (PDT) Resent-Date: Fri, 28 Jul 2000 07:27:02 -0700 (PDT) Message-Id: <3.0.3.32.20000728152249.0070ba54@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 28 Jul 2000 15:22:49 +0100 To: "Ramsay, Ron" From: Chris Harding Subject: Re: (c.harding 44401) RE: (c.harding 44382) RE: (a.josey 14931) Re: (c.harding 44333) Re: regexMatch (Was: substring filters using DN attributes ?) Cc: ldapext Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"XxXmtB.A.P5G.1gZg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hi, Ron - >Thank you, Chris. > >Actually, I was trying to say that I thought that this might be more than a >server would wish to do. I think you are saying (are you?) that, where an >attribute is marked with a language tag, the RE should be applied in a >locale appropriate to *that* language. This implies that filter processing >is attribute ;option dependent? > I'm not exactly sure how it would work - hadn't thought that far. What I was saying was that someone ought to think about it. I'm a bit rusty both on locales and language tags, but I think that it could be possible to deduce a locale from a language tag. Trouble is, locale is a UNIX construct and other O/S's (WIN 95/98 for a start - I don't know about NT) probably don't understand them. It may be possible to do something by keeping the existing RE definition and saying that your character encoding is UNICODE. But this might have undesirable characteristics - for example I suspect that [a-eacute] would include some non-alphabetic characters which probably isn't what you want. >Another problem I see is that re.html defines the syntax but not the >semantics of REs. How an RE is constructed is committed to BNF, but how it >is interpreted is ambiguous. I mention the handling of ^ in subexpressions >and the meaning (not) given to "**". > I would hope that the semantics aren't ambiguous - but you may be right. I think we have a test suite that covers RE processing - if so, it is likely that ambiguities will have been bcorrected and resolved. >Ron. >-----Original Message----- >From: Chris Harding [mailto:c.harding@opengroup.org] >Sent: Thursday, 27 July 2000 18:23 >To: Ramsay, Ron >Cc: ldapext >Subject: Re: (c.harding 44382) RE: (a.josey 14931) Re: (c.harding 44333) >Re: regexMatch (Was: substring filters using DN attributes ?) > > >Hi, Ron - > >There are several variants on the definition of regular expression, for >historical reasons. There is one UNIX(TM) standard, though, which says that >all of the versions must be supported by a UNIX system, each being applied >in the appropriate contexts as defined by the standard. > >Internationalization is a very tricky - but extremely important - area. The >standards (even the UNIX ones) should not be followed blindly, you need to >look carefuly at what implications they would have before referencing them >in a matching rule RFC or draft. > >When dealing with multiple character sets and languages, collating >sequences and regular expressions clearly become more difficult. A great >deal of very good work went into the definition of internationalized >regular expressions. However, that work pre-dates the deployment of >UNICODE, which removes some but by no means all of the problems. So far as >I know, it has not been re-evaluated in the light of UNICODE, but it >certainly should be. > >Should there be locale attributes and if so where they should go? People >must be able to put entries using different languages and character sets in >the same directory. This is in fact supported by LDAP language tagging (RFC >2596), and the first question has to be whether any mechanism beyond RFC >2596 is needed. For the sake of simplicity, I would hope not. > >>Chris, >> >>Interesting. On reading re.html below I found no less than three >'standards' >>in the first paragraph. Mention of locales later completed the picture for >>me. >> >>I guess in the conformance statement for the directory we say which RE >>'standard' we are following. We also need an attribute inb the root DSE >>which specifies what our locale is. >> >>Ron. >> >>-----Original Message----- >>From: Chris Harding [mailto:c.harding@opengroup.org] >>Sent: Wednesday, 26 July 2000 21:37 >>To: Rob Byrne - Sun Microsystems; Kurt D. Zeilenga >>Cc: ldapext; a.josey@opengroup.org >>Subject: (a.josey 14931) Re: (c.harding 44333) Re: regexMatch (Was: >>substring filters using DN attributes ?) >> >> >>>Is there a standard definition of what a regular expression actually is ? >>> >>There certainly is. >> >>It is part of the standard definition of the UNIX(TM) operating system >>which is available (foc) from The Open Group, see >>http://www.opengroup.org/publications/catalog/t912.htm#medium2 >> >>The definition of regular expressions is at >>http://www.opengroup.org/onlinepubs/007908799/xbd/re.html >> >>>I ask this because if you work on Solaris for example, there are n >>different >>>libraries and functions for doing regular expression matching so the >>meaning >>>of "regular expression" is not so obvious. >>> >>>Rob. >>> >>>"Kurt D. Zeilenga" wrote: >>> >>>> At 09:35 AM 7/25/00 -0700, Mark C Smith wrote: >>>> >"Kurt D. Zeilenga" wrote: >>>> >> >>>> >> I've meaning to publish a regexMatch rule I-D which would allow >>>> >> matching of an asserted regular expression against the string >>>> >> representation of attribute values. Of course, to be useful with >>>> >> DNs, we'd have to have to define a canonical string representation >>>> >> of DNs. Given such, you would be able to do DN matching like: >>>> >> >>>> >> (member:regexMatch:=.*,dc=example,dc=com$) >>>> >> >>>> >> Such a matching rule, I believe, would be generally useful in >>>> >> a number of applications. Of course, user applications may >>>> >> not want to expose regular expressions to average Joe. >>>> >> >>>> >> If others concur that this would be generally useful, I'll put >>>> >> up a straw man proposal after IETF#48. >>>> > >>>> >It would be interesting to see examples of the kinds of LDAP >application >>>> >problems that would be more easily addressed if such a matching rule >was >>>> >available. >>>> >>>> I agree. In fact, I wouldn't attempt to write such an I-D >>>> without decent examples. In general, such a rule would be useful >>>> to applications which required very specific, complex matching >>>> which cannot easily be decomposed into a substrings assertion. >>>> I'll try to come up with some examples, hopefully ones which >>>> are not too contrived. >>>> >>>> >If all we really need is a way to anchor the start and end >>>> >of strings (i.e., ^ and $ from regex), I'd rather see a more narrow >>>> >proposal. Why? Because general regular expression matching will be >>>> >quite difficult to support using indexes, etc. >>>> >>>> I concur that general regular expressions are quite difficult to >>>> to support using indexing. I also concur that applications wanting >>>> to make an assertion should use an appropriate matching rule. I >>>> fully agree that applications wanting to simply assert start/end >>>> text should use a substrings matching rules. >>>> >>>> Kurt >>> >>> >>> >> >>Regards, >> >>Chris >>+++++ >> >>======================================================================== >> Chris Harding >> T H E Directory Program Manager >> O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >>G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 >> WWW: http://www.opengroup.org Mobile: +44 771 8588820 >>======================================================================== >> >> > >Regards, > >Chris >+++++ > >======================================================================== > Chris Harding > T H E Directory Program Manager > O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 > WWW: http://www.opengroup.org Mobile: +44 771 8588820 >======================================================================== > > Regards, Chris +++++ ======================================================================== Chris Harding T H E Directory Program Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Mobile: +44 771 8588820 ======================================================================== From list@netscape.com Fri Jul 28 14:13:41 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29489 for ; Fri, 28 Jul 2000 14:13:41 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6SHxUR28232; Fri, 28 Jul 2000 10:59:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6SI8NY06134; Fri, 28 Jul 2000 11:08:23 -0700 (PDT) Resent-Date: Fri, 28 Jul 2000 11:08:23 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Jim Sermersheim" , , Date: Fri, 28 Jul 2000 19:07:56 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Use of criticality in dupent-04 Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <3981DA0C.26533.BA6DA98@localhost> Priority: normal In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"yfZx2C.A.kfB.Wwcg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date forwarded: Wed, 26 Jul 2000 00:11:06 -0700 (PDT) Date sent: Wed, 26 Jul 2000 01:09:47 -0600 From: "Jim Sermersheim" To: , Subject: Re: Use of criticality in dupent-04 Forwarded by: ietf-ldapext@netscape.com > I wouldn't mind removing this, but... 2251 is ambiguous in this area. > If 2251 were to state that the criticality field is only valid and > checked in requests, and ignored for responses, I'd feel more > comfortable. Note also that there are a number of other drafts that > have the same language (see SSS and VLV). Yep - they are wrong as well. Seems like you all copied from each other David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Fri Jul 28 14:19:17 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00747 for ; Fri, 28 Jul 2000 14:19:16 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6SI8vR29975; Fri, 28 Jul 2000 11:08:57 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6SIHmw11359; Fri, 28 Jul 2000 11:17:48 -0700 (PDT) Resent-Date: Fri, 28 Jul 2000 11:17:48 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: , , "'Christopher Apple'" , , Date: Fri, 28 Jul 2000 19:17:22 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: clash of times Reply-to: d.w.chadwick@salford.ac.uk CC: Stephen Kent Message-ID: <3981DC42.28284.BAF7AD1@localhost> Priority: normal In-reply-to: <000201bff792$2f8e3d00$17448490@vic.bigpond.net.au> References: X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"3Eu4XB.A.NxC.L5cg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Folks The PKIX session on Tuesday am clashes with LDAP LDUP replication. Is there any chance we can move either session David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Fri Jul 28 16:02:06 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02627 for ; Fri, 28 Jul 2000 16:02:01 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6SJs5j15248; Fri, 28 Jul 2000 12:54:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6SJxDE01579; Fri, 28 Jul 2000 12:59:13 -0700 (PDT) Resent-Date: Fri, 28 Jul 2000 12:59:13 -0700 (PDT) Message-Id: <4.3.1.0.20000728115522.00ad69d0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 28 Jul 2000 13:04:52 -0700 To: d.w.chadwick@salford.ac.uk, "Jim Sermersheim" , , From: Bruce Greenblatt Subject: Re: Use of criticality in dupent-04 In-Reply-To: <3981DA0C.26533.BA6DA98@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"Zp9L5C.A.ZY.PYeg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > > > I wouldn't mind removing this, but... 2251 is ambiguous in this area. > > If 2251 were to state that the criticality field is only valid and > > checked in requests, and ignored for responses, I'd feel more > > comfortable. Note also that there are a number of other drafts that > > have the same language (see SSS and VLV). > >Yep - they are wrong as well. Seems like you all copied from each >other > >David Are you saying that it is not allowed to put a criticality field in a control that appears in an operation response? This certainly seems to make sense. The LDAP client has already received the result of the operation. It doesn't really seem to matter at that point whether the control in the response was critical or not. If the client doesn't understand the control, it won't make use of it in either case. If the client does understand the control, it doesn't matter what the criticality is either. RFC 2251 should definitely say that criticality in controls that come back to the client in a response can be safely ignored. From list@netscape.com Fri Jul 28 17:01:18 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15568 for ; Fri, 28 Jul 2000 17:01:18 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6SKoKR21929; Fri, 28 Jul 2000 13:50:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6SKxC221460; Fri, 28 Jul 2000 13:59:12 -0700 (PDT) Resent-Date: Fri, 28 Jul 2000 13:59:12 -0700 (PDT) Message-ID: <28560036253BD41191A10000F8BCBD11841BE3@zcard00g.ca.nortel.com> From: "Mircea Pana" To: "'Bruce Greenblatt'" , ietf-ldapext , "d.w.chadwick" Subject: RE: Use of criticality in dupent-04 Date: Fri, 28 Jul 2000 16:50:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF8D5.81BEF080" X-Orig: Resent-Message-ID: <"0pkg5B.A.yMF.YQfg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFF8D5.81BEF080 Content-Type: text/plain; charset="iso-8859-1" I'd say that if a response operation has a control and the client does not understand it then: a) if the control is critical then the client SHOULD NOT make use of this response or (obviously) the associated control b) if the control is not critical then the client MAY use the response and discard the control. If the client doesn't understand the control it will not make use of it - true, but the criticality is an indication to whether or not the server recommends the utilization of the response in case the control is not understood. For example: LCUP [should] makes use of criticality in the entryUpdate controls attached to SearchResultEntries to mark deleted entries: " In response to the client's synchronization request, the server returns a set of SearchResultEntries that fits the client's specification. To represent a deleted entry, the server attaches an entryUpdate control to the corresponding SearchResultEntry. The SearchResultEntry corresponding to a deleted entry MUST contain a valid DN and a valid uniqueid but, to reduce the amount of data sent to the client, it SHOULD not contain any other attributes." Mircea. > -----Original Message----- > From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] > Sent: Friday, July 28, 2000 4:05 PM > To: d.w.chadwick@salford.ac.uk; Jim Sermersheim; ietf-ldapext; > d.w.chadwick > Subject: Re: Use of criticality in dupent-04 > > > > > > > > I wouldn't mind removing this, but... 2251 is ambiguous > in this area. > > > If 2251 were to state that the criticality field is only valid and > > > checked in requests, and ignored for responses, I'd feel more > > > comfortable. Note also that there are a number of other > drafts that > > > have the same language (see SSS and VLV). > > > >Yep - they are wrong as well. Seems like you all copied from each > >other > > > >David > > Are you saying that it is not allowed to put a criticality field in a > control that appears in an operation response? This > certainly seems to > make sense. The LDAP client has already received the result of the > operation. It doesn't really seem to matter at that point > whether the > control in the response was critical or not. If the client doesn't > understand the control, it won't make use of it in either > case. If the > client does understand the control, it doesn't matter what > the criticality > is either. RFC 2251 should definitely say that criticality > in controls > that come back to the client in a response can be safely ignored. > > ------_=_NextPart_001_01BFF8D5.81BEF080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Use of criticality in dupent-04

I'd say that if a response operation has a control = and the client does not understand it  then:
a) if the control is critical then the client SHOULD = NOT make use of this response or (obviously) the associated control =

b) if the control is not critical then the client MAY = use the response and discard the control.

If the client doesn't understand the control it will = not make use of it - true, but the criticality is an indication to = whether or not the server recommends the utilization of the response in = case the control is not understood.

For example:
LCUP [should] makes use of criticality in the = entryUpdate controls attached to SearchResultEntries to mark deleted = entries:

"   In response to the client's = synchronization request, the server
   returns a set of SearchResultEntries = that fits the client's
   specification. To represent a deleted = entry, the server attaches an
   entryUpdate control to the = corresponding SearchResultEntry. The
   SearchResultEntry corresponding to a = deleted entry MUST contain a
   valid DN and a valid uniqueid but, to = reduce the amount of data sent
   to the client, it SHOULD not contain = any other attributes."

Mircea.



> -----Original Message-----
> From: Bruce Greenblatt [mailto:bgreenblat= t@directory-applications.com]
> Sent: Friday, July 28, 2000 4:05 PM
> To: d.w.chadwick@salford.ac.uk; Jim = Sermersheim; ietf-ldapext;
> d.w.chadwick
> Subject: Re: Use of criticality in = dupent-04
>
>
>
> >
> > > I wouldn't mind removing this, but... = 2251 is ambiguous
> in this area.
> > > If 2251 were to state that the = criticality field is only valid and
> > > checked in requests, and ignored for = responses, I'd feel more
> > > comfortable. Note also that there are = a number of other
> drafts that
> > > have the same language (see SSS and = VLV).
> >
> >Yep - they are wrong as well. Seems like = you all copied from each
> >other
> >
> >David
>
> Are you saying that it is not allowed to put a = criticality field in a
> control that appears in an operation = response?  This
> certainly seems to
> make sense.  The LDAP client has already = received the result of the
> operation.  It doesn't really seem to = matter at that point
> whether the
> control in the response was critical or = not.  If the client doesn't
> understand the control, it won't make use of it = in either
> case.  If the
> client does understand the control, it doesn't = matter what
> the criticality
> is either.  RFC 2251 should definitely say = that criticality
> in controls
> that come back to the client in a response can = be safely ignored.
>
>

------_=_NextPart_001_01BFF8D5.81BEF080-- From list@netscape.com Fri Jul 28 17:25:31 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22182 for ; Fri, 28 Jul 2000 17:25:27 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6SLIoj26646; Fri, 28 Jul 2000 14:18:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6SLNv602243; Fri, 28 Jul 2000 14:23:57 -0700 (PDT) Resent-Date: Fri, 28 Jul 2000 14:23:57 -0700 (PDT) X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: , Subject: RE: LDUP Working Group Agenda - Summary of objections to requirements draft Date: Sat, 29 Jul 2000 07:23:47 +1000 Message-ID: <001701bff8da$1e6110e0$17448490@vic.bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <000101bff864$28c7e430$b05508cb@osmium.adacel.com.au> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Resent-Message-ID: <"cYrX4C.A.vi.snfg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit [Issue A - ACI Replication] > [Albert] > I am also sending this to LDAPEXT as the direction taken by > LDUP could have > major consequences for LDAPEXT (eg the current proposals for > ACL simply will > not replicate correctly [Steve] Servers that don't store access controls as values of the ldapACI attribute will have to give the appearance that they do for the purposes of LDUP. Having done that, the access controls will replicate as any other attribute values would. [Albert] Understood. Naturally LDUP can only replicate access controls that are stored as LDAP attributes. RFC 2820 already requires that ACL standards MUST satisfy that necessity (3.1 G3). Since LDUP will replicate access controls the same way that it will replicate other attributes, they will encounter the same problems that other applications will encounter. The problem is that URP merges conflicting concurrent changes to attributes and attribute values made at different replicas, whereas currently proposed LDAPEXT ACI related attributes (like many other applications), rely on an application semantics that assumes they can only be updated atomically. [Issue B - Transactions] > and future support for transactions will be > difficult if not impossible). [Steve] I've outlined an extension to LDUP for providing strong transactional consistency with a configurable degree of availability. Though you might not agree with the philosophy, no one has yet pointed out any fatal flaw in the procedure. [snip] [Albert] When an actual draft has been published, feedback can be expected. Meanwhile, the outline you gave clearly indicates that the proposal relates to DSAs contacting other DSAs before performing an update. This does not satisfy the definition of multi-master replication in the LDUP charter: "A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed." http://www.ietf.org/html.charters/ldup-charter.html It therefore cannot meet the real performance and availability requirements that motivate work on this (although those real requirements for multi-master mentioned in the introduction are completely obscured, buried or forgotten, in the actual text of the "final" requirements doc). There are many well known ways to support full transactions semantics in a non-multimaster environment and yours may or may not do well in comparison with others. Personally I cannot see what advantage it has over Alan Lloyd's advocacy of failover single master, but no doubt you will explain the advantages in a draft. However, like Alan's proposal, it cannot resolve any problems concerning future standardization of transactions that may result from deployment of multi-master LDUP standards, because it is not multi-master. Both the advantage and irrelevance of Alan's proposal is that it does not need any new standards, as it is just an implementation of existing single master standards. I see no reason to solve a problem by new standards when there is no clear advantage over what can be achieved within existing standards. Multi-master does provide local availability of updateable replicas, including availability without continuous connectivity, which cannot be achieved by either your proposal or Alans. Work is proceeding, outside LDUP, but within LDAPEXT, on how to group updates and/or do transactions in a standardized manner. Some applications already use existing directory services to add their own non-standardized transactional semantics, relying only on the LDAP/X.500 data model which *does* support atomic operations on a single entry, but does not provide any means for locking a set of entries or performing an operation atomically on that set. Methods include writing transaction identifiers to special attributes in each of the set of entries, then checking that nobody else did so, to any of them, after updating all the entries. This requires that only DUAs cooperating in a transactional application have write access to all relevant attributes of the entries. This sort of thing can work in a single master environment, but becomes more complex in a multi-master environment. It is still possible provided attributes as a whole are replicated atomically, even though updates to different attributes of a single entry may be merged - as shown by the fact that Active Directory applications can do this, clumsily, using "consistency guids" and "child counts". However it becomes much more difficult, and perhaps impossible, with URP, because even concurrent changes to individual attribute values of a single attribute may be merged. I cannot think of a way to do it satisfactorily in that environment. I suspect you cannot either, or you would not be turning your mind to future proposals for far more complex fundamental changes to DSA implementations, involving locking a majority of DSAs prior to each update. If you can think of a way for applications that need transactions to supply that support themselves within the currently proposed LDUP multi-master framework, as they can with single master replication, please spell it out. However there is no urgency to do so at the moment. All that is needed now is a clear statement in the requirements document that LDUP standards "SHOULD NOT impede future work on transactions". Actual demonstration, or justifying an inability to do so, can be left to subsequent documents and liason with people actually working on grouping or transactions (an area outside the scope of LDUP because it also applies to single server directories). Outlines of future proposals are of course interesting and relevant to the WG, but your outline concerning future transactional support has only one relevance to the final call on the requirements document. If you are confident about it, you should support adding a requirement that LDUP standards "SHOULD NOT impede future work on transactions", or perhaps a stronger requirement that it "MUST NOT". I have provided a definition of "SHOULD NOT impede" and ("MUST NOT impede"), in my individual submission: http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt [Issue C - Convergence] > SUMMARY OF OBJECTIONS TO REQUIREMENTS DRAFT > > The three key points are: > > 1) There is no requirement for convergence or "eventual consistency". > > This looks like just poor expression, but in fact the LDUP > architecture and > Update Reconciliation Procedures do specify proposed standards that > guarantee long term divergence by relying on timestamps [Steve] The timestamp in the CSN is just a version number that happens to increment without visible update activity. A version number scheme that leaves gaps in the runs of version numbers isn't broken as long as the version numbers from a server are monotonically increasing. The LDUP CSN is monotonically increasing too. The only difference with the LDUP CSN is that the gaps just happen to have a correlation to elapsed time. > and > allowing DSAs to > transmit changes out of order and drop changes when clocks > are out of sync. > This is easily fixed, once a requirement to fix it is agreed on. > > Details on how to fix it based on the Coda replication protocols also > adopted by Active Directory, and a semi-formal proof that the > fix would be > robust in the face of DSAs crashing and being restored from > backups, network > partitioning etc etc, is included in my draft below. Your proof neglects the effects of the purging mechanism. Restoring a crashed DSA from a backup works if no change information is ever removed. However if a backup restores a DSA to a state prior to the purge point of any of the other replicas there exists the possibility that the other DSAs have forgotten changes that the restored DSA needs to bring it up to date and consistent with the others. I have a procedure for solving the replica consistency problems of restored replicas and rejoined partitions but it is written in terms of a log-based implementation using a different purging mechanism. I'm still in the process of recasting it in state-based terms with an update vector. [snip] [Albert] My reference to "relying on timestamps and allowing DSAs to transmit changes out of order and drop changes when clocks are out of sync" should be read as a single sentence. Clocks are not necessarily even monotonically increasing because they sometimes jump around when administrators make mistakes, eg with time zone and daylight savings settings. Anyway, as you are not seeking a "final call" on URP without a mechanism spelled out for ensuring eventual convergence, I am quite happy to wait and see whether it can be done without a log-based mechanism when you publish a draft. My proposal, based on a similar vector to the current LDUP drafts, does take account of the purging mechanism - it prevents a purge at *any* replica until after *every* replica has received the change. It does so, precisely for the reason you mentioned. The solution I proposed is based on existing implementations (Coda and AD) that have been thoroughly researched and tested and are known to work and to have a number of advantages. For marketing purposes, AD also describes that as "state based" rather than "log based", by coyly calling the log an "index". I prefer to stick to the technical necessities and leave marketing doubletalk to others. That proposal separates report propagation from update processing and so would be equally applicable to URP or MDCR. It also enables a natural transition from single master to multi-master implementations instead of attempting to force implementation of multi-master as the current LDUP proposals do. The Coda mechanism relies on the fact that change reports are transmitted in order and relies on version numbers rather than timestamps. If it used timestamps it would not work because clocks cannot be guaranteed monotonic. If you have some other mechanism that can also be proved to work, but is somehow able to do it using timestamps and changes transmitted in random order, that's quite an achievement as the Coda research was quite a major project. I look forward to reading the draft but repeat my recommendation that you study the Coda research. As already stated, I do not believe this is a fundamental problem inherent in URP, since URP need not rely on timestamps. There may well be other and better ways to do it, as long as we are agreed that it MUST be done. My description was certainly incomplete, as a protocol for determining which replicas are currently active and which are excluded is necessary for any method. I wrote it because in the current proposals the mechanism was not merely incomplete but absent, and there was explicit language about dropping updates. When I checked back to the requirements I found that what I thought was common ground in assuming a requirement for eventual convergence, was so vague that simply dropping updates and leaving replicas with different states for the same entries could arguably be consistent with the stated requirements. If the current architecture and URP documents have left this for further work, that is fine by me, though it would have been better to have said so explicitly in the drafts. I simply object to the combination of current drafts that indicate intended non-convergence by dropping updates, together with an attempt to finalize a requirements document that does not make it utterly clear that this would be unacceptable. The current wording says the scope includes two models, "Eventual Consistency" and "Limited Effort Eventual Consistency", defining the latter as "where replicas may purge updates therefore dropping propagation changes when some replica time boundary is exceeded, thus leaving some changes replicated to a portion of the replica topology". Instead of ruling out the second, it explicitly says "LADP replication should be flexible enough to cover the above range of capabilities". The actual current drafts do "purge updates therefore dropping propagation changes when some replica time boundary is exceeded, thus leaving some changes replicated to a portion of the replica topology." A requirement "to be flexible enough to cover this" is "simply absurd". That is really an understatement. Are we agreed that the final requirements draft should unambiguously require eventual convergence under ALL circumstances? As long as that requirement IS met, I don't really care that much HOW. [Issue D - Atomic operations] > 2) There is no requirement for atomic operations. > > Again this is obscured by poor expression and nonsensical > definitions, but > in fact the architecture and URP drafts merge changes to individual > attribute values made concurrently at different replicas. The > fact that this > obviously breaks the ACL standards being developed in [LDAPEXT], [Steve] URP doesn't merge changes to individual values. The current ldapACI attribute type definition equates two values if they are semantically the same, so URP will only have the effect of changing the meaning of a collection of ACIs because of an explicit user change request to remove ACIs. [Albert] There is obviously no way that URP *could* merge two attribute values that do not match for equality. I was not accusing you of doing an XOR of the individual bits of attribute values! Nor do I see any problem in the fact that URP will sometimes update a value with a slightly different bit string that does match for equality. The problem I was referring to is that URP merges the addition or deletion of different attribute values of a single entry made concurrently by DUA operations at different replicas. That means the set of ACI attribute values which each of two users thought they were establishing, will differ from the set of ACI attribute values that actually result from their concurrent actions. The example below from Alison's document shows the 9 states that could result from concurrent updates to two attributes at one replica with eventual convergence to one of those changes. Exactly the same applies to concurrent changes to two values of a single attribute such as ldapACI. In addition, the eventual convergence can be to a mixture of both changes with some attributes or attribute values changed by one concurrent operation and others changed by the other. If two users delete an attribute value from an attribute with 2 values it ends up empty, and possibly a schema violation, although each thought they were setting it to the single value the other thought they were deleting. Frankly I think that idea should also be just dismissed as "simply absurd". It isn't something people should find out about only after standards are finalized, buried among the other ingredients like monosodium glutamate. It should be highlighted in the requirements document, preferably with a heading like "WARNING: Lark's Vomit". However it has obviously been taken seriously, so I accept an obligation to answer it seriously. I just want to make damn sure that others who would be affected by it, and who could feel equally amazed, are aware of this intention, and may therefore come to the meeting, since I can't be there - and/or join or rejoin discussions of the WG "last call" on requirements in the LDUP mailing list. [Steve] On the other hand, MDCR will arbitrarily throw away previously accepted ACIs because of a potential, but probably non-existent, semantic conflict between the original change requests. MDCR assumes that changes to the same entry at different replicas are automatically in conflict and one of them has to lose. I contend that URP does less damage and therefore has a better chance of achieving a favourable final AC state than MDCR. > despite an > overlap in authorship between the two documents, strongly > confirms that the > consequences for existing applications are simply not > [understood] and should > be studied through a requirements analysis by actively explaining the > implications and soliciting input from other areas > (operations etc) that may > be affected. > > Fixing this would require substantial changes to the current > architecture > and URP. I have sketched one possible way to do so in the draft below. [Albert] Your contention should certainly be examined carefully. (See below). My aim at present is simply to ensure that LDAPEXT is fully aware of the consequences of letting a "final call" on LDUP requirements go unchallenged. The failure to require atomicity clearly affects ACI and I believe also many other aspects of the base LDAP standards and other extensions to them. The requirements document should clearly explain the potential impact and actively solicit input instead of glossing it over and inventing a new and absurd definition of "atomicity" to prevent thought in a thoroughly Orwellian manner. What is needed is not "a better chance of achieving a favorable [Access Control] state". The requirement ought to be: "LDUP standards SHALL absolutely guarantee correct operation of replicated access controls under all circumstances, during convergence as well as after". If either MDCR or URP, or any other proposal, cannot provide that guarantee it is not acceptable, whether or not it has a "better chance" than some other unacceptable proposal. In my view that guarantee can only be met satisfactorily by preserving the current LDAP/X.500 data model, in which entries are the unit on which operations are performed atomically, not individual attribute values. Obviously we disagree about that. Can we nevertheless agree that meeting that guarantee ought to be a requirement? [Issue E - modifiersName] > 3) There is no requirement to support mandatory operational > attributes of > LDAP. > > The operational attribute "modifiersName" cannot be supported > meaningfully > as nobody in particular can be said to be responsible for a > change that has > in fact been merged from two or more concurrent changes made > independently > and without knowledge of each other. [Steve] Even though we talk about changes being "merged" the reality is that one of them will take precedence over the others. The operational attribute updates from that one change also take precedence, so the value of modifiersName corresponds to the latest apparent change to the entry, which is exactly what you'd expect from the single master case. > This severely complicates system > administration as the first thing anybody would want to know > after receiving > a problem report is "who changed what". You've over estimated the utility of the modifiersName attribute. It only tells you who last changed something, not what they changed. [snip] [Albert] On a single master system, "modifiersName" tells you that what they changed is what was in the entry immediately before the change and what they could have read before making that change. If it wasn't broken before, then it broke because of that change by that DUA. If problems result from the rare race condition in which DUA B updates an entry between DUA A reading the previous state and writing the change based on that read, it tells you that the application should be fixed to prevent such problems in future - eg by explicitly replacing every attribute not changed as well as replacing the attributes changed, instead of just adding or deleting attribute values that are actually changed. That is usually unnecessary in single master environments but is the sort of thing that DOES become necessary for some existing applications in ANY multi-master environment, due to the much longer interval in which conflicting concurrent changes can occur, despite having read the state of the LOCAL copy of an entry "immediately" before changing that entry. That kind of fix could work, perhaps even with URP, by ensuring that convergence will be to the new state resulting from only one of the concurrent changes having actually occurred, and the others having had no effect. With that fix, modifiersName has the same semantics as on existing X.500/LDAP directories - as required by the existing standards. However, most applications will NOT be initially fixed for transition to a multi-master environment. MDCR attempts to minimize the system administration problems that WILL result, by ensuring convergence to the results of applying only 1 concurrent change, whether the applications have been fixed or not. This means that when something breaks that was not broken before, you know it was broken by something done by the DUA that last changed it. With URP, you just know it broke, and it broke after you turned on multi-master replication. Neither the directory service nor any applications of it are intended to support applications making concurrent changes to a single entry. Such concurrency is an unavoidable problem that must be dealt with by any multi-master system. This should be clearly explained in the requirements document and input actively sought from other areas likely to be affected. With URP, modifiersName only tells you that some of the attributes and values in an entry that is causing a problem were changed by that DUA and were changed blindly by that DUA with no way of knowing what the rest of the entry state that it was changing might actually be, or what the changes of that state might result in, based on unknown concurrent changes by other DUAs. The problem may in fact be due to the unknown concurrent changes by other DUAs. The same is true for entries that are causing no problems and in both cases there is no way to be sure of "who did what". So where does a sysadmin begin when trying to track down a problem? Personally I would start by ripping out multi-master replication, because it is obviously broken and causing problems. For what it is worth, that incidentally is the anecdotal results I have been getting in some discussions about future plans - "we're not interested in multi-master, it looks too complicated and unreliable". Nobody wants to have to administer a "directory" where they cannot be sure "who changed what". In fact the only valid value for a URP "modifiersName" attribute could be "nobody". [Issue F - Predictability and Understandability] > In my view, both an explicit requirement for atomic operations and a > requirement that the results be 1) predictable and 2) make some kind of > sense to users, should be in the final requirements draft. [Steve] I don't think obliterating all trace of a user's previously accepted change to an entry because someone else changed some unrelated information in the same entry qualifies as either predictable or sensible to users. [snip] Regards, Steven [Albert] Neither do I. MDCR keeps not only a trace, but a full audit trail at every replica, in which each change is associated with both the modifiersName of the DUA responsible and the replica at which the change occurred and the previous state of the entry. This makes it possible to make the rejected concurrent changes available for fixing by users instead of administrators - in much the same way that URP does this by placing orphans in "lost and found" for those conflicts that it does resolve atomically instead of "reconciling". It also makes it possible to add notifications in conjunction with LCUP or by email. URP just throws all this information away, pretending that there is no problem with conflicting concurrent changes, by obliterating the fact that there ever was a conflict. I believe it is highly predictable and easily understood by users, that if somebody else changes an entry at around the same time that you do, only 1 of the changes can succeed so their change may be eventually accepted and yours eventually rejected. This also happens on single master and single server directories, except that "around the same time" is a longer interval and it will therefore happen more often, and the successful change does not always have the latest timestamp. MDCR also tries to minimize the frequency with which it will happen, by maintaining a tree to serialize any concurrent changes that *could* be serialized. Some applications would still be affected, and the MDCR draft suggests possible ways of dealing with that, such as moving attributes or attribute values that can safely be updated concurrently into separate child entries, and providing backwards compatability through methods based on David Chadwick's "Compound (families) of entries" draft (expired). However it is still certainly a major concern and if the WG was considering any such proposal on its agenda, the potential problems should also be highlighted in a requirements document, to solicit input from other areas that might be affected, for the same reason that URP's approach should be. The fact is you can have locally available updatable replicas (multi-master), atomic operations and irrevocable operations - pick any 2. The choices that must be made between atomicity and durability of operations for multi-master replication should be clearly explained in requirements drafts, so that the consequences of those choices can be evaluated based on feedback. Instead the LDUP WG has chosen to provide no information and solicit no feedback. In my view that does not merit publication even as an "Informational" RFC, except perhaps with the status "Historic". What is not predictable or easily understood by users or administrators is when changes appear on entries that were not made by anybody in particular and yet identify somebody in particular as "modifiersName". URP produces "Extraordinary States" and "Transient Extraordinary States" and can multiply 2 changes made concurrently into 9 different transient states at different replicas for the same entry (with a combinatorial explosion for larger numbers of attribute values changed or concurrent operations). The consistency model of URP, was summarized in Alison's "Contribution to Profiles Document (Consistency Discussion)": http://www.imc.org/ietf-ldup/mail-archive/msg00548.html The attached Word version, with more easily read tables, is: http://www.imc.org/ietf-ldup/mail-archive/doc00000.doc It certainly isn't predictable. In fact I doubt that it can be analysed in non-polynomial time. If you think that it is predictable and makes some kind of sense to users, how about trying to summarize it for the requirements document. Here's an extract, please write a paragraph summary for the LDUP requirements document, in the marketing brochure style of that document, emphasizing how this predictability and understandability further enhances the "simple, highly efficient and flexible" LDUP standards "to meet the needs of both the internet and enterprise environments". *** 3.1 Latest Known Wins Consistency The "Latest Known Wins" approach has the outcome that all attributes will "eventually" reach the latest value entered into the system. During the "eventuality" being reached, intermediate states reflecting a combination of states which have existed over time may be held by an individual DSA. These intermediate states are best described using an example. Two operations, T1 at time 1 and T2 at time 2, occur on an entry updating attributes A and B. This may be viewed as follows : T0 T1 T2 A0 A1 A2 B0 B1 B2 "Latest Known Wins" consistency has the semantics that all directories will eventually have the state A2, B2 (providing no further operations in the distributed system affect attributes A and B). However, at times between either update occurring and this "eventuality", the directory state may be any combination of the individual states of A and B depending on the primitives currently received and processed by each DSA. That is, any of the following states may exist : * A0, B0 (Neither Operation has yet occurred) * A0, B1 (Partial completion of Operation 1) * A0, B2 (Partial completion of Operation 2) * A1, B0 (Partial completion of Operation 1) * A1, B1 (Operation 1 has occurred) * A1, B2 (Operation 1 completed, Partial completion of Operation 2) * A2, B0 (Partial completion of Operation 2) * A2, B1 (Operation 1 completed, Partial completion of Operation 2) * A2, B2 (Operation 2 has occurred) The length of time for "eventuality" to be reached is dependent on * replication agreement structure, (e.g. does the overall topology supported by all relevant replication agreements allow ease of communication between all DSAs?) * scheduling policies, (e.g. are changes made onchange, or via periodic policies (e.g. one per day?)) * DSA reliability, (e.g. are any DSAs bottlenecks in the transition of updates from one network area to another?) * communications links reliability. (e.g. are any DSAs separated from the remainder of the DSAs through slow or unreliable communications links?) Additionally, the above also influences the number and duration of these intermediate states occupied by a DSA. It is possible within a small community of reliable DSAs with reliable communications links to greatly minimise the period of time spent in these intermediate states. *** In my view the only accurate summary would be "LDUP currently does not have a viable proposal for replication standards as it did not do a requirements analysis before embarking on design and the result has inevitably turned out to be broken. We are therefore seeking input on requirements before proceeding further." The problem for URP is that the directory service has no way of defining what is "unrelated information" in the same entry. The whole basis of the LDAP/X.500 data model is that an "entry" consists of RELATED information about a "single entity". The actual relationships among attributes and attribute values are maintained by users and their applications, not by the directory service, so it simply cannot assume that they are unrelated. It does assume that different entries are unrelated, except for maintaining the tree structure, thus making applications themselves responsible for transactions affecting multiple entries. This is intentionally a VERY weak requirement on the directory service, necessary for it to be distributed and globally scalable. By assuming that attributes of an individual entry are unrelated, Active Directory breaks the LDAP/X.500 data model and could be in a real trouble if a viable standards based approach to multi-master LDAP replication gets going. By going further and treating even attribute values of a single attribute as though they are unrelated, URP makes it highly unlikely that a viable alternative to AD will actually be deployable. Why would anyone want anything even less consistent? Anyway, you seem to be agreeing that predictability and understandability should be a criteria by which proposals are evaluated. Can we agree that this should be written into the requirements document? We obviously disagree about whether atomicity is necessary for predictability and understandability and should also be written into the requirements document, but here's a reminder of the close relationship between the two: "Re: LDUP warmup exercise: atomicity in LDAPv3", from Tim Howes (16 December 1998): *** "Each LDAP operation (add, modify, delete, moddn) as a whole is atomic. The whole operation either happens or it doesn't. Changes cannot be half-applied to any single LDAP server. The replication consistency model must assume and build on this basic fact to define how multiple LDAP replicas converge to the same state over time, in the absence of additional changes. This kind of loose consistency model is pretty fundamental to the notion of a directory. My two cents on what's important in a replication consistency model are that it must be 1) predictable, and that it should 2) make some kind of sense to people using the system. All this talk of consistency at different levels (e.g., between applications using the directory at the same time) is a red herring. Our job is to define a consistency model for the directory itself. Some applications may find this model sufficient for their needs. Others may have to build more elaborate models on top. But let's start with the basics. -- Tim" http://www.imc.org/ietf-ldup/mail-archive/msg00214.html *** Could you please respond to it? Do you agree that LDUP has a responsibility to state its consistency model for entries in the requirements document? Whatever that model should be, the requirements document avoids any input about it by simply not mentioning it, and obscures this by irrelevant discussion of consistency between the state of different replicas. Seeya, Albert PS I have corrected two typos in my original with the intended words "understood" and "LDAPEXT" instead of "understand" and "LDUP", and marked those corrections with [brackets]. Also, I have not attempted to list other areas of LDAPEXT work that would be affected by the current LDUP approach, such as signed operations (RFC 2649) - broken by not maintaining the concept of an "operation". From list@netscape.com Fri Jul 28 20:02:50 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28775 for ; Fri, 28 Jul 2000 20:02:49 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6SNqHR16080; Fri, 28 Jul 2000 16:52:17 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6SNfpk01133; Fri, 28 Jul 2000 16:41:51 -0700 (PDT) Resent-Date: Fri, 28 Jul 2000 16:41:51 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 28 Jul 2000 17:41:35 -0600 From: "Jim Sermersheim" To: , , Cc: Subject: Re: Syntax Issues in Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e6SNfn101090 Resent-Message-ID: <"RNXEnC.A.XR.-ohg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit >>> "Steven Legg" 7/28/00 1:24:34 AM >>> > >The ldapACI SYNTAX and the binary representation of values are not >compatible. Values of any attribute declared to be of DirectoryString >syntax would be expected to have a BER encoding of a CHOICE of string >types rather than a SEQUENCE. Also, the caseIgnoreMatch matching rule >is meaningless if applied to a SEQUENCE type. > >Either define a new syntax OID and find/define a compatible matching >rule, or lose the binary representation. I'd prefer the former to the >latter. That's my fault. I see your point, I'm also in favor of defining a new OID and matching rule (or rules). I'm told of a WG meeting some time back (Chicago maybe?) where there was an overwhelming consensus NOT to define new syntax OIDS. If this is still the case, a lesser evil might be to use Octet String syntax, and just force exact matching (eck). >The SYNTAX field should also be an OID rather than a type name. true >> 4.1.2 ACI Binary Representation >> >> The following ASN.1 data type is used to represent this >> syntax when transferred in binary form: >> >> ldapACI ::= SEQUENCE { > >ASN.1 type names must start with an uppercase letter so ldapACI >should be LDAPACI or LdapACI. ok. >> subject CHOICE { >> dn [0] DN, >> user [1] utf8String > >The type name "utf8String" can't be right. I would guess that it should >be UTF8String but I haven't got the relevant standard handy to confirm this. Right, and if UTF8String is not defined, we could change it to UTF8String and add: UTF8String ::= OCTET String -- one or more ISO 10646 characters. >> 11.1.1 Request Control > >> getEffectiveRightsRequest ::= SEQUENCE { > >Should read: > > GetEffectiveRightsRequest ::= SEQUENCE { > >> effectiveRightsRequest SEQUENCE OF SEQUENCE { >> whichObject ENUMERATED { >> LDAP_ENTRY (1), >> LDAP_SUBTREE (2) > >Identifiers in ENUMERATED lists must start with lowercase letters >and cannot contain underscores. > >Try, > > ldap-entry (1), > ldap-subtree (2) > >or just, > > entry (1), > subtree (2) > >like in the BNF. > >> }, >> subject in BNF> | "*" > >This is meaningless as an ASN.1 type definition. I assume it is >intended to be a UTF8String whose contents are the string encoding >of a subject according to the BNF, or "*". Otherwise, expose the >subject CHOICE as a named ASN.1 type and use that. > > >> 11.1.2 Response Control > >> getEffectiveRightsResponse ::= { > >Should read: > > GetEffectiveRightsResponse ::= SEQUENCE { > >.. has the same problems as previously mentioned. I think we hadn't scrubbed the controls and extensions yet. Thanks for these. >> 12.1 LDAP Get Effective Rights Operation >> >> ldapGetEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE >> { >> requestName [0] , >> requestValue [1] OCTET STRING OPTIONAL } > >I suggest describing the extended operation the way >draft-ietf-ldup-framing-00.txt does it. I've paraphrased below. > > An LDAPv3 Extended Request is defined in [LDAPv3] as follows: > > ExtendedRequest ::= [APPLICATION 23] SEQUENCE { > requestName [0] LDAPOID, > requestValue [1] OCTET STRING OPTIONAL > } > > The requestName portion of the GetEffectiveRightsRequest must be the > OID . > > The requestValue of the GetEffectiveRightsRequest must be set to the > BER-encoding of the following: > >> requestValue ::= SEQUENCE { > > GetEffectiveRightsRequestValue ::= SEQUENCE { This makes more sense. >> >> } > >Ditto the usual problems. yes >> The server will respond to this with an LDAPMessage >> containing the ExtendedResponse which is a rights list. >I suggest ... > > An LDAPv3 Extended Response is defined in [LDAPv3] as follows: > > ExtendedResponse ::= [APPLICATION 24] SEQUENCE { > COMPONENTS of LDAPResult, > responseName [10] LDAPOID OPTIONAL, > response [11] OCTET STRING OPTIONAL > } > > The responseName of the GetEffectiveRightsResponse must be the OID > . > > The response of the GetEffectiveRightsResponse is set to the BER- > encoding of: > >> effectiveRights ::= SEQUENCE OF SEQUENCE { Same response. Thanks. Jim From list@netscape.com Fri Jul 28 20:23:09 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03298 for ; Fri, 28 Jul 2000 20:23:08 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6T0CpR18619; Fri, 28 Jul 2000 17:12:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6SNtmM08234; Fri, 28 Jul 2000 16:55:48 -0700 (PDT) Resent-Date: Fri, 28 Jul 2000 16:55:48 -0700 (PDT) Message-ID: <39821C02.9FEC9BD8@software.com> Date: Fri, 28 Jul 2000 16:49:22 -0700 From: sanjay jain Organization: Software.Com X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Wahl CC: ietf-ldapext@netscape.com, paf@swip.net, ned.freed@innosoft.com, agenda@ietf.org Subject: Re: IETF LDAPEXT WG draft agenda References: <10383.964656306@threadgill.austin.innosoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"-bKe9.A.d4B.s1hg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Mark Wahl wrote: > Here is the draft agenda for the LDAPEXT meeting. If you have any > requests, please let me know! Thanks, Mark > > LDAP Extension Working Group (LDAPEXT) > > Monday, July 31, 2000 1300-1500 > > CHAIR: Mark Wahl > > AGENDA: > > 1. Introduction and Agenda Bashing > LDUP, LDAPBIS, Bar BOFs meeting this week > > 2. Status of WG > draft-ietf-ldapext-ldapv3-vlv-04.txt: Approved by IESG > draft-ietf-ldapext-sorting-03.txt: Approved by IESG > draft-ietf-ldapext-ldap-taxonomy-02.txt: Completed WG Last Call > > 3. Duplicate Entries [In WG Last Call] > draft-ietf-ldapext-ldapv3-dupent-04.txt *UPDATED* > > 4. Java API [In WG Last Call] > draft-ietf-ldapext-ldap-java-api-11.txt *UPDATED* > draft-ietf-ldapext-ldap-java-api-asynch-ext-05.txt > > 5. Server discovery [In WG Last Call] > draft-ietf-ldapext-locate-03.txt *UPDATED* > > 6. Access Control Model > draft-ietf-ldapext-acl-model-06.txt *UPDATED* > > 7. Referral and knowledge reference maintenance > draft-ietf-ldapext-refer-00.txt *NEW* > > 8. CLDAP > draft-ietf-ldapext-cldap-00.txt *NEW* > > 9. Subentries > draft-ietf-ldup-subentry-03.txt *UPDATED* > > 10. Charter review > draft-ietf-ldapext-x509-sasl-03.txt > draft-ietf-ldapext-ldap-c-api-04.txt I am not able to find the c-api draft. What am I missing ? thanks. > > draft-just-ldapv3-rescodes-02.txt *UPDATED* > draft-hodges-ldapv3-as-00.txt *NEW* > draft-rharrison-ldap-extpartresp-01.txt *UPDATED* > draft-armijo-ldap-control-error-00.txt *NEW* > draft-zeilenga-ldapv3bis-*.txt *NEW* > draft-smith-ldapv3-*.txt *NEW* > draft-wahl-ldapv3-*.txt *NEW* > > 11. Matched Values > draft-ietf-ldapext-matchedval-02.txt *UPDATED* > > 12. Passwords > draft-zeilenga-ldap-passwd-exop-04.txt *UPDATED* > draft-zeilenga-ldap-authpasswd-03.txt *UPDATED* > draft-behera-ldap-password-policy-02.txt *UPDATED* > > 13. LDAP Controls for Reply Signatures > draft-salzr-ldap-repsig-00.txt *NEW* > > Mark Wahl, Directory Architect, Service Provider/Infrastructure > Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Fri Jul 28 23:18:40 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10353 for ; Fri, 28 Jul 2000 23:18:40 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6T3C1j03239; Fri, 28 Jul 2000 20:12:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6T3H9Q10146; Fri, 28 Jul 2000 20:17:09 -0700 (PDT) Resent-Date: Fri, 28 Jul 2000 20:17:09 -0700 (PDT) Date: Fri, 28 Jul 2000 22:15:57 -0500 From: Mark Wahl Subject: Re: IETF LDAPEXT WG draft agenda In-reply-to: "Your message of Fri, 28 Jul 2000 16:49:22 PDT." <39821C02.9FEC9BD8@software.com> Sender: wahl@austin.innosoft.com To: sanjay jain Cc: ietf-ldapext@netscape.com Message-id: <20597.964840557@threadgill.austin.innosoft.com> Resent-Message-ID: <"kF_phB.A.QeC.0ykg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com It must have timed out. I'll ask Mark Smith to give a status update during this slot of when an updated draft is expected to be available. Mark Wahl, Directory Architect, Service Provider/Infrastructure Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Sat Jul 29 02:45:03 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27407 for ; Sat, 29 Jul 2000 02:45:02 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6T6cUj13617; Fri, 28 Jul 2000 23:38:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6T6hc217269; Fri, 28 Jul 2000 23:43:38 -0700 (PDT) Resent-Date: Fri, 28 Jul 2000 23:43:38 -0700 (PDT) Message-Id: <3.0.5.32.20000728234307.009374b0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 28 Jul 2000 23:43:07 -0700 To: "Mircea Pana" , ietf-ldapext , "d.w.chadwick" From: Bruce Greenblatt Subject: RE: Use of criticality in dupent-04 In-Reply-To: <28560036253BD41191A10000F8BCBD11841BE3@zcard00g.ca.nortel. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"CQcUL.A.jNE.Y0ng5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 04:50 PM 7/28/2000 -0400, Mircea Pana wrote: >I'd say that if a response operation has a control and the client does not understand it then: >a) if the control is critical then the client SHOULD NOT make use of this response or >(obviously) the associated control > But the client already has the whole response. What does it mean to "not make use of the control"? Aren't we only concerned with across the wire behavior? This appears to be an unenforceable mandate... ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html From list@netscape.com Sat Jul 29 14:39:48 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01615 for ; Sat, 29 Jul 2000 14:39:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6TISnR07938; Sat, 29 Jul 2000 11:28:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6TIbhM21180; Sat, 29 Jul 2000 11:37:44 -0700 (PDT) Resent-Date: Sat, 29 Jul 2000 11:37:44 -0700 (PDT) From: Subject: Re: From Lorraine,as promised,I can lower your bill Date: Sat, 29 Jul 2000 15:34:00 Message-Id: <138.589129.307189@altavistausa.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Resent-Message-ID: <"WPR8hB.A.gKF.2Ryg5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Untitled Document


Today, everyone knows the impact of the Internet.
But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!

Uk $.04     France $.06    UAE  $.31    Saudi Arabia $.59     Denmark $.04      Sweden $.05

Click Here Now.

If you do not have flash please go to
www.macromedia.com
to download it.

From list@netscape.com Sat Jul 29 15:42:59 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09134 for ; Sat, 29 Jul 2000 15:42:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6TJWTR11335; Sat, 29 Jul 2000 12:32:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6TJfOM03889; Sat, 29 Jul 2000 12:41:24 -0700 (PDT) Resent-Date: Sat, 29 Jul 2000 12:41:24 -0700 (PDT) Date: Sat, 29 Jul 2000 12:41:11 -0700 (PDT) From: r_5rem@excite.com Message-Id: <200007291941.e6TJfBM05749@ywing.netscape.com> Resent-Message-ID: <"ebP2BC.A.F8.iNzg5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com Subject: Unidentified subject! X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com AUXER IS FORMING $60 MILLION TELECOMMUNICATIONS GROUP July 13, 2000--Auxer has entered discussions to assemble a new group of Telecommunications Services companies. Initial projections show $60 Million in revenues with earnings of $3 to $6 Million. The Board has set a timeline to have the group operational within 3 months. Auxer expects to announce letters of intent this week. AUXER SIGNS LETTER OF INTENT TO ACQUIRE $30 MILLION TELECOMMUNICATIONS DISTRIBUTOR July 27, 2000--The Auxer Group, Inc. (OTCBB: AXGI) announced today that it has signed a letter of intent to acquire the assets of Clifton Telecom Alliance a northeast United States distributor of prepaid phone cards. While the terms have not been disclosed, Auxer has agreed to pay cash and stock as consideration for the assets under a binding agreement. Clifton Telecom Alliance is projected to generate $25 - 30 million in revenue during the initial twelve months under the Auxer Telecom Group. From list@netscape.com Sat Jul 29 16:13:45 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12709 for ; Sat, 29 Jul 2000 16:13:42 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6TK3FR12998; Sat, 29 Jul 2000 13:03:16 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6TKCA610978; Sat, 29 Jul 2000 13:12:10 -0700 (PDT) Resent-Date: Sat, 29 Jul 2000 13:12:10 -0700 (PDT) Sender: mcs@netscape.com (Mark C Smith) Message-ID: <39833A7F.B0E4766F@netscape.com> Date: Sat, 29 Jul 2000 16:11:43 -0400 From: Mark Smith Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Mark Wahl CC: sanjay jain , ietf-ldapext@netscape.com Subject: Re: IETF LDAPEXT WG draft agenda References: <20597.964840557@threadgill.austin.innosoft.com> Content-Type: multipart/mixed; boundary="------------D35DC124AD154E184BDEAFD4" Resent-Message-ID: <"fGqOz.A.OrC.Yqzg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multi-part message in MIME format. --------------D35DC124AD154E184BDEAFD4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Wahl wrote: > > It must have timed out. I'll ask Mark Smith to give a status update during > this slot of when an updated draft is expected to be available. I let the document expire because I did not think it was appropriate to reissue the draft until the issues that were raised during the last call have been addressed... and they have not yet. I actually did not expect it to be removed from the I-D repository so promptly. Sorry for the confusion. Here is a brief list of the significant open issues: 1) Some functions in the API do not provide a reliable way for the caller to detect errors. The best resolution is still being discussed (choices include defining a global LDAP error reporting mechanism or modifying the calls to return result codes directly). 2) Lack of separation between local (API generated) result codes and ones returned by the LDAP server. As currently defined, some space is reserved for APIs within the LDAPv3 result codes. Some people think this is a problem, and others do not. 3) Need to accommodate IPv6 address in the ldap_init() call. Proposed resolution: adopt the format defined in RFC 2732 (Format for Literal IPv6 Addresses in URL's). I do not think this is controversial. 4) Additional result codes and specification needed to support use of non-blocking I/O under the covers. It may be possible to defer this to an API extension. There are also many small clarifications and so on that have been made but not yet published. For reference, the last published C API I-D is attached. -Mark --------------D35DC124AD154E184BDEAFD4 Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-ldapext-ldap-c-api-04.txt" Content-Disposition: inline; filename="draft-ietf-ldapext-ldap-c-api-04.txt" Content-Transfer-Encoding: quoted-printable Network Working Group M. Smith, Editor INTERNET-DRAFT Netscape Communications Corp. Intended Category: Standards Track T. Howes Obsoletes: RFC 1823 Expires: 8 April 2000 A. Herron Microsoft Corp. M. Wahl Innosoft International, Inc. A. Anantha Microsoft Corp. 8 October 1999 The C LDAP Application Program Interface 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working docu- ments 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 draft document will be submitted to the RFC Editor as a Standards Track document. Distribution of this memo is unlimited. Technical dis- cussion of this document will take place on the IETF LDAP Extension Working Group mailing list . Please send editorial comments directly to the authors. Copyright (C) The Internet Society (1997-1999). All Rights Reserved. Please see the Copyright section near the end of this document for more information. Expires: 8 April 2000 [Page 1] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 2. Introduction This document defines a C language application program interface (API) to the Lightweight Directory Access Protocol (LDAP). This document replaces the previous definition of this API, defined in RFC 1823, updating it to include support for features found in version 3 of the LDAP protocol. New extended operation functions were added to support LDAPv3 features such as controls. In addition, other LDAP API changes were made to support information hiding and thread safety. 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 RFC 2119[1]. The C LDAP API is designed to be powerful, yet simple to use. It defines compatible synchronous and asynchronous interfaces to LDAP to suit a wide variety of applications. This document gives a brief overview of the LDAP model, then an overview of how the API is used by an applica- tion program to obtain LDAP information. The API calls are described in detail, followed by appendices that provide example code demonstrating use of the API, the namespace consumed by the API, a summary of require- ments for API extensions, known incompatibilities with RFC 1823, and a list of changes made since the last revision of this document. 3. Table of Contents 1. Status of this Memo............................................1 2. Introduction...................................................2 3. Table of Contents..............................................2 4. Overview of the LDAP Model.....................................4 5. Overview of LDAP API Use and General Requirements..............4 6. Header Requirements............................................6 7. Common Data Structures and Types...............................7 8. Memory Handling Overview.......................................9 9. Retrieving Information About the API Implementation............9 9.1. Retrieving Information at Compile Time......................9 9.2. Retrieving Information During Execution.....................11 10. LDAP Error Codes...............................................14 11. Performing LDAP Operations.....................................15 11.1. Initializing an LDAP Session................................15 11.2. LDAP Session Handle Options.................................16 11.3. Working With Controls.......................................22 11.3.1. A Client Control That Governs Referral Processing........23 11.4. Authenticating to the directory.............................24 11.5. Closing the session.........................................26 11.6. Searching...................................................27 11.7. Reading an Entry............................................31 Expires: 8 April 2000 [Page 2] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 11.8. Listing the Children of an Entry............................31 11.9. Comparing a Value Against an Entry..........................31 11.10. Modifying an entry..........................................33 11.11. Modifying the Name of an Entry..............................36 11.12. Adding an entry.............................................38 11.13. Deleting an entry...........................................40 11.14. Extended Operations.........................................41 12. Abandoning An Operation........................................43 13. Obtaining Results and Peeking Inside LDAP Messages.............43 14. Handling Errors and Parsing Results............................45 15. Stepping Through a List of Results.............................48 16. Parsing Search Results.........................................49 16.1. Stepping Through a List of Entries or References............49 16.2. Stepping Through the Attributes of an Entry.................51 16.3. Retrieving the Values of an Attribute.......................52 16.4. Retrieving the name of an entry.............................53 16.5. Retrieving controls from an entry...........................54 16.6. Parsing References..........................................55 17. Encoded ASN.1 Value Manipulation...............................56 17.1. BER Data Structures and Types...............................56 17.2. Memory Disposal and Utility Functions.......................57 17.3. Encoding....................................................58 17.4. Encoding Example............................................61 17.5. Decoding....................................................62 17.6. Decoding Example............................................65 18. Security Considerations........................................67 19. Acknowledgements...............................................68 20. Copyright......................................................68 21. Bibliography...................................................68 22. Authors' Addresses.............................................69 23. Appendix A - Sample C LDAP API Code............................70 24. Appendix B - Namespace Consumed By This Specification..........72 25. Appendix C - Summary of Requirements for API Extensions........72 25.1. Compatibility...............................................72 25.2. Style.......................................................73 25.3. Dependence on Externally Defined Types......................73 25.4. Compile Time Information....................................73 25.5. Runtime Information.........................................73 25.6. Values Used for Session Handle Options......................73 26. Appendix D - Known Incompatibilities with RFC 1823.............74 26.1. Opaque LDAP Structure.......................................74 26.2. Additional Error Codes......................................74 26.3. Freeing of String Data with ldap_memfree()..................74 26.4. Changes to ldap_result()....................................75 26.5. Changes to ldap_first_attribute() and ldap_next_attribute...75 26.6. Changes to ldap_modrdn() and ldap_modrdn_s() Functions......75 26.7. Changes to the berval structure.............................75 26.8. API Specification Clarified.................................75 26.9. Deprecated Functions........................................76 Expires: 8 April 2000 [Page 3] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 27. Appendix E - Data Types and Legacy Implementations.............76 28. Appendix F - Changes Made Since Last Document Revision.........77 28.1. API Changes.................................................77 28.2. Editorial Changes...........................................79 4. Overview of the LDAP Model LDAP is the lightweight directory access protocol, described in [2] and [3]. It can provide a lightweight frontend to the X.500 directory [4], or a stand-alone service. In either mode, LDAP is based on a client- server model in which a client makes a TCP connection to an LDAP server, over which it sends requests and receives responses. The LDAP information model is based on the entry, which contains infor- mation about some object (e.g., a person). Entries are composed of attributes, which have a type and one or more values. Each attribute has a syntax that determines what kinds of values are allowed in the attri- bute (e.g., ASCII characters, a jpeg photograph, etc.) and how those values behave during directory operations (e.g., is case significant during comparisons). Entries may be organized in a tree structure, usually based on politi- cal, geographical, and organizational boundaries. Each entry is uniquely named relative to its sibling entries by its relative distinguished name (RDN) consisting of one or more distinguished attribute values from the entry. At most one value from each attribute may be used in the RDN. For example, the entry for the person Babs Jensen might be named with the "Barbara Jensen" value from the commonName attribute. A globally unique name for an entry, called a distinguished name or DN, is constructed by concatenating the sequence of RDNs from the entry up to the root of the tree. For example, if Babs worked for the University of Michigan, the DN of her U-M entry might be "cn=3DBarbara Jensen, o=3DUniversity of Michigan, c=3DUS". The DN format used by LDAP is define= d in [5]. Operations are provided to authenticate, search for and retrieve infor- mation, modify information, and add and delete entries from the tree. The next sections give an overview of how the API is used and detailed descriptions of the LDAP API calls that implement all of these func- tions. 5. Overview of LDAP API Use and General Requirements An application generally uses the C LDAP API in four simple steps. Expires: 8 April 2000 [Page 4] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 1. Initialize an LDAP session with a primary LDAP server. The ldap_init() function returns a handle to the session, allowing multiple connections to be open at once. 2. Authenticate to the LDAP server. The ldap_sasl_bind() function and friends support a variety of authentication methods. 3. Perform some LDAP operations and obtain some results. ldap_search() and friends return results which can be parsed by ldap_parse_result(), ldap_first_entry(), ldap_next_entry(), etc. 4. Close the session. The ldap_unbind() function closes the connec- tion. Operations can be performed either synchronously or asynchronously. The names of the synchronous functions end in _s. For example, a synchronous search can be completed by calling ldap_search_s(). An asynchronous search can be initiated by calling ldap_search(). All synchronous rou- tines return an indication of the outcome of the operation (e.g, the constant LDAP_SUCCESS or some other error code). The asynchronous rou- tines make available to the caller the message id of the operation ini- tiated. This id can be used in subsequent calls to ldap_result() to obtain the result(s) of the operation. An asynchronous operation can be abandoned by calling ldap_abandon() or ldap_abandon_ext(). Results and errors are returned in an opaque structure called LDAPMes- sage. Routines are provided to parse this structure, step through entries and attributes returned, etc. Routines are also provided to interpret errors. Later sections of this document describe these rou- tines in more detail. LDAP version 3 servers can return referrals and references to other servers. By default, implementations of this API will attempt to follow referrals automatically for the application. This behavior can be dis- abled globally (using the ldap_set_option() call) or on a per-request basis through the use of a client control. All DN and string attribute values passed into or produced by this C LDAP API are represented using the character set of the underlying LDAP protocol version in use. When this API is used with LDAPv3, DN and string values are represented as UTF-8[6] characters. When this API is used with LDAPv2, the US-ASCII[7] or T.61[7] character set are used. Future documents MAY specify additional APIs supporting other character sets. For compatibility with existing applications, implementations of this API will by default use version 2 of the LDAP protocol. Applications that intend to take advantage of LDAP version 3 features will need to Expires: 8 April 2000 [Page 5] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 use the ldap_set_option() call with a LDAP_OPT_PROTOCOL_VERSION to switch to version 3. Unless otherwise indicated, conformant implementations of this specifi- cation MUST implement all of the C LDAP API functions as described in this document, and they MUST use the function prototypes, macro defini- tions, and types defined in this document. Note that this API is designed for use in environments where the 'int' type is at least 32 bits in size. 6. Header Requirements To promote portability of applications, the following requirements are imposed on the headers used by applications to access the services of this API: Name and Inclusion Applications only need to include a single header named ldap.h to access all of the API services described in this document. Therefore, the following C source program MUST compile without errors: #include int main() { return 0; } The ldap.h header MAY include other implementation-specific headers. Implementations SHOULD also provide a header named lber.h to facilitate development of applications desiring compatibility with older LDAP implementations. The lber.h header MAY be empty. Old applications that include lber.h in order to use BER facilities will need to include ldap.h. Idempotence All headers SHOULD be idempotent; that is, if they are included more than once the effect is as if they had only been included once. Must Be Included Before API Is Used Expires: 8 April 2000 [Page 6] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 An application MUST include the ldap.h header before referencing any of the function or type definitions described in this API specification. Mutual Independence Headers SHOULD be mutually independent with minimal dependence on system or any other headers. Use of the 'const' Keyword This API specification is defined in terms of ISO C[8]. It makes use of function prototypes and the 'const' keyword. The use of 'const' in this specification is limited to simple, non- array function parameters to avoid forcing applications to declare parameters and variables that accept return values from LDAP API functions as 'const.' Implementations specifically designed to be used with non-ISO C translators SHOULD provide function declarations without prototypes or function prototypes without specification of 'const' arguments. Definition of 'struct timeval' This API specification uses the 'struct timeval' type. Imple- mentations of this API MUST ensure that the struct timeval type is by default defined as a consequence of including the ldap.h header. Because struct timeval is usually defined in one or more system headers, it is possible for header conflicts to occur if ldap.h also defines it or arranges for it to be defined by including another header. Therefore, applications MAY want to arrange for struct timeval to be defined before they include ldap.h. To support this, the ldap.h header MUST NOT itself define struct timeval if the preprocessor symbol LDAP_TYPE_TIMEVAL_DEFINED is defined before ldap.h is included. 7. Common Data Structures and Types Data structures and types that are common to several LDAP API functions are defined here: typedef struct ldap LDAP; typedef struct ldapmsg LDAPMessage; typedef struct berelement BerElement; typedef impl_len_t ber_len_t; typedef struct berval { ber_len_t bv_len; Expires: 8 April 2000 [Page 7] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 char *bv_val; } BerValue; struct timeval { impl_sec_t tv_sec; impl_usec_t tv_usec; }; The LDAP structure is an opaque data type that represents an LDAP ses- sion Typically this corresponds to a connection to a single server, but it MAY encompass several server connections in the face of LDAPv3 refer- rals. The LDAPMessage structure is an opaque data type that is used to return entry, reference, result, and error information. An LDAPMessage struc- ture can represent the beginning of a list, or chain of messages that consists of a series of entries, references, and result messages as returned by LDAP operations such as search. LDAP API functions such as ldap_parse_result() that operate on message chains that can contain more than one result message always operate on the first result message in the chain. See the "Obtaining Results and Peeking Inside LDAP Messages" section of this document for more information. The BerElement structure is an opaque data type that is used to hold data and state information about encoded data. It is described in more detail in the section "Encoded ASN.1 Value Manipulation" later in this document. The `ber_len_t' type is an unsigned integral data type that is large enough to contain the length of the largest piece of data supported by the API implementation. The `impl_len_t' in the `ber_len_t' typedef MUST be replaced with an appropriate type. The width (number of signi- ficant bits) of `ber_len_t' MUST be at least 32 and no larger than that of `unsigned long'. See the appendix "Data Types and Legacy Implementa- tions" for additional considerations. The BerValue structure is used to represent arbitrary binary data and its fields have the following meanings: bv_len Length of data in bytes. bv_val A pointer to the data itself. The timeval structure is used to represent an interval of time and its fields have the following meanings: tv_sec Seconds component of time interval. Expires: 8 April 2000 [Page 8] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 tv_usec Microseconds component of time interval. Note that because the struct timeval definition typically is derived from a system header, the types used for the tv_sec and tv_usec com- ponents are implementation-specific integral types. Therefore, `impl_sec_t' and `impl_usec_t' in the struct timeval definition MUST be replaced with appropriate types. See the earlier section "Header Requirements" for more information on struct timeval. 8. Memory Handling Overview All memory that is allocated by a function in this C LDAP API and returned to the caller SHOULD be disposed of by calling the appropriate "free" function provided by this API. The correct "free" function to call is documented in each section of this document where a function that allocates memory is described. Memory that is allocated through means outside of the C LDAP API MUST NOT be disposed of using a function provided by this API. If a pointer value passed to one of the C LDAP API "free" functions is NULL, graceful failure (i.e, ignoring of the NULL pointer) MUST occur. The complete list of "free" functions that are used to dispose of allo- cated memory is: ber_bvecfree() ber_bvfree() ber_free() ldap_control_free() ldap_controls_free() ldap_memfree() ldap_msgfree() ldap_value_free() ldap_value_free_len() 9. Retrieving Information About the API Implementation Applications developed to this specification need to be able to deter- mine information about the particular API implementation they are using both at compile time and during execution. 9.1. Retrieving Information at Compile Time All conformant implementations MUST include the following five Expires: 8 April 2000 [Page 9] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 definitions in a header so compile time tests can be done by LDAP software developers: #define LDAP_API_VERSION level #define LDAP_VERSION_MIN min-version #define LDAP_VERSION_MAX max-version #define LDAP_VENDOR_NAME "vend-name" #define LDAP_VENDOR_VERSION vend-version where: "level" is replaced with the RFC number given to this C LDAP API specification when it is published as a standards track RFC. min-version is replaced with the lowest LDAP protocol version sup- ported by the implementation. max-version is replaced with the highest LDAP protocol version sup- ported by the implementation. This SHOULD be 3. "vend-name" is replaced with a text string that identifies the party that supplies the API implementation. "vend-version" is a supplier-specific version number multiplied times 100. Note that the LDAP_VENDOR_NAME macro SHOULD be defined as "" if no ven- dor name is available and the LDAP_VENDOR_VERSION macro SHOULD be defined as 0 if no vendor-specific version information is available. For example, if this specification is published as RFC 88888, Netscape Communication's version 4.0 implementation that supports LDAPv2 and v3 might include macro definitions like these: #define LDAP_API_VERSION 88888 /* RFC 88888 compliant */ #define LDAP_VERSION_MIN 2 #define LDAP_VERSION_MAX 3 #define LDAP_VENDOR_NAME "Netscape Communications Corp." #define LDAP_VENDOR_VERSION 400 /* version 4.0 */ and application code can test the C LDAP API version level using a construct such as this one: #if (LDAP_API_VERSION >=3D 88888) /* use features supported in RFC 88888 or later */ #endif Until such time as this document is published as an RFC, implementations Expires: 8 April 2000 [Page 10] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 SHOULD use the value 2000 plus the revision number of this draft for LDAP_API_VERSION. For example, the correct value for LDAP_API_VERSION for revision 04 of this draft is 2004. Documents that extend this specification SHOULD define a macro of the form: #define LDAP_API_FEATURE_x level where "x" is replaced with a name (textual identifier) for the feature and "level" is replaced with the number of the RFC that specifies the API extension. The name SHOULD NOT begin with the string "X_". For example, if C LDAP API extensions for Transport Layer Security [9] were published in RFC 99999, that RFC might require conformant implemen- tations to define a macro like this: #define LDAP_API_FEATURE_TLS 99999 Private or experimental API extensions SHOULD be indicated by defining a macro of this same form where "x" (the extension's name) begins with the string "X_" and "level" is replaced with a integer number that is specific to the extension. It is RECOMMENDED that private or experimental API extensions use only the following prefixes for macros, types, and function names: LDAP_X_ LBER_X_ ldap_x_ ber_x_ and that these prefixes not be used by standard extensions. 9.2. Retrieving Information During Execution The ldap_get_option() call (described in greater detail later in this document) can be used during execution in conjunction with an option parameter value of LDAP_OPT_API_INFO (0x00) to retrieve some basic information about the API and about the specific implementation being used. The ld parameter to ldap_get_option() can be either NULL or a valid LDAP session handle which was obtained by calling ldap_init(). The optdata parameter to ldap_get_option() SHOULD be the address of an LDAPAPIInfo structure which is defined as follows: typedef struct ldapapiinfo { int ldapai_info_version; /* version of this struct (1) */ int ldapai_api_version; /* revision of API supported */ Expires: 8 April 2000 [Page 11] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 int ldapai_protocol_version; /* highest LDAP version supported */= char **ldapai_extensions; /* names of API extensions */ char *ldapai_vendor_name; /* name of supplier */ int ldapai_vendor_version; /* supplier-specific version times 1= 00 */ } LDAPAPIInfo; In addition, API implementations MUST include the following macro defin- ition: #define LDAP_API_INFO_VERSION 1 Note that the ldapai_info_version field of the LDAPAPIInfo structure SHOULD be set to the value LDAP_API_INFO_VERSION (1) before calling ldap_get_option() so that it can be checked for consistency. All other fields are set by the ldap_get_option() function. The members of the LDAPAPIInfo structure are: ldapai_info_version A number that identifies the version of the LDAPAPIInfo struc- ture. This SHOULD be set to the value LDAP_API_INFO_VERSION (1) before calling ldap_get_option(). If the value received is not recognized by the API implementation, the ldap_get_option() function sets ldapai_info_version to a valid value that would be recognized, sets the ldapai_api_version to the correct value, and returns an error without filling in any of the other fields in the LDAPAPIInfo structure. ldapai_api_version A number that matches that assigned to the C LDAP API RFC sup- ported by the API implementation. This SHOULD match the value of the LDAP_API_VERSION macro defined earlier. ldapai_protocol_version The highest LDAP protocol version supported by the implementa- tion. For example, if LDAPv3 is the highest version supported then this field will be set to 3. ldapai_extensions A NULL-terminated array of character strings that lists the names of the API extensions supported by the LDAP API imple- mentation. These names will typically match the textual iden- tifiers that appear in the "x" portion of the LDAP_API_FEATURE_x macros described above, although the pre- cise value MUST be defined by documents that specify C LDAP API extensions. If no API extensions are supported, this field will be set to NULL. The caller is responsible for disposing of the memory occupied by this array by passing it Expires: 8 April 2000 [Page 12] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 to ldap_value_free() which is described later in this docu- ment. To retrieve more information about a particular exten- sion, the ldap_get_option() call can be used with an option parameter value of LDAP_OPT_API_FEATURE_INFO (0x15). The opt- data parameter to the ldap_get_option() SHOULD be the address of an LDAPAPIFeatureInfo structure which is defined as fol- lows: typedef struct ldap_apifeature_info { int ldapaif_info_version; /* version of this struct (1= ) */ char *ldapaif_name; /* name of supported feature= */ int ldapaif_version; /* revision of supported fea= ture */ } LDAPAPIFeatureInfo; In addition, API implementations MUST include the following macro definition: #define LDAP_FEATURE_INFO_VERSION 1 Note that the ldapaif_info_version field of the LDAPAPI- FeatureInfo structure SHOULD be set to the value LDAP_FEATURE_INFO_VERSION (1) and the ldapaif_name field SHOULD be set to the extension name string as described below before ldap_get_option() is called. The call will fill in the ldapaif_version field of the LDAPAPIFeatureInfo structure. The members of the LDAPAPIFeatureInfo structure are: ldapaif_info_version A number that identifies the version of the LDAPAPI- FeatureInfo structure. This SHOULD be set to the value LDAP_FEATURE_INFO_VERSION (1) before calling ldap_get_option(). If the value received is not recognized by the API implementation, the ldap_get_option() function sets ldapaif_info_version to a valid value that would be recognized and returns an error without filling in the ldapaif_version field in the LDAPAPIFeatureInfo structure. ldapaif_name The name of an extension, as returned in the ldapai_extensions array of the LDAPAPIInfo structure and as specified in the document that describes the extension. ldapaif_version This field will be set as a result of calling ldap_get_option(). It is a number that matches that assigned to the C LDAP API extension RFC supported for this extension. For private or experimental API extensions, the Expires: 8 April 2000 [Page 13] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 value is extension-specific. In either case, the value of ldapaxi_ext_version SHOULD be identical to the value of the LDAP_API_FEATURE_x macro defined for the extension (described above). 10. LDAP Error Codes Many of the LDAP API routines return LDAP error codes, some of which indicate local errors and some of which are returned by servers. All of the LDAP error codes returned will be non-negative integers. Supported error codes are (hexadecimal values are given in parentheses after the constant): LDAP_SUCCESS (0x00) LDAP_OPERATIONS_ERROR (0x01) LDAP_PROTOCOL_ERROR (0x02) LDAP_TIMELIMIT_EXCEEDED (0x03) LDAP_SIZELIMIT_EXCEEDED (0x04) LDAP_COMPARE_FALSE (0x05) LDAP_COMPARE_TRUE (0x06) LDAP_STRONG_AUTH_NOT_SUPPORTED (0x07) LDAP_STRONG_AUTH_REQUIRED (0x08) LDAP_REFERRAL (0x0a) -- new in LDAP= v3 LDAP_ADMINLIMIT_EXCEEDED (0x0b) -- new in LDAP= v3 LDAP_UNAVAILABLE_CRITICAL_EXTENSION (0x0c) -- new in LDAP= v3 LDAP_CONFIDENTIALITY_REQUIRED (0x0d) -- new in LDAP= v3 LDAP_SASL_BIND_IN_PROGRESS (0x0e) -- new in LDAP= v3 LDAP_NO_SUCH_ATTRIBUTE (0x10) LDAP_UNDEFINED_TYPE (0x11) LDAP_INAPPROPRIATE_MATCHING (0x12) LDAP_CONSTRAINT_VIOLATION (0x13) LDAP_TYPE_OR_VALUE_EXISTS (0x14) LDAP_INVALID_SYNTAX (0x15) LDAP_NO_SUCH_OBJECT (0x20) LDAP_ALIAS_PROBLEM (0x21) LDAP_INVALID_DN_SYNTAX (0x22) LDAP_IS_LEAF (0x23) -- not used in= LDAPv3 LDAP_ALIAS_DEREF_PROBLEM (0x24) LDAP_INAPPROPRIATE_AUTH (0x30) LDAP_INVALID_CREDENTIALS (0x31) LDAP_INSUFFICIENT_ACCESS (0x32) LDAP_BUSY (0x33) LDAP_UNAVAILABLE (0x34) LDAP_UNWILLING_TO_PERFORM (0x35) LDAP_LOOP_DETECT (0x36) LDAP_NAMING_VIOLATION (0x40) LDAP_OBJECT_CLASS_VIOLATION (0x41) Expires: 8 April 2000 [Page 14] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 LDAP_NOT_ALLOWED_ON_NONLEAF (0x42) LDAP_NOT_ALLOWED_ON_RDN (0x43) LDAP_ALREADY_EXISTS (0x44) LDAP_NO_OBJECT_CLASS_MODS (0x45) LDAP_RESULTS_TOO_LARGE (0x46) -- reserved fo= r CLDAP LDAP_AFFECTS_MULTIPLE_DSAS (0x47) -- new in LDAP= v3 LDAP_OTHER (0x50) LDAP_SERVER_DOWN (0x51) LDAP_LOCAL_ERROR (0x52) LDAP_ENCODING_ERROR (0x53) LDAP_DECODING_ERROR (0x54) LDAP_TIMEOUT (0x55) LDAP_AUTH_UNKNOWN (0x56) LDAP_FILTER_ERROR (0x57) LDAP_USER_CANCELLED (0x58) LDAP_PARAM_ERROR (0x59) LDAP_NO_MEMORY (0x5a) LDAP_CONNECT_ERROR (0x5b) LDAP_NOT_SUPPORTED (0x5c) LDAP_CONTROL_NOT_FOUND (0x5d) LDAP_NO_RESULTS_RETURNED (0x5e) LDAP_MORE_RESULTS_TO_RETURN (0x5f) LDAP_CLIENT_LOOP (0x60) LDAP_REFERRAL_LIMIT_EXCEEDED (0x61) 11. Performing LDAP Operations This section describes each LDAP operation API call in detail. All func- tions take a "session handle," a pointer to an LDAP structure containing per-connection information. Many routines return results in an LDAPMes- sage structure. These structures and others are described as needed below. 11.1. Initializing an LDAP Session ldap_init() initializes a session with an LDAP server. The server is not actually contacted until an operation is performed that requires it, allowing various options to be set after initialization. LDAP *ldap_init( const char *hostname, int portno ); Use of the following routine is deprecated: Expires: 8 April 2000 [Page 15] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 LDAP *ldap_open( const char *hostname, int portno ); Unlike ldap_init(), ldap_open() attempts to make a server connection before returning to the caller. A more complete description can be found in RFC 1823. Parameters are: hostname Contains a space-separated list of hostnames or dotted strings representing the IP address of hosts running an LDAP server to connect to. Each hostname in the list MAY include a port number which is separated from the host itself with a colon (:) char- acter. The hosts will be tried in the order listed, stopping with the first one to which a successful connection is made. Note: A suitable representation for including a literal IPv6[10] address in the hostname parameter is desired, but has not yet been determined or implemented in practice. portno Contains the TCP port number to connect to. The default LDAP port of 389 can be obtained by supplying the constant LDAP_PORT. If a host includes a port number then this parame- ter is ignored. ldap_init() and ldap_open() both return a "session handle," a pointer to an opaque structure that MUST be passed to subsequent calls pertaining to the session. These routines return NULL if the session cannot be ini- tialized in which case the operating system error reporting mechanism can be checked to see why the call failed. Note that if you connect to an LDAPv2 server, one of the LDAP bind calls described below SHOULD be completed before other operations can be per- formed on the session. LDAPv3 does not require that a bind operation be completed before other operations can be performed. The calling program can set various attributes of the session by calling the routines described in the next section. 11.2. LDAP Session Handle Options The LDAP session handle returned by ldap_init() is a pointer to an opaque data type representing an LDAP session. In RFC 1823 this data type was a structure exposed to the caller, and various fields in the structure could be set to control aspects of the session, such as size and time limits on searches. Expires: 8 April 2000 [Page 16] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 In the interest of insulating callers from inevitable changes to this structure, these aspects of the session are now accessed through a pair of accessor functions, described below. ldap_get_option() is used to access the current value of various session-wide parameters. ldap_set_option() is used to set the value of these parameters. Note that some options are READ-ONLY and cannot be set; it is an error to call ldap_set_option() and attempt to set a READ-ONLY option. Note that if automatic referral following is enabled (the default), any connections created during the course of following referrals will inherit the options associated with the session that sent the original request that caused the referrals to be returned. int ldap_get_option( LDAP *ld, int option, void *outvalue ); int ldap_set_option( LDAP *ld, int option, const void *invalue ); #define LDAP_OPT_ON ((void *)1) #define LDAP_OPT_OFF ((void *)0) Parameters are: ld The session handle. If this is NULL, a set of global defaults is accessed. New LDAP session handles created with ldap_init() or ldap_open() inherit their characteristics from these global defaults. option The name of the option being accessed or set. This parameter SHOULD be one of the following constants, which have the indi- cated meanings. After the constant the actual hexadecimal value of the constant is listed in parentheses. LDAP_OPT_API_INFO (0x00) Type for invalue parameter: not applicable (option is READ-ONLY) Type for outvalue parameter: LDAPAPIInfo * Expires: 8 April 2000 [Page 17] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 Description: Used to retrieve some basic information about the LDAP API implementation at execution time. See the section "Retriev- ing Information About the API Implementation" above for more information. This option is READ-ONLY and cannot be set. LDAP_OPT_DEREF (0x02) Type for invalue parameter: int * Type for outvalue parameter: int * Description: Determines how aliases are handled during search. It SHOULD have one of the following values: LDAP_DEREF_NEVER (0x00), LDAP_DEREF_SEARCHING (0x01), LDAP_DEREF_FINDING (0x02), or LDAP_DEREF_ALWAYS (0x03). The LDAP_DEREF_SEARCHING value means aliases are dereferenced during the search but not when locating the base object of the search. The LDAP_DEREF_FINDING value means aliases are dereferenced when locating the base object but not during the search. The default value for this option is LDAP_DEREF_NEVER. LDAP_OPT_SIZELIMIT (0x03) Type for invalue parameter: int * Type for outvalue parameter: int * Description: A limit on the number of entries to return from a search. A value of LDAP_NO_LIMIT (0) means no limit. The default value for this option is LDAP_NO_LIMIT. LDAP_OPT_TIMELIMIT (0x04) Type for invalue parameter: int * Type for outvalue parameter: int * Description: A limit on the number of seconds to spend on a search. A value of LDAP_NO_LIMIT (0) means no limit. This value is passed to the server in the search request only; it does not affect how long the C LDAP API implementation itself will wait locally for search results. The timeout parameter passed to ldap_search_ext_s() or ldap_result() -- both of which are described later in this document -- can be used to specify both a local and server side time limit. The default value for this option is LDAP_NO_LIMIT. Expires: 8 April 2000 [Page 18] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 LDAP_OPT_REFERRALS (0x08) Type for invalue parameter: void * (LDAP_OPT_ON or LDAP_OPT_OFF) Type for outvalue parameter: int * Description: Determines whether the LDAP library automatically follows referrals returned by LDAP servers or not. It MAY be set to one of the constants LDAP_OPT_ON or LDAP_OPT_OFF; any non- NULL pointer value passed to ldap_set_option() enables this option. When reading the current setting using ldap_get_option(), a zero value means OFF and any non-zero value means ON. By default, this option is ON. LDAP_OPT_RESTART (0x09) Type for invalue parameter: void * (LDAP_OPT_ON or LDAP_OPT_OFF) Type for outvalue parameter: int * Description: Determines whether LDAP I/O operations are automatically res- tarted if they abort prematurely. It MAY be set to one of the constants LDAP_OPT_ON or LDAP_OPT_OFF; any non-NULL pointer value passed to ldap_set_option() enables this option. When reading the current setting using ldap_get_option(), a zero value means OFF and any non-zero value means ON. This option is useful if an LDAP I/O operation can be interrupted prema- turely, for example by a timer going off, or other interrupt. By default, this option is OFF. LDAP_OPT_PROTOCOL_VERSION (0x11) Type for invalue parameter: int * Type for outvalue parameter: int * Description: This option indicates the version of the LDAP protocol used when communicating with the primary LDAP server. It SHOULD be one of the constants LDAP_VERSION2 (2) or LDAP_VERSION3 (3). If no version is set the default is LDAP_VERSION2 (2). LDAP_OPT_SERVER_CONTROLS (0x12) Type for invalue parameter: LDAPControl ** Type for outvalue parameter: LDAPControl *** Description: A default list of LDAP server controls to be sent with each Expires: 8 April 2000 [Page 19] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 request. See the Working With Controls section below. LDAP_OPT_CLIENT_CONTROLS (0x13) Type for invalue parameter: LDAPControl ** Type for outvalue parameter: LDAPControl *** Description: A default list of client controls that affect the LDAP ses- sion. See the Working With Controls section below. LDAP_OPT_API_FEATURE_INFO (0x15) Type for invalue parameter: not applicable (option is READ-ONLY) Type for outvalue parameter: LDAPAPIFeatureInfo * Description: Used to retrieve version information about LDAP API extended features at execution time. See the section "Retrieving Information About the API Implementation" above for more information. This option is READ-ONLY and cannot be set. LDAP_OPT_HOST_NAME (0x30) Type for invalue parameter: char * Type for outvalue parameter: char ** Description: The host name (or list of hosts) for the primary LDAP server. See the definition of the hostname parameter to ldap_init() for the allowed syntax. LDAP_OPT_ERROR_NUMBER (0x31) Type for invalue parameter: int * Type for outvalue parameter: int * Description: The code of the most recent LDAP error that occurred for this session. LDAP_OPT_ERROR_STRING (0x32) Type for invalue parameter: char * Type for outvalue parameter: char ** Description: The message returned with the most recent LDAP error that Expires: 8 April 2000 [Page 20] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 occurred for this session. LDAP_OPT_MATCHED_DN (0x33) Type for invalue parameter: char * Type for outvalue parameter: char ** Description: The matched DN value returned with the most recent LDAP error that occurred for this session. outvalue The address of a place to put the value of the option. The actual type of this parameter depends on the setting of the option parameter. For outvalues of type char ** and LDAPCon- trol **, a copy of the data that is associated with the LDAP session ld is returned; callers should dispose of the memory by calling ldap_memfree() or ldap_controls_free(), depending on the type of data returned. invalue A pointer to the value the option is to be given. The actual type of this parameter depends on the setting of the option parameter. The data associated with invalue is copied by the API implementation to allow callers of the API to dispose of or otherwise change their copy of the data after a successful call to ldap_set_option(). If a value passed for invalue is invalid or cannot be accepted by the implementation, ldap_set_option() should return -1 to indicate an error. Both ldap_get_option() and ldap_set_option() return 0 if successful and -1 if an error occurs. If -1 is returned by either function, a specific error code MAY be retrieved by calling ldap_get_option() with an option value of LDAP_OPT_ERROR_NUMBER. Note that there is no way to retrieve a more specific error code if a call to ldap_get_option() with an option value of LDAP_OPT_ERROR_NUMBER fails. When a call to ldap_get_option() succeeds, the API implementation MUST NOT change the state of the LDAP session handle or the state of the underlying implementation in a way that affects the behavior of future LDAP API calls. When a call to ldap_get_option() fails, the only ses- sion handle change permitted is setting the LDAP error code (as returned by the LDAP_OPT_ERROR_NUMBER option). When a call to ldap_set_option() fails, it MUST NOT change the state of the LDAP session handle or the state of the underlying implementation in a way that affects the behavior of future LDAP API calls. Standards track documents that extend this specification and specify new Expires: 8 April 2000 [Page 21] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 options SHOULD use values for option macros that are between 0x1000 and 0x3FFF inclusive. Private and experimental extensions SHOULD use values for the option macros that are between 0x4000 and 0x7FFF inclusive. All values below 0x1000 and above 0x7FFF that are not defined in this docu- ment are reserved and SHOULD NOT be used. The following macro MUST be defined by C LDAP API implementations to aid extension implementors: #define LDAP_OPT_PRIVATE_EXTENSION_BASE 0x4000 /* to 0x7FFF inclusive= */ 11.3. Working With Controls LDAPv3 operations can be extended through the use of controls. Controls can be sent to a server or returned to the client with any LDAP message. These controls are referred to as server controls. The LDAP API also supports a client-side extension mechanism through the use of client controls. These controls affect the behavior of the LDAP API only and are never sent to a server. A common data structure is used to represent both types of controls: typedef struct ldapcontrol { char *ldctl_oid; struct berval ldctl_value; char ldctl_iscritical; } LDAPControl; The fields in the ldapcontrol structure have the following meanings: ldctl_oid The control type, represented as a string. ldctl_value The data associated with the control (if any). To specify a zero-length value, set ldctl_value.bv_len to zero and ldctl_value.bv_val to a zero-length string. To indicate that no data is associated with the con- trol, set ldctl_value.bv_val to NULL. ldctl_iscritical Indicates whether the control is critical of not. If this field is non-zero, the operation will only be car- ried out if the control is recognized by the server and/or client. Note that the LDAP unbind and abandon operations have no server response, so clients SHOULD NOT mark server controls critical when used with these two operations. Some LDAP API calls allocate an ldapcontrol structure or a NULL- terminated array of ldapcontrol structures. The following routines can be used to dispose of a single control or an array of controls: Expires: 8 April 2000 [Page 22] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 void ldap_control_free( LDAPControl *ctrl ); void ldap_controls_free( LDAPControl **ctrls ); If the ctrl or ctrls parameter is NULL, these calls do nothing. A set of controls that affect the entire session can be set using the ldap_set_option() function (see above). A list of controls can also be passed directly to some LDAP API calls such as ldap_search_ext(), in which case any controls set for the session through the use of ldap_set_option() are ignored. Control lists are represented as a NULL- terminated array of pointers to ldapcontrol structures. Server controls are defined by LDAPv3 protocol extension documents; for example, a control has been proposed to support server-side sorting of search results [11]. One client control is defined in this document (described in the follow- ing section). Other client controls MAY be defined in future revisions of this document or in documents that extend this API. 11.3.1. A Client Control That Governs Referral Processing As described previously in the section "LDAP Session Handle Options," applications can enable and disable automatic chasing of referrals on a session-wide basic by using the ldap_set_option() function with the LDAP_OPT_REFERRALS option. It is also useful to govern automatic refer- ral chasing on per-request basis. A client control with an OID of 1.2.840.113556.1.4.616 exists to provide this functionality. /* OID for referrals client control */ #define LDAP_CONTROL_REFERRALS "1.2.840.113556.1.4.616" /* Flags for referrals client control value */ #define LDAP_CHASE_SUBORDINATE_REFERRALS 0x00000020U #define LDAP_CHASE_EXTERNAL_REFERRALS 0x00000040U To create a referrals client control, the ldctl_oid field of an LDAPCon- trol structure MUST be set to LDAP_CONTROL_REFERRALS ("1.2.840.113556.1.4.616") and the ldctl_value field MUST be set to a 4-octet value that contains a set of flags. The ldctl_value.bv_len field MUST always be set to 4. The ldctl_value.bv_val field MUST point to a 4-octet integer flags value. This flags value can be set to zero to disable automatic chasing of referrals and LDAPv3 references alto- gether. Alternatively, the flags value can be set to the value LDAP_CHASE_SUBORDINATE_REFERRALS (0x00000020U) to indicate that only LDAPv3 search continuation references are to be automatically chased by the API implementation, to the value LDAP_CHASE_EXTERNAL_REFERRALS (0x00000040U) to indicate that only LDAPv3 referrals are to be Expires: 8 April 2000 [Page 23] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 automatically chased, or the logical OR of the two flag values (0x00000060U) to indicate that both referrals and references are to be automatically chased. 11.4. Authenticating to the directory The following functions are used to authenticate an LDAP client to an LDAP directory server. The ldap_sasl_bind() and ldap_sasl_bind_s() functions can be used to do general and extensible authentication over LDAP through the use of the Simple Authentication Security Layer [12]. The routines both take the dn to bind as, the method to use, as a dotted-string representation of an OID identifying the method, and a struct berval holding the creden- tials. The special constant value LDAP_SASL_SIMPLE (NULL) can be passed to request simple authentication, or the simplified routines ldap_simple_bind() or ldap_simple_bind_s() can be used. int ldap_sasl_bind( LDAP *ld, const char *dn, const char *mechanism, const struct berval *cred, LDAPControl **serverctrls, LDAPControl **clientctrls, int *msgidp ); int ldap_sasl_bind_s( LDAP *ld, const char *dn, const char *mechanism, const struct berval *cred, LDAPControl **serverctrls, LDAPControl **clientctrls, struct berval **servercredp ); int ldap_simple_bind( LDAP *ld, const char *dn, const char *passwd ); int ldap_simple_bind_s( LDAP *ld, const char *dn, Expires: 8 April 2000 [Page 24] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 const char *passwd ); The use of the following routines is deprecated and more complete descriptions can be found in RFC 1823: int ldap_bind( LDAP *ld, const char *dn, const char *cred, int method ); int ldap_bind_s( LDAP *ld, const char *dn, const char *cred, int method ); int ldap_kerberos_bind( LDAP *ld, const char *dn ); int ldap_kerberos_bind_s( LDAP *ld, const char *dn ); Parameters are: ld The session handle. dn The name of the entry to bind as. mechanism Either LDAP_SASL_SIMPLE (NULL) to get simple authentica- tion, or a text string identifying the SASL method. cred The credentials with which to authenticate. Arbitrary credentials can be passed using this parameter. The format and content of the credentials depends on the setting of the mechanism parameter. passwd For ldap_simple_bind(), the password to compare to the entry's userPassword attribute. serverctrls List of LDAP server controls. clientctrls List of client controls. msgidp This result parameter will be set to the message id of the request if the ldap_sasl_bind() call succeeds. servercredp This result parameter will be filled in with the creden- tials passed back by the server for mutual authentication, if given. An allocated berval structure is returned that SHOULD be disposed of by calling ber_bvfree(). NULL SHOULD be passed to ignore this field. Additional parameters for the deprecated routines are not described. Interested readers are referred to RFC 1823. Expires: 8 April 2000 [Page 25] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 The ldap_sasl_bind() function initiates an asynchronous bind operation and returns the constant LDAP_SUCCESS if the request was successfully sent, or another LDAP error code if not. See the section below on error handling for more information about possible errors and how to interpret them. If successful, ldap_sasl_bind() places the message id of the request in *msgidp. A subsequent call to ldap_result(), described below, can be used to obtain the result of the bind. The ldap_simple_bind() function initiates a simple asynchronous bind operation and returns the message id of the operation initiated. A sub- sequent call to ldap_result(), described below, can be used to obtain the result of the bind. In case of error, ldap_simple_bind() will return -1, setting the session error parameters in the LDAP structure appropri- ately. The synchronous ldap_sasl_bind_s() and ldap_simple_bind_s() functions both return the result of the operation, either the constant LDAP_SUCCESS if the operation was successful, or another LDAP error code if it was not. See the section below on error handling for more informa- tion about possible errors and how to interpret them. Note that if an LDAPv2 server is contacted, no other operations over the connection can be attempted before a bind call has successfully com- pleted. Subsequent bind calls can be used to re-authenticate over the same con- nection, and multistep SASL sequences can be accomplished through a sequence of calls to ldap_sasl_bind() or ldap_sasl_bind_s(). 11.5. Closing the session The following functions are used to unbind from the directory, close open connections, and dispose of the session handle. int ldap_unbind_ext( LDAP *ld, LDAPControl **serverctrls, LDAPControl **clientctrls ); int ldap_unbind( LDAP *ld ); int ldap_unbind_s( LDAP *ld ); Parameters are: ld The session handle. serverctrls List of LDAP server controls. Expires: 8 April 2000 [Page 26] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 clientctrls List of client controls. The ldap_unbind_ext(), ldap_unbind() and ldap_unbind_s() all work syn- chronously in the sense that they send an unbind request to the server, close all open connections associated with the LDAP session handle, and dispose of all resources associated with the session handle before returning. Note, however, that there is no server response to an LDAP unbind operation. All three of the unbind functions return LDAP_SUCCESS (or another LDAP error code if the request cannot be sent to the LDAP server). After a call to one of the unbind functions, the session han- dle ld is invalid and it is illegal to make any further LDAP API calls using ld. The ldap_unbind() and ldap_unbind_s() functions behave identically. The ldap_unbind_ext() function allows server and client controls to be included explicitly, but note that since there is no server response to an unbind request there is no way to receive a response to a server con- trol sent with an unbind request. 11.6. Searching The following functions are used to search the LDAP directory, returning a requested set of attributes for each entry matched. There are five variations. int ldap_search_ext( LDAP *ld, const char *base, int scope, const char *filter, char **attrs, int attrsonly, LDAPControl **serverctrls, LDAPControl **clientctrls, struct timeval *timeout, int sizelimit, int *msgidp ); int ldap_search_ext_s( LDAP *ld, const char *base, int scope, const char *filter, char **attrs, int attrsonly, Expires: 8 April 2000 [Page 27] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 LDAPControl **serverctrls, LDAPControl **clientctrls, struct timeval *timeout, int sizelimit, LDAPMessage **res ); int ldap_search( LDAP *ld, const char *base, int scope, const char *filter, char **attrs, int attrsonly ); int ldap_search_s( LDAP *ld, const char *base, int scope, const char *filter, char **attrs, int attrsonly, LDAPMessage **res ); int ldap_search_st( LDAP *ld, const char *base, int scope, const char *filter, char **attrs, int attrsonly, struct timeval *timeout, LDAPMessage **res ); Parameters are: ld The session handle. base The dn of the entry at which to start the search. scope One of LDAP_SCOPE_BASE (0x00), LDAP_SCOPE_ONELEVEL (0x01), or LDAP_SCOPE_SUBTREE (0x02), indicating the scope of the search. filter A character string as described in [13], representing the Expires: 8 April 2000 [Page 28] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 search filter. The value NULL can be passed to indicate that the filter "(objectclass=3D*)" which matches all entrie= s is to be used. Note that if the caller of the API is using LDAPv2, only a subset of the filter functionality described in [13] can be successfully used. attrs A NULL-terminated array of strings indicating which attri- butes to return for each matching entry. Passing NULL for this parameter causes all available user attributes to be retrieved. The special constant string LDAP_NO_ATTRS ("1.1") MAY be used as the only string in the array to indicate that no attribute types are to be returned by the server. The special constant string LDAP_ALL_USER_ATTRS ("*") can be used in the attrs array along with the names of some operational attributes to indicate that all user attributes plus the listed operational attributes are to be returned. attrsonly A boolean value that MUST be zero if both attribute types and values are to be returned, and non-zero if only types are wanted. timeout For the ldap_search_st() function, this specifies the local search timeout value (if it is NULL, the timeout is infin- ite). If a zero timeout (where tv_sec and tv_usec are both zero) is passed, API implementations SHOULD return LDAP_PARAM_ERROR. For the ldap_search_ext() and ldap_search_ext_s() func- tions, the timeout parameter specifies both the local search timeout value and the operation time limit that is sent to the server within the search request. Passing a NULL value for timeout causes the global default timeout stored in the LDAP session handle (set by using ldap_set_option() with the LDAP_OPT_TIMELIMIT parameter) to be sent to the server with the request but an infinite local search timeout to be used. If a zero timeout (where tv_sec and tv_usec are both zero) is passed in, API imple- mentations SHOULD return LDAP_PARAM_ERROR. If a zero value for tv_sec is used but tv_usec is non-zero, an operation time limit of 1 SHOULD be passed to the LDAP server as the operation time limit. For other values of tv_sec, the tv_sec value itself SHOULD be passed to the LDAP server. sizelimit For the ldap_search_ext() and ldap_search_ext_s() calls, this is a limit on the number of entries to return from the search. A value of LDAP_NO_LIMIT (0) means no limit. Expires: 8 April 2000 [Page 29] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 res For the synchronous calls, this is a result parameter which will contain the results of the search upon completion of the call. If no results are returned, *res is set to NULL. serverctrls List of LDAP server controls. clientctrls List of client controls. msgidp This result parameter will be set to the message id of the request if the ldap_search_ext() call succeeds. There are three options in the session handle ld which potentially affect how the search is performed. They are: LDAP_OPT_SIZELIMIT A limit on the number of entries to return from the search. A value of LDAP_NO_LIMIT (0) means no limit. Note that the value from the session handle is ignored when using the ldap_search_ext() or ldap_search_ext_s() functions. LDAP_OPT_TIMELIMIT A limit on the number of seconds to spend on the search. A value of LDAP_NO_LIMIT (0) means no limit. Note that the value from the session handle is ignored when using the ldap_search_ext() or ldap_search_ext_s() functions. LDAP_OPT_DEREF One of LDAP_DEREF_NEVER (0x00), LDAP_DEREF_SEARCHING (0x01), LDAP_DEREF_FINDING (0x02), or LDAP_DEREF_ALWAYS (0x03), specifying how aliases are handled during the search. The LDAP_DEREF_SEARCHING value means aliases are dereferenced during the search but not when locating the base object of the search. The LDAP_DEREF_FINDING value means aliases are dereferenced when locating the base object but not during the search. The ldap_search_ext() function initiates an asynchronous search opera- tion and returns the constant LDAP_SUCCESS if the request was success- fully sent, or another LDAP error code if not. See the section below on error handling for more information about possible errors and how to interpret them. If successful, ldap_search_ext() places the message id of the request in *msgidp. A subsequent call to ldap_result(), described below, can be used to obtain the results from the search. These results can be parsed using the result parsing routines described in detail later. Similar to ldap_search_ext(), the ldap_search() function initiates an asynchronous search operation and returns the message id of the Expires: 8 April 2000 [Page 30] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 operation initiated. As for ldap_search_ext(), a subsequent call to ldap_result(), described below, can be used to obtain the result of the bind. In case of error, ldap_search() will return -1, setting the ses- sion error parameters in the LDAP structure appropriately. The synchronous ldap_search_ext_s(), ldap_search_s(), and ldap_search_st() functions all return the result of the operation, either the constant LDAP_SUCCESS if the operation was successful, or another LDAP error code if it was not. See the section below on error handling for more information about possible errors and how to interpret them. Entries returned from the search (if any) are contained in the res parameter. This parameter is opaque to the caller. Entries, attri- butes, values, etc., can be extracted by calling the parsing routines described below. The results contained in res SHOULD be freed when no longer in use by calling ldap_msgfree(), described later. The ldap_search_ext() and ldap_search_ext_s() functions support LDAPv3 server controls, client controls, and allow varying size and time limits to be easily specified for each search operation. The ldap_search_st() function is identical to ldap_search_s() except that it takes an addi- tional parameter specifying a local timeout for the search. The local search timeout is used to limit the amount of time the API implementa- tion will wait for a search to complete. After the local search timeout expires, the API implementation will send an abandon operation to abort the search operation. 11.7. Reading an Entry LDAP does not support a read operation directly. Instead, this operation is emulated by a search with base set to the DN of the entry to read, scope set to LDAP_SCOPE_BASE, and filter set to "(objectclass=3D*)" or NULL. attrs contains the list of attributes to return. 11.8. Listing the Children of an Entry LDAP does not support a list operation directly. Instead, this operation is emulated by a search with base set to the DN of the entry to list, scope set to LDAP_SCOPE_ONELEVEL, and filter set to "(objectclass=3D*)" o= r NULL. attrs contains the list of attributes to return for each child entry. 11.9. Comparing a Value Against an Entry The following routines are used to compare a given attribute value assertion against an LDAP entry. There are four variations: int ldap_compare_ext( Expires: 8 April 2000 [Page 31] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 LDAP *ld, const char *dn, const char *attr, const struct berval *bvalue, LDAPControl **serverctrls, LDAPControl **clientctrls, int *msgidp ); int ldap_compare_ext_s( LDAP *ld, const char *dn, const char *attr, const struct berval *bvalue, LDAPControl **serverctrls, LDAPControl **clientctrls ); int ldap_compare( LDAP *ld, const char *dn, const char *attr, const char *value ); int ldap_compare_s( LDAP *ld, const char *dn, const char *attr, const char *value ); Parameters are: ld The session handle. dn The name of the entry to compare against. attr The attribute to compare against. bvalue The attribute value to compare against those found in the given entry. This parameter is used in the extended rou- tines and is a pointer to a struct berval so it is possible to compare binary values. value A string attribute value to compare against, used by the ldap_compare() and ldap_compare_s() functions. Use ldap_compare_ext() or ldap_compare_ext_s() if you need to Expires: 8 April 2000 [Page 32] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 compare binary values. serverctrls List of LDAP server controls. clientctrls List of client controls. msgidp This result parameter will be set to the message id of the request if the ldap_compare_ext() call succeeds. The ldap_compare_ext() function initiates an asynchronous compare opera- tion and returns the constant LDAP_SUCCESS if the request was success- fully sent, or another LDAP error code if not. See the section below on error handling for more information about possible errors and how to interpret them. If successful, ldap_compare_ext() places the message id of the request in *msgidp. A subsequent call to ldap_result(), described below, can be used to obtain the result of the compare. Similar to ldap_compare_ext(), the ldap_compare() function initiates an asynchronous compare operation and returns the message id of the opera- tion initiated. As for ldap_compare_ext(), a subsequent call to ldap_result(), described below, can be used to obtain the result of the bind. In case of error, ldap_compare() will return -1, setting the ses- sion error parameters in the LDAP structure appropriately. The synchronous ldap_compare_ext_s() and ldap_compare_s() functions both return the result of the operation, either the constant LDAP_SUCCESS if the operation was successful, or another LDAP error code if it was not. See the section below on error handling for more information about pos- sible errors and how to interpret them. The ldap_compare_ext() and ldap_compare_ext_s() functions support LDAPv3 server controls and client controls. 11.10. Modifying an entry The following routines are used to modify an existing LDAP entry. There are four variations: typedef struct ldapmod { int mod_op; char *mod_type; union mod_vals_u { char **modv_strvals; struct berval **modv_bvals; } mod_vals; } LDAPMod; #define mod_values mod_vals.modv_strvals Expires: 8 April 2000 [Page 33] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 #define mod_bvalues mod_vals.modv_bvals int ldap_modify_ext( LDAP *ld, const char *dn, LDAPMod **mods, LDAPControl **serverctrls, LDAPControl **clientctrls, int *msgidp ); int ldap_modify_ext_s( LDAP *ld, const char *dn, LDAPMod **mods, LDAPControl **serverctrls, LDAPControl **clientctrls ); int ldap_modify( LDAP *ld, const char *dn, LDAPMod **mods ); int ldap_modify_s( LDAP *ld, const char *dn, LDAPMod **mods ); Parameters are: ld The session handle. dn The name of the entry to modify. mods A NULL-terminated array of modifications to make to the entry. serverctrls List of LDAP server controls. clientctrls List of client controls. msgidp This result parameter will be set to the message id of the request if the ldap_modify_ext() call succeeds. The fields in the LDAPMod structure have the following meanings: Expires: 8 April 2000 [Page 34] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 mod_op The modification operation to perform. It MUST be one of LDAP_MOD_ADD (0x00), LDAP_MOD_DELETE (0x01), or LDAP_MOD_REPLACE (0x02). This field also indicates the type of values included in the mod_vals union. It is logi- cally ORed with LDAP_MOD_BVALUES (0x80) to select the mod_bvalues form. Otherwise, the mod_values form is used. mod_type The type of the attribute to modify. mod_vals The values (if any) to add, delete, or replace. Only one of the mod_values or mod_bvalues variants can be used, selected by ORing the mod_op field with the constant LDAP_MOD_BVALUES. mod_values is a NULL-terminated array of zero-terminated strings and mod_bvalues is a NULL- terminated array of berval structures that can be used to pass binary values such as images. For LDAP_MOD_ADD modifications, the given values are added to the entry, creating the attribute if necessary. For LDAP_MOD_DELETE modifications, the given values are deleted from the entry, removing the attribute if no values remain. If the entire attri- bute is to be deleted, the mod_vals field can be set to NULL. For LDAP_MOD_REPLACE modifications, the attribute will have the listed values after the modification, having been created if necessary, or removed if the mod_vals field is NULL. All modifications are performed in the order in which they are listed. The ldap_modify_ext() function initiates an asynchronous modify opera- tion and returns the constant LDAP_SUCCESS if the request was success- fully sent, or another LDAP error code if not. See the section below on error handling for more information about possible errors and how to interpret them. If successful, ldap_modify_ext() places the message id of the request in *msgidp. A subsequent call to ldap_result(), described below, can be used to obtain the result of the modify. Similar to ldap_modify_ext(), the ldap_modify() function initiates an asynchronous modify operation and returns the message id of the opera- tion initiated. As for ldap_modify_ext(), a subsequent call to ldap_result(), described below, can be used to obtain the result of the modify. In case of error, ldap_modify() will return -1, setting the ses- sion error parameters in the LDAP structure appropriately. The synchronous ldap_modify_ext_s() and ldap_modify_s() functions both return the result of the operation, either the constant LDAP_SUCCESS if the operation was successful, or another LDAP error code if it was not. See the section below on error handling for more information about Expires: 8 April 2000 [Page 35] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 possible errors and how to interpret them. The ldap_modify_ext() and ldap_modify_ext_s() functions support LDAPv3 server controls and client controls. 11.11. Modifying the Name of an Entry In LDAPv2, the ldap_modrdn(), ldap_modrdn_s(), ldap_modrdn2(), and ldap_modrdn2_s() routines were used to change the name of an LDAP entry. They could only be used to change the least significant component of a name (the RDN or relative distinguished name). LDAPv3 provides the Modify DN protocol operation that allows more general name change access. The ldap_rename() and ldap_rename_s() routines are used to change the name of an entry, and the use of the ldap_modrdn(), ldap_modrdn_s(), ldap_modrdn2(), and ldap_modrdn2_s() routines is depre- cated. int ldap_rename( LDAP *ld, const char *dn, const char *newrdn, const char *newparent, int deleteoldrdn, LDAPControl **serverctrls, LDAPControl **clientctrls, int *msgidp ); int ldap_rename_s( LDAP *ld, const char *dn, const char *newrdn, const char *newparent, int deleteoldrdn, LDAPControl **serverctrls, LDAPControl **clientctrls ); The use of the following routines is deprecated and more complete descriptions can be found in RFC 1823: int ldap_modrdn( LDAP *ld, const char *dn, const char *newrdn ); int ldap_modrdn_s( Expires: 8 April 2000 [Page 36] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 LDAP *ld, const char *dn, const char *newrdn ); int ldap_modrdn2( LDAP *ld, const char *dn, const char *newrdn, int deleteoldrdn ); int ldap_modrdn2_s( LDAP *ld, const char *dn, const char *newrdn, int deleteoldrdn ); Parameters are: ld The session handle. dn The name of the entry whose DN is to be changed. newrdn The new RDN to give the entry. newparent The new parent, or superior entry. If this parameter is NULL, only the RDN of the entry is changed. The root DN SHOULD be specified by passing a zero length string, "". The newparent parameter SHOULD always be NULL when using version 2 of the LDAP protocol; otherwise the server's behavior is undefined. deleteoldrdn This parameter only has meaning on the rename routines if newrdn is different than the old RDN. It is a boolean value, if non-zero indicating that the old RDN value(s) is to be removed, if zero indicating that the old RDN value(s) is to be retained as non-distinguished values of the entry. serverctrls List of LDAP server controls. clientctrls List of client controls. msgidp This result parameter will be set to the message id of the request if the ldap_rename() call succeeds. The ldap_rename() function initiates an asynchronous modify DN operation and returns the constant LDAP_SUCCESS if the request was successfully sent, or another LDAP error code if not. See the section below on error Expires: 8 April 2000 [Page 37] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 handling for more information about possible errors and how to interpret them. If successful, ldap_rename() places the DN message id of the request in *msgidp. A subsequent call to ldap_result(), described below, can be used to obtain the result of the rename. The synchronous ldap_rename_s() returns the result of the operation, either the constant LDAP_SUCCESS if the operation was successful, or another LDAP error code if it was not. See the section below on error handling for more information about possible errors and how to interpret them. The ldap_rename() and ldap_rename_s() functions both support LDAPv3 server controls and client controls. 11.12. Adding an entry The following functions are used to add entries to the LDAP directory. There are four variations: int ldap_add_ext( LDAP *ld, const char *dn, LDAPMod **attrs, LDAPControl **serverctrls, LDAPControl **clientctrls, int *msgidp ); int ldap_add_ext_s( LDAP *ld, const char *dn, LDAPMod **attrs, LDAPControl **serverctrls, LDAPControl **clientctrls ); int ldap_add( LDAP *ld, const char *dn, LDAPMod **attrs ); int ldap_add_s( LDAP *ld, const char *dn, LDAPMod **attrs ); Expires: 8 April 2000 [Page 38] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 Parameters are: ld The session handle. dn The name of the entry to add. attrs The entry's attributes, specified using the LDAPMod struc- ture defined for ldap_modify(). The mod_type and mod_vals fields MUST be filled in. The mod_op field is ignored unless ORed with the constant LDAP_MOD_BVALUES, used to select the mod_bvalues case of the mod_vals union. serverctrls List of LDAP server controls. clientctrls List of client controls. msgidp This result parameter will be set to the message id of the request if the ldap_add_ext() call succeeds. Note that the parent of the entry being added must already exist or the parent must be empty (i.e., equal to the root DN) for an add to succeed. The ldap_add_ext() function initiates an asynchronous add operation and returns the constant LDAP_SUCCESS if the request was successfully sent, or another LDAP error code if not. See the section below on error han- dling for more information about possible errors and how to interpret them. If successful, ldap_add_ext() places the message id of the request in *msgidp. A subsequent call to ldap_result(), described below, can be used to obtain the result of the add. Similar to ldap_add_ext(), the ldap_add() function initiates an asyn- chronous add operation and returns the message id of the operation ini- tiated. As for ldap_add_ext(), a subsequent call to ldap_result(), described below, can be used to obtain the result of the add. In case of error, ldap_add() will return -1, setting the session error parameters in the LDAP structure appropriately. The synchronous ldap_add_ext_s() and ldap_add_s() functions both return the result of the operation, either the constant LDAP_SUCCESS if the operation was successful, or another LDAP error code if it was not. See the section below on error handling for more information about possible errors and how to interpret them. The ldap_add_ext() and ldap_add_ext_s() functions support LDAPv3 server controls and client controls. Expires: 8 April 2000 [Page 39] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 11.13. Deleting an entry The following functions are used to delete a leaf entry from the LDAP directory. There are four variations: int ldap_delete_ext( LDAP *ld, const char *dn, LDAPControl **serverctrls, LDAPControl **clientctrls, int *msgidp ); int ldap_delete_ext_s( LDAP *ld, const char *dn, LDAPControl **serverctrls, LDAPControl **clientctrls ); int ldap_delete( LDAP *ld, const char *dn ); int ldap_delete_s( LDAP *ld, const char *dn ); Parameters are: ld The session handle. dn The name of the entry to delete. serverctrls List of LDAP server controls. clientctrls List of client controls. msgidp This result parameter will be set to the message id of the request if the ldap_delete_ext() call succeeds. Note that the entry to delete must be a leaf entry (i.e., it must have no children). Deletion of entire subtrees in a single operation is not supported by LDAP. The ldap_delete_ext() function initiates an asynchronous delete Expires: 8 April 2000 [Page 40] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 operation and returns the constant LDAP_SUCCESS if the request was suc- cessfully sent, or another LDAP error code if not. See the section below on error handling for more information about possible errors and how to interpret them. If successful, ldap_delete_ext() places the mes- sage id of the request in *msgidp. A subsequent call to ldap_result(), described below, can be used to obtain the result of the delete. Similar to ldap_delete_ext(), the ldap_delete() function initiates an asynchronous delete operation and returns the message id of the opera- tion initiated. As for ldap_delete_ext(), a subsequent call to ldap_result(), described below, can be used to obtain the result of the delete. In case of error, ldap_delete() will return -1, setting the ses- sion error parameters in the LDAP structure appropriately. The synchronous ldap_delete_ext_s() and ldap_delete_s() functions both return the result of the operation, either the constant LDAP_SUCCESS if the operation was successful, or another LDAP error code if it was not. See the section below on error handling for more information about pos- sible errors and how to interpret them. The ldap_delete_ext() and ldap_delete_ext_s() functions support LDAPv3 server controls and client controls. 11.14. Extended Operations The ldap_extended_operation() and ldap_extended_operation_s() routines allow extended LDAP operations to be passed to the server, providing a general protocol extensibility mechanism. int ldap_extended_operation( LDAP *ld, const char *requestoid, const struct berval *requestdata, LDAPControl **serverctrls, LDAPControl **clientctrls, int *msgidp ); int ldap_extended_operation_s( LDAP *ld, const char *requestoid, const struct berval *requestdata, LDAPControl **serverctrls, LDAPControl **clientctrls, char **retoidp, struct berval **retdatap ); Expires: 8 April 2000 [Page 41] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 Parameters are: ld The session handle. requestoid The dotted-OID text string naming the request. requestdata The arbitrary data needed by the operation (if NULL, no data is sent to the server). serverctrls List of LDAP server controls. clientctrls List of client controls. msgidp This result parameter will be set to the message id of the request if the ldap_extended_operation() call succeeds. retoidp Pointer to a character string that will be set to an allo- cated, dotted-OID text string returned by the server. This string SHOULD be disposed of using the ldap_memfree() func- tion. If no OID was returned, *retoidp is set to NULL. retdatap Pointer to a berval structure pointer that will be set an allocated copy of the data returned by the server. This struct berval SHOULD be disposed of using ber_bvfree(). If no data is returned, *retdatap is set to NULL. The ldap_extended_operation() function initiates an asynchronous extended operation and returns the constant LDAP_SUCCESS if the request was successfully sent, or another LDAP error code if not. See the sec- tion below on error handling for more information about possible errors and how to interpret them. If successful, ldap_extended_operation() places the message id of the request in *msgidp. A subsequent call to ldap_result(), described below, can be used to obtain the result of the extended operation which can be passed to ldap_parse_extended_result() to obtain the OID and data contained in the response. The synchronous ldap_extended_operation_s() function returns the result of the operation, either the constant LDAP_SUCCESS if the operation was successful, or another LDAP error code if it was not. See the section below on error handling for more information about possible errors and how to interpret them. The retoid and retdata parameters are filled in with the OID and data from the response. If no OID or data was returned, these parameters are set to NULL. The ldap_extended_operation() and ldap_extended_operation_s() functions both support LDAPv3 server controls and client controls. Expires: 8 April 2000 [Page 42] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 12. Abandoning An Operation The following calls are used to abandon an operation in progress: int ldap_abandon_ext( LDAP *ld, int msgid, LDAPControl **serverctrls, LDAPControl **clientctrls ); int ldap_abandon( LDAP *ld, int msgid ); ld The session handle. msgid The message id of the request to be abandoned. serverctrls List of LDAP server controls. clientctrls List of client controls. ldap_abandon_ext() abandons the operation with message id msgid and returns the constant LDAP_SUCCESS if the abandon was successful or another LDAP error code if not. See the section below on error handling for more information about possible errors and how to interpret them. ldap_abandon() is identical to ldap_abandon_ext() except that it does not accept client or server controls and it returns zero if the abandon was successful, -1 otherwise. After a successful call to ldap_abandon() or ldap_abandon_ext(), results with the given message id are never returned from a subsequent call to ldap_result(). There is no server response to LDAP abandon operations. 13. Obtaining Results and Peeking Inside LDAP Messages ldap_result() is used to obtain the result of a previous asynchronously initiated operation. Note that depending on how it is called, ldap_result() can actually return a list or "chain" of result messages. The ldap_result() function only returns messages for a single request, so for all LDAP operations other than search only one result message is expected; that is, the only time the "result chain" can contain more than one message is if results from a search operation are returned. Expires: 8 April 2000 [Page 43] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 Once a chain of messages has been returned to the caller, it is no longer tied in any caller-visible way to the LDAP request that produced it. Therefore, a chain of messages returned by calling ldap_result() or by calling a synchronous search routine will never be affected by subse- quent LDAP API calls (except for ldap_msgfree() which is used to dispose of a chain of messages). ldap_msgfree() frees the result messages (possibly an entire chain of messages) obtained from a previous call to ldap_result() or from a call to a synchronous search routine. ldap_msgtype() returns the type of an LDAP message. ldap_msgid() returns the message ID of an LDAP message. int ldap_result( LDAP *ld, int msgid, int all, struct timeval *timeout, LDAPMessage **res ); int ldap_msgfree( LDAPMessage *res ); int ldap_msgtype( LDAPMessage *res ); int ldap_msgid( LDAPMessage *res ); Parameters are: ld The session handle. msgid The message id of the operation whose results are to be returned, the constant LDAP_RES_UNSOLICITED (0) if an unsoli- cited result is desired, or or the constant LDAP_RES_ANY (-1) if any result is desired. all Specifies how many messages will be retrieved in a single call to ldap_result(). This parameter only has meaning for search results. Pass the constant LDAP_MSG_ONE (0x00) to retrieve one message at a time. Pass LDAP_MSG_ALL (0x01) to request that all results of a search be received before returning all results in a single chain. Pass LDAP_MSG_RECEIVED (0x02) to indicate that all messages retrieved so far are to be returned in the result chain. timeout A timeout specifying how long to wait for results to be returned. A NULL value causes ldap_result() to block until Expires: 8 April 2000 [Page 44] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 results are available. A timeout value of zero seconds speci- fies a polling behavior. res For ldap_result(), a result parameter that will contain the result(s) of the operation. If no results are returned, *res is set to NULL. For ldap_msgfree(), the result chain to be freed, obtained from a previous call to ldap_result(), ldap_search_s(), or ldap_search_st(). If res is NULL, nothing is done and ldap_msgfree() returns zero. Upon successful completion, ldap_result() returns the type of the first result returned in the res parameter. This will be one of the following constants. LDAP_RES_BIND (0x61) LDAP_RES_SEARCH_ENTRY (0x64) LDAP_RES_SEARCH_REFERENCE (0x73) -- new in LDAPv3 LDAP_RES_SEARCH_RESULT (0x65) LDAP_RES_MODIFY (0x67) LDAP_RES_ADD (0x69) LDAP_RES_DELETE (0x6B) LDAP_RES_MODDN (0x6D) LDAP_RES_COMPARE (0x6F) LDAP_RES_EXTENDED (0x78) -- new in LDAPv3 ldap_result() returns 0 if the timeout expired and -1 if an error occurs, in which case the error parameters of the LDAP session handle will be set accordingly. ldap_msgfree() frees each message in the result chain pointed to by res and returns the type of the last message in the chain. If res is NULL, nothing is done and the value zero is returned. ldap_msgtype() returns the type of the LDAP message it is passed as a parameter. The type will be one of the types listed above, or -1 on error. ldap_msgid() returns the message ID associated with the LDAP message passed as a parameter, or -1 on error. 14. Handling Errors and Parsing Results The following calls are used to extract information from results and handle errors returned by other LDAP API routines. Note that ldap_parse_sasl_bind_result() and ldap_parse_extended_result() must typ- ically be used in addition to ldap_parse_result() to retrieve all the result information from SASL Bind and Extended Operations respectively. Expires: 8 April 2000 [Page 45] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 int ldap_parse_result( LDAP *ld, LDAPMessage *res, int *errcodep, char **matcheddnp, char **errmsgp, char ***referralsp, LDAPControl ***serverctrlsp, int freeit ); int ldap_parse_sasl_bind_result( LDAP *ld, LDAPMessage *res, struct berval **servercredp, int freeit ); int ldap_parse_extended_result( LDAP *ld, LDAPMessage *res, char **retoidp, struct berval **retdatap, int freeit ); #define LDAP_NOTICE_OF_DISCONNECTION "1.3.6.1.4.1.1466.2003= 6" char *ldap_err2string( int err ); The use of the following routines is deprecated and more complete descriptions can be found in RFC 1823: int ldap_result2error( LDAP *ld, LDAPMessage *res, int freeit ); void ldap_perror( LDAP *ld, const char *msg ); Parameters are: ld The session handle. res The result of an LDAP operation as returned by ldap_result() or one of the synchronous API operation calls. Expires: 8 April 2000 [Page 46] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 errcodep This result parameter will be filled in with the LDAP error code field from the LDAPMessage message. This is the indi- cation from the server of the outcome of the operation. NULL SHOULD be passed to ignore this field. matcheddnp In the case of a return of LDAP_NO_SUCH_OBJECT, this result parameter will be filled in with a DN indicating how much of the name in the request was recognized. NULL SHOULD be passed to ignore this field. The matched DN string SHOULD be freed by calling ldap_memfree() which is described later in this document. errmsgp This result parameter will be filled in with the contents of the error message field from the LDAPMessage message. The error message string SHOULD be freed by calling ldap_memfree() which is described later in this document. NULL SHOULD be passed to ignore this field. referralsp This result parameter will be filled in with the contents of the referrals field from the LDAPMessage message, indi- cating zero or more alternate LDAP servers where the request is to be retried. The referrals array SHOULD be freed by calling ldap_value_free() which is described later in this document. NULL SHOULD be passed to ignore this field. serverctrlsp This result parameter will be filled in with an allocated array of controls copied out of the LDAPMessage message. The control array SHOULD be freed by calling ldap_controls_free() which was described earlier. freeit A boolean that determines whether the res parameter is disposed of or not. Pass any non-zero value to have these routines free res after extracting the requested informa- tion. This is provided as a convenience; you can also use ldap_msgfree() to free the result later. If freeit is non-zero, the entire chain of messages represented by res is disposed of. servercredp For SASL bind results, this result parameter will be filled in with the credentials passed back by the server for mutual authentication, if given. An allocated berval struc- ture is returned that SHOULD be disposed of by calling ber_bvfree(). NULL SHOULD be passed to ignore this field. retoidp For extended results, this result parameter will be filled in with the dotted-OID text representation of the name of the extended operation response. This string SHOULD be Expires: 8 April 2000 [Page 47] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 disposed of by calling ldap_memfree(). NULL SHOULD be passed to ignore this field. The LDAP_NOTICE_OF_DISCONNECTION macro is defined as a conveni- ence for clients that wish to check an OID to see if it matches the one used for the unsolicited Notice of Discon- nection (defined in RFC 2251[2] section 4.4.1). retdatap For extended results, this result parameter will be filled in with a pointer to a struct berval containing the data in the extended operation response. It SHOULD be disposed of by calling ber_bvfree(). NULL SHOULD be passed to ignore this field. err For ldap_err2string(), an LDAP error code, as returned by ldap_parse_result() or another LDAP API call. Additional parameters for the deprecated routines are not described. Interested readers are referred to RFC 1823. The ldap_parse_result(), ldap_parse_sasl_bind_result(), and ldap_parse_extended_result() functions all skip over messages of type LDAP_RES_SEARCH_ENTRY and LDAP_RES_SEARCH_REFERENCE when looking for a result message to parse. They return the constant LDAP_SUCCESS if the result was successfully parsed and another LDAP error code if not. Note that the LDAP error code that indicates the outcome of the operation performed by the server is placed in the errcodep ldap_parse_result() parameter. If a chain of messages that contains more than one result message is passed to these routines they always operate on the first result in the chain. ldap_err2string() is used to convert a numeric LDAP error code, as returned by ldap_parse_result(), ldap_parse_sasl_bind_result(), ldap_parse_extended_result() or one of the synchronous API operation calls, into an informative zero-terminated character string message describing the error. It returns a pointer to static data. 15. Stepping Through a List of Results The ldap_first_message() and ldap_next_message() routines are used to step through the list of messages in a result chain returned by ldap_result(). For search operations, the result chain can actually include referral messages, entry messages, and result messages. ldap_count_messages() is used to count the number of messages returned. The ldap_msgtype() function, described above, can be used to distinguish between the different message types. LDAPMessage *ldap_first_message( LDAP *ld, LDAPMessage *res );= Expires: 8 April 2000 [Page 48] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 LDAPMessage *ldap_next_message( LDAP *ld, LDAPMessage *msg ); int ldap_count_messages( LDAP *ld, LDAPMessage *res ); Parameters are: ld The session handle. res The result chain, as obtained by a call to one of the synchronous search routines or ldap_result(). msg The message returned by a previous call to ldap_first_message() or ldap_next_message(). ldap_first_message() and ldap_next_message() will return NULL when no more messages exist in the result set to be returned. NULL is also returned if an error occurs while stepping through the entries, in which case the error parameters in the session handle ld will be set to indi- cate the error. If successful, ldap_count_messages() returns the number of messages con- tained in a chain of results; if an error occurs such as the res parame- ter being invalid, -1 is returned. The ldap_count_messages() call can also be used to count the number of messages that remain in a chain if called with a message, entry, or reference returned by ldap_first_message(), ldap_next_message(), ldap_first_entry(), ldap_next_entry(), ldap_first_reference(), ldap_next_reference(). 16. Parsing Search Results The following calls are used to parse the entries and references returned by ldap_search() and friends. These results are returned in an opaque structure that MAY be accessed by calling the routines described below. Routines are provided to step through the entries and references returned, step through the attributes of an entry, retrieve the name of an entry, and retrieve the values associated with a given attribute in an entry. 16.1. Stepping Through a List of Entries or References The ldap_first_entry() and ldap_next_entry() routines are used to step through and retrieve the list of entries from a search result chain. The ldap_first_reference() and ldap_next_reference() routines are used to step through and retrieve the list of continuation references from a search result chain. ldap_count_entries() is used to count the number of entries returned. ldap_count_references() is used to count the number Expires: 8 April 2000 [Page 49] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 of references returned. LDAPMessage *ldap_first_entry( LDAP *ld, LDAPMessage *res ); LDAPMessage *ldap_next_entry( LDAP *ld, LDAPMessage *entry ); LDAPMessage *ldap_first_reference( LDAP *ld, LDAPMessage *res = ); LDAPMessage *ldap_next_reference( LDAP *ld, LDAPMessage *ref )= ; int ldap_count_entries( LDAP *ld, LDAPMessage *res ); int ldap_count_references( LDAP *ld, LDAPMessage *res ); Parameters are: ld The session handle. res The search result, as obtained by a call to one of the synchro- nous search routines or ldap_result(). entry The entry returned by a previous call to ldap_first_entry() or ldap_next_entry(). ref The reference returned by a previous call to ldap_first_reference() or ldap_next_reference(). ldap_first_entry(), ldap_next_entry(), ldap_first_reference() and ldap_next_reference() all return NULL when no more entries or references exist in the result set to be returned. NULL is also returned if an error occurs while stepping through the entries or references, in which case the error parameters in the session handle ld will be set to indi- cate the error. ldap_count_entries() returns the number of entries contained in a chain of entries; if an error occurs such as the res parameter being invalid, -1 is returned. The ldap_count_entries() call can also be used to count the number of entries that remain in a chain if called with a message, entry or reference returned by ldap_first_message(), ldap_next_message(), ldap_first_entry(), ldap_next_entry(), ldap_first_reference(), ldap_next_reference(). ldap_count_references() returns the number of references contained in a chain of search results; if an error occurs such as the res parameter being invalid, -1 is returned. The ldap_count_references() call can also be used to count the number of references that remain in a chain. Expires: 8 April 2000 [Page 50] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 16.2. Stepping Through the Attributes of an Entry The ldap_first_attribute() and ldap_next_attribute() calls are used to step through the list of attribute types returned with an entry. char *ldap_first_attribute( LDAP *ld, LDAPMessage *entry, BerElement **ptr ); char *ldap_next_attribute( LDAP *ld, LDAPMessage *entry, BerElement *ptr ); void ldap_memfree( char *mem ); Parameters are: ld The session handle. entry The entry whose attributes are to be stepped through, as returned by ldap_first_entry() or ldap_next_entry(). ptr In ldap_first_attribute(), the address of a pointer used inter- nally to keep track of the current position in the entry. In ldap_next_attribute(), the pointer returned by a previous call to ldap_first_attribute(). The BerElement type itself is an opaque structure that is described in more detail later in this document in the section "Encoded ASN.1 Value Manipulation". mem A pointer to memory allocated by the LDAP library, such as the attribute type names returned by ldap_first_attribute() and ldap_next_attribute, or the DN returned by ldap_get_dn(). If mem is NULL, the ldap_memfree() call does nothing. ldap_first_attribute() and ldap_next_attribute() will return NULL when the end of the attributes is reached, or if there is an error, in which case the error parameters in the session handle ld will be set to indi- cate the error. Both routines return a pointer to an allocated buffer containing the current attribute name. This SHOULD be freed when no longer in use by calling ldap_memfree(). ldap_first_attribute() will allocate and return in ptr a pointer to a Expires: 8 April 2000 [Page 51] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 BerElement used to keep track of the current position. This pointer MAY be passed in subsequent calls to ldap_next_attribute() to step through the entry's attributes. After a set of calls to ldap_first_attribute() and ldap_next_attribute(), if ptr is non-NULL, it SHOULD be freed by calling ber_free( ptr, 0 ). Note that it is very important to pass the second parameter as 0 (zero) in this call, since the buffer associated with the BerElement does not point to separately allocated memory. The attribute type names returned are suitable for passing in a call to ldap_get_values() and friends to retrieve the associated values. 16.3. Retrieving the Values of an Attribute ldap_get_values() and ldap_get_values_len() are used to retrieve the values of a given attribute from an entry. ldap_count_values() and ldap_count_values_len() are used to count the returned values. ldap_value_free() and ldap_value_free_len() are used to free the values. char **ldap_get_values( LDAP *ld, LDAPMessage *entry, const char *attr ); struct berval **ldap_get_values_len( LDAP *ld, LDAPMessage *entry, const char *attr ); int ldap_count_values( char **vals ); int ldap_count_values_len( struct berval **vals ); void ldap_value_free( char **vals ); void ldap_value_free_len( struct berval **vals ); Parameters are: ld The session handle. entry The entry from which to retrieve values, as returned by ldap_first_entry() or ldap_next_entry(). attr The attribute whose values are to be retrieved, as returned by ldap_first_attribute() or ldap_next_attribute(), or a caller- Expires: 8 April 2000 [Page 52] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 supplied string (e.g., "mail"). vals The values returned by a previous call to ldap_get_values() or ldap_get_values_len(). Two forms of the various calls are provided. The first form is only suitable for use with non-binary character string data. The second _len form is used with any kind of data. ldap_get_values() and ldap_get_values_len() return NULL if no values are found for attr or if an error occurs. ldap_count_values() and ldap_count_values_len() return -1 if an error occurs such as the vals parameter being invalid. If a NULL vals parameter is passed to ldap_value_free() or ldap_value_free_len(), nothing is done. Note that the values returned are dynamically allocated and SHOULD be freed by calling either ldap_value_free() or ldap_value_free_len() when no longer in use. 16.4. Retrieving the name of an entry ldap_get_dn() is used to retrieve the name of an entry. ldap_explode_dn() and ldap_explode_rdn() are used to break up a name into its component parts. ldap_dn2ufn() is used to convert the name into a more "user friendly" format. char *ldap_get_dn( LDAP *ld, LDAPMessage *entry ); char **ldap_explode_dn( const char *dn, int notypes ); char **ldap_explode_rdn( const char *rdn, int notypes ); char *ldap_dn2ufn( const char *dn ); Parameters are: ld The session handle. entry The entry whose name is to be retrieved, as returned by ldap_first_entry() or ldap_next_entry(). dn The dn to explode, such as returned by ldap_get_dn(). rdn The rdn to explode, such as returned in the components of the Expires: 8 April 2000 [Page 53] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 array returned by ldap_explode_dn(). notypes A boolean parameter, if non-zero indicating that the dn or rdn components are to have their type information stripped off (i.e., "cn=3DBabs" would become "Babs"). ldap_get_dn() will return NULL if there is some error parsing the dn, setting error parameters in the session handle ld to indicate the error. It returns a pointer to newly allocated space that the caller SHOULD free by calling ldap_memfree() when it is no longer in use. Note the format of the DNs returned is given by [5]. ldap_explode_dn() returns a NULL-terminated char * array containing the RDN components of the DN supplied, with or without types as indicated by the notypes parameter. The components are returned in the order they appear in the dn. The array returned SHOULD be freed when it is no longer in use by calling ldap_value_free(). ldap_explode_rdn() returns a NULL-terminated char * array containing the components of the RDN supplied, with or without types as indicated by the notypes parameter. The components are returned in the order they appear in the rdn. The array returned SHOULD be freed when it is no longer in use by calling ldap_value_free(). ldap_dn2ufn() converts the DN into the user friendly format described in [14]. The UFN returned is newly allocated space that SHOULD be freed by a call to ldap_memfree() when no longer in use. 16.5. Retrieving controls from an entry ldap_get_entry_controls() is used to extract LDAP controls from an entry. int ldap_get_entry_controls( LDAP *ld, LDAPMessage *entry, LDAPControl ***serverctrlsp ); Parameters are: ld The session handle. entry The entry to extract controls from, as returned by ldap_first_entry() or ldap_next_entry(). Expires: 8 April 2000 [Page 54] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 serverctrlsp This result parameter will be filled in with an allocated array of controls copied out of entry. The control array SHOULD be freed by calling ldap_controls_free(). If ser- verctrlsp is NULL, no controls are returned. ldap_get_entry_controls() returns an LDAP error code that indicates whether the reference could be successfully parsed (LDAP_SUCCESS if all goes well). 16.6. Parsing References ldap_parse_reference() is used to extract referrals and controls from a SearchResultReference message. int ldap_parse_reference( LDAP *ld, LDAPMessage *ref, char ***referralsp, LDAPControl ***serverctrlsp, int freeit ); Parameters are: ld The session handle. ref The reference to parse, as returned by ldap_result(), ldap_first_reference(), or ldap_next_reference(). referralsp This result parameter will be filled in with an allocated array of character strings. The elements of the array are the referrals (typically LDAP URLs) contained in ref. The array SHOULD be freed when no longer in used by calling ldap_value_free(). If referralsp is NULL, the referral URLs are not returned. serverctrlsp This result parameter will be filled in with an allocated array of controls copied out of ref. The control array SHOULD be freed by calling ldap_controls_free(). If ser- verctrlsp is NULL, no controls are returned. freeit A boolean that determines whether the ref parameter is disposed of or not. Pass any non-zero value to have this routine free ref after extracting the requested informa- tion. This is provided as a convenience; you can also use Expires: 8 April 2000 [Page 55] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 ldap_msgfree() to free the result later. ldap_parse_reference() returns an LDAP error code that indicates whether the reference could be successfully parsed (LDAP_SUCCESS if all goes well). 17. Encoded ASN.1 Value Manipulation This section describes routines which MAY be used to encode and decode BER-encoded ASN.1 values, which are often used inside of control and extension values. With the exceptions of two new functions ber_flatten() and ber_init(), these functions are compatible with the University of Michigan LDAP 3.3 implementation of BER. Note that the functions defined in this section all provide a method for determining success or failure but generally do not provide access to specific error codes. Therefore, applications that require precise error information when encoding or decoding ASN.1 values SHOULD NOT use these functions. 17.1. BER Data Structures and Types The following additional integral types are defined for use in manipula- tion of BER encoded ASN.1 values: typedef impl_tag_t ber_tag_t; /* for BER tags */ typedef impl_int_t ber_int_t; /* for BER ints, enums, and Bo= oleans */ typedef impl_unit_t ber_uint_t; /* unsigned equivalent of ber_= int_t */ typedef impl_slen_t ber_slen_t; /* signed equivalent of ber_le= n_t */ Note that the actual definition for these four integral types is imple- mentation specific; that is, `impl_tag_t', `impl_int_t', `impl_uint_t', and `impl_slen_t' MUST each be replaced with an appropriate implementation-specific type. The `ber_tag_t' type is an unsigned integral data type that is large enough to hold the largest BER tag supported by the API implementation. The width (number of significant bits) of `ber_tag_t' MUST be at least 32, greater than or equal to that of `unsigned int' (so that integer promotions won't promote it to `int'), and no wider than that of `unsigned long'. Expires: 8 April 2000 [Page 56] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 The `ber_int_t' and `ber_uint_t' types are the signed and unsigned vari- ants of an integral type that is large enough to hold integers for pur- poses of BER encoding and decoding. The width of `ber_int_t' MUST be at least 32 and no larger than that of `long'. The width (number of signi- ficant bits) of `ber_uint_t' MUST be at least 32 and no larger than that of `unsigned long'. Note that the `ber_uint_t' type is not used directly in the C LDAP API but is provided for the convenience of appli- cation developers and for use by extensions to the API. The `ber_slen_t' type is the signed variant of the `ber_len_t' integral type that is large enough to contain the length of the largest piece of data supported by the API implementation. The `impl_slen_t' in the `ber_len_t' typedef MUST be replaced with an appropriate type. The width of `ber_slen_t' MUST be at least 32 and no larger than that of `unsigned long'. Note that `ber_slen_t' is not used directly in the C LDAP API but is provided for the convenience of application developers and for use by extensions to the API. typedef struct berval { ber_len_t bv_len; char *bv_val; } BerValue; As defined earlier in the section "Common Data Structures", a berval structure contains an arbitrary sequence of bytes and an indication of its length. The bv_len element is an unsigned integer. The bv_val is not necessarily zero-terminated. Applications MAY allocate their own berval structures. As defined earlier in the section "Common Data Structures", the BerEle- ment structure is an opaque structure: typedef struct berelement BerElement; It contains not only a copy of the encoded value, but also state infor- mation used in encoding or decoding. Applications cannot allocate their own BerElement structures. The internal state is neither thread- specific nor locked, so two threads SHOULD NOT manipulate the same BerElement value simultaneously. A single BerElement value cannot be used for both encoding and decoding. 17.2. Memory Disposal and Utility Functions void ber_bvfree( struct berval *bv ); ber_bvfree() frees a berval structure returned from this API. Both the bv->bv_val string and the berval structure itself are freed. If bv is Expires: 8 April 2000 [Page 57] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 NULL, this call does nothing. void ber_bvecfree( struct berval **bv ); ber_bvecfree() frees an array of berval structures returned from this API. Each of the berval structures in the array are freed using ber_bvfree(), then the array itself is freed. If bv is NULL, this call does nothing. struct berval *ber_bvdup( const struct berval *bv ); ber_bvdup() returns a copy of a berval structure. The bv_val field in the returned berval structure points to a different area of memory than the bv_val field in the bv argument. The NULL pointer is returned on error (e.g. out of memory). void ber_free( BerElement *ber, int fbuf ); ber_free() frees a BerElement which is returned from the API calls ber_alloc_t() or ber_init(). Each BerElement SHOULD be freed by the caller. The second argument fbuf SHOULD always be set to 1 to ensure that the internal buffer used by the BER functions is freed as well as the BerElement container itself. If ber is NULL, this call does noth- ing. 17.3. Encoding BerElement *ber_alloc_t( int options ); ber_alloc_t() constructs and returns BerElement. The NULL pointer is returned on error. The options field contains a bitwise-or of options which are to be used when generating the encoding of this BerElement. One option is defined and SHOULD always be supplied: #define LBER_USE_DER 0x01 When this option is present, lengths will always be encoded in the minimum number of octets. Note that this option does not cause values of sets to be rearranged in tag and byte order or default values to be removed, so these functions are not sufficient for generating DER output as defined in X.509 and X.680. If the caller takes responsibility for ordering values of sets correctly and removing default values, DER out- put as defined in X.509 and X.680 can be produced. Unrecognized option bits are ignored. The BerElement returned by ber_alloc_t() is initially empty. Calls to Expires: 8 April 2000 [Page 58] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 ber_printf() will append bytes to the end of the ber_alloc_t(). int ber_printf( BerElement *ber, const char *fmt, ... ) The ber_printf() routine is used to encode a BER element in much the same way that sprintf() works. One important difference, though, is that state information is kept in the ber argument so that multiple calls can be made to ber_printf() to append to the end of the BER ele- ment. ber MUST be a pointer to a BerElement returned by ber_alloc_t(). ber_printf() interprets and formats its arguments according to the for- mat string fmt. ber_printf() returns -1 if there is an error during encoding and a non-negative number if successful. As with sprintf(), each character in fmt refers to an argument to ber_printf(). The format string can contain the following format characters: 't' Tag. The next argument is a ber_tag_t specifying the tag to override the next element to be written to the ber. This works across calls. The integer tag value SHOULD contain the tag class, constructed bit, and tag value. For example, a tag of "[3]" for a constructed type is 0xA3U. All implementations MUST support tags that fit in a single octet (i.e., where the tag value is less than 32) and they MAY support larger tags. 'b' Boolean. The next argument is an ber_int_t, containing either 0 for FALSE or 0xff for TRUE. A boolean element is output. If this format character is not preceded by the 't' format modif- ier, the tag 0x01U is used for the element. 'e' Enumerated. The next argument is a ber_int_t, containing the enumerated value in the host's byte order. An enumerated ele- ment is output. If this format character is not preceded by the 't' format modifier, the tag 0x0AU is used for the element. 'i' Integer. The next argument is a ber_int_t, containing the integer in the host's byte order. An integer element is output. If this format character is not preceded by the 't' format modifier, the tag 0x02U is used for the element. 'B' Bitstring. The next two arguments are a char * pointer to the start of the bitstring, followed by a ber_len_t containing the number of bits in the bitstring. A bitstring element is output, in primitive form. If this format character is not preceded by the 't' format modifier, the tag 0x03U is used for the element. 'n' Null. No argument is needed. An ASN.1 NULL element is output. If this format character is not preceded by the 't' format modifier, the tag 0x05U is used for the element. Expires: 8 April 2000 [Page 59] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 'o' Octet string. The next two arguments are a char *, followed by a ber_len_t with the length of the string. The string MAY con- tain null bytes and are do not have to be zero-terminated. An octet string element is output, in primitive form. If this for- mat character is not preceded by the 't' format modifier, the tag 0x04U is used for the element. 's' Octet string. The next argument is a char * pointing to a zero-terminated string. An octet string element in primitive form is output, which does not include the trailing '\0' (null) byte. If this format character is not preceded by the 't' format modifier, the tag 0x04U is used for the element. 'v' Several octet strings. The next argument is a char **, an array of char * pointers to zero-terminated strings. The last element in the array MUST be a NULL pointer. The octet strings do not include the trailing '\0' (null) byte. Note that a construct like '{v}' is used to get an actual SEQUENCE OF octet strings. The 't' format modifier cannot be used with this format charac- ter. 'V' Several octet strings. A NULL-terminated array of struct berval *'s is supplied. Note that a construct like '{V}' is used to get an actual SEQUENCE OF octet strings. The 't' format modifier cannot be used with this format character. '{' Begin sequence. No argument is needed. If this format charac- ter is not preceded by the 't' format modifier, the tag 0x30U is used. '}' End sequence. No argument is needed. The 't' format modifier cannot be used with this format character. '[' Begin set. No argument is needed. If this format character is not preceded by the 't' format modifier, the tag 0x31U is used. ']' End set. No argument is needed. The 't' format modifier cannot be used with this format character. Each use of a '{' format character SHOULD be matched by a '}' character, either later in the format string, or in the format string of a subse- quent call to ber_printf() for that BerElement. The same applies to the '[' and ']' format characters. Sequences and sets nest, and implementations of this API MUST maintain internal state to be able to properly calculate the lengths. int ber_flatten( BerElement *ber, struct berval **bvPtr ); Expires: 8 April 2000 [Page 60] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 The ber_flatten routine allocates a struct berval whose contents are a BER encoding taken from the ber argument. The bvPtr pointer points to the returned berval structure, which SHOULD be freed using ber_bvfree(). This routine returns 0 on success and -1 on error. The ber_flatten API call is not present in U-M LDAP 3.3. The use of ber_flatten on a BerElement in which all '{' and '}' format modifiers have not been properly matched is an error (i.e., -1 will be returned by ber_flatten() if this situation is exists). 17.4. Encoding Example The following is an example of encoding the following ASN.1 data type: Example1Request ::=3D SEQUENCE { s OCTET STRING, -- must be printable val1 INTEGER, val2 [0] INTEGER DEFAULT 0 } int encode_example1(const char *s, ber_int_t val1, ber_int_t val2, struct berval **bvPtr) { BerElement *ber; int rc =3D -1; ber =3D ber_alloc_t(LBER_USE_DER); if (ber =3D=3D NULL) return -1; if (ber_printf(ber,"{si",s,val1) =3D=3D -1) { goto done; } if (val2 !=3D 0) { if (ber_printf(ber,"ti",(ber_tag_t)0x80,val2) =3D=3D -= 1) { goto done; } } if (ber_printf(ber,"}") =3D=3D -1) { goto done; } rc =3D ber_flatten(ber,bvPtr); Expires: 8 April 2000 [Page 61] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 done: ber_free(ber,1); return rc; } 17.5. Decoding The following two macros are available to applications: LBER_ERROR and LBER_DEFAULT. Both of these macros MUST be #define'd as integer con- stants that are both compatible with the ber_tag_t type and for which all bits have the value one. For example, ISO C guarantees that these definitions will work: #define LBER_ERROR ((ber_tag_t)-1) #define LBER_DEFAULT ((ber_tag_t)-1) The intent is that LBER_ERROR and LBER_DEFAULT are both defined as the integer value that has all bits set to 1, as such a value is not a valid BER tag. BerElement *ber_init( const struct berval *bv ); The ber_init function constructs a BerElement and returns a new BerEle- ment containing a copy of the data in the bv argument. ber_init returns the NULL pointer on error. ber_tag_t ber_scanf( BerElement *ber, const char *fmt, ... ); The ber_scanf() routine is used to decode a BER element in much the same way that sscanf() works. One important difference, though, is that some state information is kept with the ber argument so that multiple calls can be made to ber_scanf() to sequentially read from the BER element. The ber argument SHOULD be a pointer to a BerElement returned by ber_init(). ber_scanf interprets the bytes according to the format string fmt, and stores the results in its additional arguments. ber_scanf() returns LBER_ERROR on error, and a different value on suc- cess. The format string contains conversion specifications which are used to direct the interpretation of the BER element. The format string can contain the following characters: 'a' Octet string. A char ** argument MUST be supplied. Memory is allocated, filled with the contents of the octet string, zero- terminated, and the pointer to the string is stored in the argu- ment. The returned value SHOULD be freed using ldap_memfree. The tag of the element MUST indicate the primitive form Expires: 8 April 2000 [Page 62] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 (constructed strings are not supported) but is otherwise ignored and discarded during the decoding. This format cannot be used with octet strings which could contain null bytes. 'O' Octet string. A struct berval ** argument MUST be supplied, which upon return points to an allocated struct berval contain- ing the octet string and its length. ber_bvfree() SHOULD be called to free the allocated memory. The tag of the element MUST indicate the primitive form (constructed strings are not supported) but is otherwise ignored during the decoding. 'b' Boolean. A pointer to a ber_int_t MUST be supplied. The ber_int_t value stored will be 0 for FALSE or nonzero for TRUE. The tag of the element MUST indicate the primitive form but is otherwise ignored during the decoding. 'e' Enumerated. A pointer to a ber_int_t MUST be supplied. The enumerated value stored will be in host byte order. The tag of the element MUST indicate the primitive form but is otherwise ignored during the decoding. ber_scanf() will return an error if the value of the enumerated value cannot be stored in a ber_int_t. 'i' Integer. A pointer to a ber_int_t MUST be supplied. The ber_int_t value stored will be in host byte order. The tag of the element MUST indicate the primitive form but is otherwise ignored during the decoding. ber_scanf() will return an error if the integer cannot be stored in a ber_int_t. 'B' Bitstring. A char ** argument MUST be supplied which will point to the allocated bits, followed by a ber_len_t * argument, which will point to the length (in bits) of the bitstring returned. ldap_memfree SHOULD be called to free the bitstring. The tag of the element MUST indicate the primitive form (constructed bit- strings are not supported) but is otherwise ignored during the decoding. 'n' Null. No argument is needed. The element is verified to have a zero-length value and is skipped. The tag is ignored. 't' Tag. A pointer to a ber_tag_t MUST be supplied. The ber_tag_t value stored will be the tag of the next element in the BerEle- ment ber, represented so it can be written using the 't' format of ber_printf(). The decoding position within the ber argument is unchanged by this; that is, the fact that the tag has been retrieved does not affect future use of ber. 'v' Several octet strings. A char *** argument MUST be supplied, Expires: 8 April 2000 [Page 63] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 which upon return points to an allocated NULL-terminated array of char *'s containing the octet strings. NULL is stored if the sequence is empty. ldap_memfree SHOULD be called to free each element of the array and the array itself. The tag of the sequence and of the octet strings are ignored. 'V' Several octet strings (which could contain null bytes). A struct berval *** MUST be supplied, which upon return points to a allocated NULL-terminated array of struct berval *'s contain- ing the octet strings and their lengths. NULL is stored if the sequence is empty. ber_bvecfree() can be called to free the allocated memory. The tag of the sequence and of the octet strings are ignored. 'x' Skip element. The next element is skipped. No argument is needed. '{' Begin sequence. No argument is needed. The initial sequence tag and length are skipped. '}' End sequence. No argument is needed. '[' Begin set. No argument is needed. The initial set tag and length are skipped. ']' End set. No argument is needed. ber_tag_t ber_peek_tag( BerElement *ber, ber_len_t *lenPtr ); ber_peek_tag() returns the tag of the next element to be parsed in the BerElement argument. The length of this element is stored in the *lenPtr argument. LBER_DEFAULT is returned if there is no further data to be read. The decoding position within the ber argument is unchanged by this call; that is, the fact that ber_peek_tag() has been called does not affect future use of ber. ber_tag_t ber_skip_tag( BerElement *ber, ber_len_t *lenPtr ); ber_skip_tag() is similar to ber_peek_tag(), except that the state pointer in the BerElement argument is advanced past the first tag and length, and is pointed to the value part of the next element. This rou- tine SHOULD only be used with constructed types and situations when a BER encoding is used as the value of an OCTET STRING. The length of the value is stored in *lenPtr. ber_tag_t ber_first_element( BerElement *ber, ber_len_t *lenPtr, char **opaquePtr ); Expires: 8 April 2000 [Page 64] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 ber_tag_t ber_next_element( BerElement *ber, ber_len_t *lenPtr, char *opaque ); ber_first_element() and ber_next_element() are used to traverse a SET, SET OF, SEQUENCE or SEQUENCE OF data value. ber_first_element() calls ber_skip_tag(), stores internal information in *lenPtr and *opaquePtr, and calls ber_peek_tag() for the first element inside the constructed value. LBER_DEFAULT is returned if the constructed value is empty. ber_next_element() positions the state at the start of the next element in the constructed type. LBER_DEFAULT is returned if there are no further values. The len and opaque values SHOULD NOT be used by applications other than as arguments to ber_next_element(), as shown in the example below. 17.6. Decoding Example The following is an example of decoding an ASN.1 data type: Example2Request ::=3D SEQUENCE { dn OCTET STRING, -- must be printable scope ENUMERATED { b (0), s (1), w (2) }, ali ENUMERATED { n (0), s (1), f (2), a (3) }, size INTEGER, time INTEGER, tonly BOOLEAN, attrs SEQUENCE OF OCTET STRING, -- must be printable [0] SEQUENCE OF SEQUENCE { type OCTET STRING -- must be printable, crit BOOLEAN DEFAULT FALSE, value OCTET STRING } OPTIONAL } #define TAG_CONTROL_LIST 0xA0U /* context specific cons 0 */ int decode_example2(struct berval *bv) { BerElement *ber; ber_len_t len; ber_tag_t res; ber_int_t scope, ali, size, time, tonly; char *dn =3D NULL, **attrs =3D NULL; int i,rc =3D 0; ber =3D ber_init(bv); if (ber =3D=3D NULL) { fputs("ERROR ber_init failed\n", stderr); Expires: 8 April 2000 [Page 65] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 return -1; } res =3D ber_scanf(ber,"{aiiiib{v}",&dn,&scope,&ali, &size,&time,&tonly,&attrs); if (res =3D=3D LBER_ERROR) { fputs("ERROR ber_scanf failed\n", stderr); ber_free(ber,1); return -1; } /* *** use dn */ ldap_memfree(dn); for (i =3D 0; attrs !=3D NULL && attrs[i] !=3D NULL; i++) { /* *** use attrs[i] */ ldap_memfree(attrs[i]); } ldap_memfree(attrs); if (ber_peek_tag(ber,&len) =3D=3D TAG_CONTROL_LIST) { char *opaque; ber_tag_t tag; for (tag =3D ber_first_element(ber,&len,&opaque); tag !=3D LBER_DEFAULT; tag =3D ber_next_element (ber,&len,opaque)) { ber_len_t tlen; ber_tag_t ttag; char *type; ber_int_t crit; struct berval *value; if (ber_scanf(ber,"{a",&type) =3D=3D LBER_ERRO= R) { fputs("ERROR cannot parse type\n", std= err); break; } /* *** use type */ ldap_memfree(type); ttag =3D ber_peek_tag(ber,&tlen); if (ttag =3D=3D 0x01U) { /* boolean */ if (ber_scanf(ber,"b", &crit) =3D=3D LBER_ERROR= ) { fputs("ERROR cannot parse crit= \n", stderr); Expires: 8 April 2000 [Page 66] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 rc =3D -1; break; } } else if (ttag =3D=3D 0x04U) { /* octet strin= g */ crit =3D 0; } else { fputs("ERROR extra field in controls\n= ", stderr ); break; } if (ber_scanf(ber,"O}",&value) =3D=3D LBER_ERR= OR) { fputs("ERROR cannot parse value\n", st= derr); rc =3D -1; break; } /* *** use value */ ber_bvfree(value); } } if ( rc =3D=3D 0 ) { /* no errors so far */ if (ber_scanf(ber,"}") =3D=3D LBER_ERROR) { rc =3D -1; } } ber_free(ber,1); return rc; } 18. Security Considerations LDAPv2 supports security through protocol-level authentication using clear-text passwords. LDAPv3 adds support for SASL [12] (Simple Authen- tication Security Layer) methods. LDAPv3 also supports operation over a secure transport layer using Transport Layer Security TLS [9]. Readers are referred to the protocol documents for discussion of related secu- rity considerations. Implementations of this API SHOULD be cautious when handling authentica- tion credentials. In particular, keeping long-lived copies of creden- tials without the application's knowledge is discouraged. Expires: 8 April 2000 [Page 67] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 19. Acknowledgements Many members of the IETF ASID and LDAPEXT working groups as well as members of the Internet at large have provided useful comments and suggestions that have been incorporated into this document. Chris Weider deserves special mention for his contributions as co-author of earlier revisions of this document. The original material upon which this specification is based was sup- ported by the National Science Foundation under Grant No. NCR-9416667. 20. Copyright Copyright (C) The Internet Society (1997-1999). All Rights Reserved. This document and translations of it may be copied and furnished to oth- ers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and dis- tributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Stan- dards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 FIT- NESS FOR A PARTICULAR PURPOSE. 21. Bibliography [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. Expires: 8 April 2000 [Page 68] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 [3] M. Wahl, A. Coulbeck, T. Howes, S. Kille, W. Yeong, C. Robbins, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [4] The Directory: Selected Attribute Syntaxes. CCITT, Recommendation X.520. [5] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol (v3): A UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [6] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. [7] K. Simonsen, "Character Mnemonics and Character Sets," RFC 1345, June 1992. [8] "Programming Languages - C", ANSI/ISO Standard 9899, revised 1997. [9] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Proto- col (v3): Extension for Transport Layer Security", INTERNET-DRAFT (work in progress) , June 1999. [10] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture," RFC 1884, December 1995. [11] A. Herron, T. Howes, M. Wahl, A. Anantha, "LDAP Control Extension for Server Side Sorting of Search Results", INTERNET-DRAFT (work in progress) , 5 April 1999. [12] J. Meyers, "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [13] T. Howes, "The String Representation of LDAP Search Filters," RFC 2254, December 1997. [14] S. Kille, "Using the OSI Directory to Achieve User Friendly Nam- ing," RFC 1781, March 1995. 22. Authors' Addresses Mark Smith (document editor) Netscape Communications Corp. 501 E. Middlefield Rd., Mailstop MV068 Mountain View, CA 94043 USA Expires: 8 April 2000 [Page 69] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 +1 650 937-3477 mcs@netscape.com Tim Howes 1345 Fairway Dr. Los Altos, CA 94024 +1 650 787-5384 timhowes@yahoo.com Andy Herron Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 USA +1 425 882-8080 andyhe@microsoft.com Mark Wahl Innosoft International, Inc. 8911 Capital of Texas Hwy, Suite 4140 Austin, TX 78759 USA +1 626 919 3600 Mark.Wahl@innosoft.com Anoop Anantha Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 USA +1 425 882-8080 anoopa@microsoft.com 23. Appendix A - Sample C LDAP API Code #include #include main() { LDAP *ld; LDAPMessage *res, *e; int i, rc; char *a, *dn; BerElement *ptr; char **vals; Expires: 8 April 2000 [Page 70] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 /* open an LDAP session */ if ( (ld =3D ldap_init( "dotted.host.name", LDAP_PORT )) =3D=3D= NULL ) return 1; /* authenticate as nobody */ if (( rc =3D ldap_simple_bind_s( ld, NULL, NULL )) !=3D LDAP_S= UCCESS ) { fprintf( stderr, "ldap_simple_bind_s: %s\n", ldap_err2string( rc )); ldap_unbind( ld ); return 1; } /* search for entries with cn of "Babs Jensen", return all att= rs */ if (( rc =3D ldap_search_s( ld, "o=3DUniversity of Michigan, c= =3DUS", LDAP_SCOPE_SUBTREE, "(cn=3DBabs Jensen)", NULL, 0, &res ))= !=3D LDAP_SUCCESS ) { fprintf( stderr, "ldap_search_s: %s\n", ldap_err2string( rc )); if ( res =3D=3D NULL ) { ldap_unbind( ld ); return 1; } } /* step through each entry returned */ for ( e =3D ldap_first_entry( ld, res ); e !=3D NULL; e =3D ldap_next_entry( ld, e ) ) { /* print its name */ dn =3D ldap_get_dn( ld, e ); printf( "dn: %s\n", dn ); ldap_memfree( dn ); /* print each attribute */ for ( a =3D ldap_first_attribute( ld, e, &ptr ); a !=3D= NULL; a =3D ldap_next_attribute( ld, e, ptr ) ) { printf( "\tattribute: %s\n", a ); /* print each value */ vals =3D ldap_get_values( ld, e, a ); for ( i =3D 0; vals[i] !=3D NULL; i++ ) { printf( "\t\tvalue: %s\n", vals[i] ); } ldap_value_free( vals ); ldap_memfree( a ); } if ( ptr !=3D NULL ) { ber_free( ptr, 0 ); } Expires: 8 April 2000 [Page 71] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 } /* free the search results */ ldap_msgfree( res ); /* close and free connection resources */ ldap_unbind( ld ); return 0; } 24. Appendix B - Namespace Consumed By This Specification The following 2 prefixes are used in this specification to name func- tions: ldap_ ber_ The following 6 prefixes are used in this specification to name struc- tures, unions, and typedefs: ldap LDAP PLDAP ber Ber timeval The following 3 prefixes are used in this specification to name #defined macros: LDAP LBER_ mod_ 25. Appendix C - Summary of Requirements for API Extensions As the LDAP protocol is extended, this C LDAP API will need to be extended as well. For example, an LDAPv3 control extension has already been defined for server-side sorting of search results [7]. This appen- dix summarizes the requirements for extending this API. 25.1. Compatibility Extensions to this document SHOULD NOT, by default, alter the behavior of any of the APIs specified in this document. If an extension option- ally changes the behavior of any existing C LDAP API function calls, the behavior change MUST be well documented. Expires: 8 April 2000 [Page 72] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 25.2. Style Extensions to this API SHOULD follow the general style and naming con- ventions used in this document. For example, function names SHOULD start with "ldap_" or "ber_" and consist entirely of lowercase letters, digits, and underscore ('_') characters. It is RECOMMENDED that private and experimental extensions use only the following prefixes for macros, types, and function names: LDAP_X_ LBER_X_ ldap_x_ ber_x_ and that these prefixes not be used by standard extensions. 25.3. Dependence on Externally Defined Types Extensions to this API SHOULD minimize dependencies on types and macros that are defined in system headers and generally use only intrinsic types that are part of the C language, types defined in this specifica- tion, or types defined in the extension document itself. 25.4. Compile Time Information Extensions to this API SHOULD conform to the requirements contained in the "Retrieving Information at Compile Time" section of this document. That is, extensions SHOULD define a macro of the form: #define LDAP_API_FEATURE_x level so that applications can detect the presence or absence of the extension at compile time and also test the version or level of the extension pro- vided by an API implementation. 25.5. Runtime Information Extensions to this API SHOULD conform to the requirements contained in the "Retrieving Information During Execution" section of this document. That is, each extension SHOULD be given a character string name and that name SHOULD appear in the ldapai_extensions array field of the LDAPAPI- Info structure following a successful call to ldap_get_option() with an option parameter value of LDAP_OPT_API_INFO. In addition, information about the extension SHOULD be available via a call to ldap_get_option() with an option parameter value of LDAP_OPT_API_FEATURE_INFO. 25.6. Values Used for Session Handle Options Extensions to this API that add new session options (for use with the ldap_get_option() and ldap_set_option() functions) SHOULD meet the Expires: 8 April 2000 [Page 73] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 requirements contained in the last paragraph of the "LDAP Session Handle Options" section of this document. Specifically, standards track docu- ments MUST use values for option macros that are between 0x1000 and 0x3FFF inclusive and private and experimental extensions MUST use values for the option macros that are between 0x4000 and 0x7FFF inclusive. 26. Appendix D - Known Incompatibilities with RFC 1823 This appendix lists known incompatibilities between this API specifica- tion and the one contained in RFC 1823, beyond the additional API func- tions added in support of LDAPv3. 26.1. Opaque LDAP Structure In RFC 1823, some fields in the LDAP structure were exposed to applica- tion programmers. To provide a cleaner interface and to make it easier for implementations to evolve over time without sacrificing binary com- patibility with older applications, the LDAP structure is now entirely opaque. The new ldap_set_option() and ldap_get_option() calls can be used to manipulate per-session and global options. 26.2. Additional Error Codes The following new error code macros were introduced to support LDAPv3: LDAP_REFERRAL LDAP_ADMINLIMIT_EXCEEDED LDAP_UNAVAILABLE_CRITICAL_EXTENSION LDAP_CONFIDENTIALITY_REQUIRED LDAP_SASL_BIND_IN_PROGRESS LDAP_AFFECTS_MULTIPLE_DSAS LDAP_CONNECT_ERROR LDAP_NOT_SUPPORTED LDAP_CONTROL_NOT_FOUND LDAP_NO_RESULTS_RETURNED LDAP_MORE_RESULTS_TO_RETURN LDAP_CLIENT_LOOP LDAP_REFERRAL_LIMIT_EXCEEDED 26.3. Freeing of String Data with ldap_memfree() All strings received from the API (e.g., those returned by the ldap_get_dn() or ldap_dn2ufn() functions) SHOULD be freed by calling ldap_memfree() not free(). RFC 1823 did not define an ldap_memfree() function. Expires: 8 April 2000 [Page 74] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 26.4. Changes to ldap_result() The meaning of the all parameter to ldap_result has changed slightly. Nonzero values from RFC 1823 correspond to LDAP_MSG_ALL (0x01). There is also a new possible value, LDAP_MSG_RECEIVED (0x02). The result type LDAP_RES_MODDN is now returned where RFC 1823 returned LDAP_RES_MODRDN. The actual value for these two macros is the same (0x6D). 26.5. Changes to ldap_first_attribute() and ldap_next_attribute Each non-NULL return value SHOULD be freed by calling ldap_memfree() after use. In RFC 1823, these two functions returned a pointer to a per-session buffer, which was not very thread-friendly. After the last call to ldap_first_attribute() or ldap_next_attribute(), the value set in the ptr parameter SHOULD be freed by calling ber_free( ptr, 0 ). RFC 1823 did not mention that the ptr value SHOULD be freed. The type of the ptr parameter was changed from void * to BerElement *. 26.6. Changes to ldap_modrdn() and ldap_modrdn_s() Functions In RFC 1823, the ldap_modrdn() and ldap_modrdn_s() functions include a parameter called deleteoldrdn. This does not match the great majority of implementations, so in this specification the deleteoldrdn parameter was removed from ldap_modrdn() and ldap_modrdn_s(). Two additional functions that support deleteoldrdn and are widely implemented as well were added to this specification: ldap_modrdn2() and ldap_modrdn2_s(). 26.7. Changes to the berval structure In RFC 1823, the bv_len element of the berval structure was defined as an `unsigned long'. In this specification, the type is implementation- specific, although it MUST be an unsigned integral type that is at least 32 bits in size. See the appendix "Data Types and Legacy Implementa- tions" for additional considerations. 26.8. API Specification Clarified RFC 1823 left many things unspecified, including behavior of various memory disposal functions when a NULL pointer is presented, requirements for headers, values of many macros, and so on. This specification is Expires: 8 April 2000 [Page 75] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 more complete and generally tighter than the one in RFC 1823. 26.9. Deprecated Functions A number of functions that are in RFC 1823 are labeled as "deprecated" in this specification. In most cases, a replacement that provides equivalent functionality has been defined. The deprecated functions are: ldap_bind() Use ldap_simple_bind() or ldap_sasl_bind() instead. ldap_bind_s() Use ldap_simple_bind_s() or ldap_sasl_bind_s() instead. ldap_kerberos_bind() and ldap_kerberos_bind_s() No equivalent functions are provided. ldap_modrdn() and ldap_modrdn2() Use ldap_rename() instead. ldap_modrdn_s() and ldap_modrdn2_s() Use ldap_rename_s() instead. ldap_open() Use ldap_init() instead. ldap_perror() Use ldap_err2string() instead. ldap_result2error() Use ldap_parse_result() instead. 27. Appendix E - Data Types and Legacy Implementations The data types associated with the length of a ber value (ber_len_t), and the tag (ber_tag_t) have been defined in this specification as unsigned integral types of implementation-specific size. The data type used for encoding and decoding ber integer, enumerated, and boolean values has been defined in this specification as a signed integral type of implementation-specific size. This was done so that source and binary compatibility of the C LDAP API can be maintained across ILP32 environments (where int, long, and pointers are all 32 bits in size) and LP64 environments (where ints remain 32 bits but longs and pointers grow to 64 bits). Expires: 8 April 2000 [Page 76] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 In older implementations of the C LDAP API, such as those based on RFC 1823, implementors may have chosen to use an `unsigned long' for length and tag values. If a long data type was used for either of these items, a port of an application to a 64-bit operating system using the LP64 data model would find the size of the types used by the C LDAP API to increase. Also, if the legacy implementation had chosen to implement the tag and types as an unsigned int, adoption of a specification that mandated use of unsigned longs would cause a source incompatibility in an LP64 application. By using implementation-specific data types, the C LDAP API implementation is free to choose the correct data type and the ability to maintain source compatibility. For example, suppose a legacy implementation chose to define the return value of ber_skip_tag() as an unsigned long but wishes to have the library return a 32-bit quantity in both ILP32 and LP64 data models. The following typedefs for ber_tag_t will provide a fixed sized data structure while preserving existing ILP32 source -- all without generat- ing compiler warnings: #include /* provides UINT_MAX in ISO C */ #if UINT_MAX >=3D 0xffffffffU typedef unsigned int ber_tag_t; #else typedef unsigned long ber_tag_t; #endif Similar code can be used to define appropriate ber_len_t and ber_int_t types. 28. Appendix F - Changes Made Since Last Document Revision The previous version of this document was draft-ietf-ldapext-ldap-c- api-03.txt, dated 2 June 1999. This appendix lists all of the changes made to that document to produce this one. 28.1. API Changes Types: Added BerValue typedef for struct berval. Clarified width requirements for integral types. Made it clear that the types for the fields within struct timeval are implementation-specific. Namespace: Added recommendation that private and experimental exten- sions use the LDAP_X_, LBER_X_, ldap_x_, and ber_x_ portions of the namespace only. Macro-defined constants: Added missing 'U' suffix to unsigned integral values. Expires: 8 April 2000 [Page 77] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 "LDAP Error Codes" section: Corrected text to say that LDAP error codes are non-negative integers (used to say "positive integers" which excluded LDAP_SUCCESS). "LDAP Session Handle Option" section: Removed LDAP_OPT_DESC because the definition was insufficient to allow interoperable use. Added new option LDAP_OPT_MATCHED_DN. Documented the defaults for options. Added text to specify required behavior with respect to state in the session handle when a call to ldap_get_option() or ldap_set_option() succeeds or fails. Added the LDAP_OPT_PRIVATE_EXTENSION_BASE macro. "Working With Controls" section: Removed PLDAPControl typedef (was a pointer to an LDAPControl, but was not used anywhere in the API). "Searching" section: Added text to describe how the operation timel- imit that is passed to the LDAP server for an LDAP search operation is derived from the timeout parameter that is passed to ldap_search_ext() and ldap_search_ext_s(). "Comparing a Value Against an Entry" section: Added `const' to declarations of `bvalue' in ldap_compare_ext() and ldap_compare_ext_s(). Also added missing trailing commas in proto- types. "Extended Operations" section: Added `const' to declarations of `requestdata' in ldap_extended_operation() and ldap_extended_operation_s() prototypes. "Obtaining Results and Peeking Inside LDAP Messages" section: Added LDAP_RES_UNSOLICITED macro for use as the `msgid' parameter to ldap_result(). Added text to indicate that ldap_msgid() returns -1 on error. "Handling Errors and Parsing Results" section: Added LDAP_NOTICE_OF_DISCONNECTION macro. "Stepping Through a List of Results" section: Added text to indicate that ldap_count_messages(), ldap_count_entries(), and ldap_count_references() return -1 if an error occurs. "Encoded ASN.1 Value Manipulation" section: Added ber_int_t, ber_uint_t, and ber_slen_t integral types. Changed functions to use ber_int_t where appropriate. Added support for encoding and decoding enumerated values (format 'e'). Added support for the 't' format to ber_scanf() (works like ber_peek_tag()). Changed the format specif- ier for Bitstring in ber_printf() from 'X' to 'B' to match ber_scanf(). Corrected text to say that ber_printf() returns a non- negative number if successful (used to say positive, but zero is a Expires: 8 April 2000 [Page 78] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 valid return value). Removed `const' qualifier from BerElement parameters in ber_flatten() and ber_peek_tag() function prototypes and added note about preserving the state of the underlying BerEle- ment when ber_peek_tag() is called. Revised LBER_ERROR and LBER_DEFAULT macros to use more portable definitions. Updated exam- ples to reflect changes. 28.2. Editorial Changes General: Changed document to reference RFC 2119 ("Key words for use in RFCs to Indicate Requirement Levels") and to use the key words consistently. Reordered references to list them in the order they appear in the document. Added text for deprecated functions to indi- cate that more complete descriptions can be found in RFC 1823. Section names: Renamed "Overview of LDAP API Use" to "Overview of LDAP API Use and General Requirements." Renamed "Header File Requirements" to "Header Requirements." Renamed "Common Data Struc- tures" to "Common Data Structures and Types." Renamed "General" sec- tion within "Encoded ASN.1 Value Manipulation" section to "BER Data Structures and Types." Types: Modified implementation-specific typedefs to use `impl_XXX_t' convention. Moved definition of `ber_tag_t' from "Common Data Struc- tures and Types" section to "Encoded ASN.1 Value Manipulation" sec- tion. "Overview of LDAP API Use and General Requirements" section: added note that conformant implementations MUST implement all of the func- tions and so on defined in this specification. "Header Requirements" section: Removed all references to the term "header file(s)" and replaced with the simpler and less restrictive term "header(s)." "Memory Handling Overview" section: New section added. Also cleaned up text throughout the document to consistently state that "free" routines do nothing when a NULL pointer is passed in. "LDAP Session Handle Options" section: Clarified text to better indi- cate whether ldap_memfree() or ldap_controls_free() should be used to dispose of char * and LDAPControl * values returned by ldap_get_option(). "Handling Errors and Parsing Results" section: Removed confusing use of ldap_parse_*_result() pattern (all function names are spelled out now). Expires: 8 April 2000 [Page 79] =0C C LDAP API C LDAP Application Program Interface 8 October 1999 "Encoded ASN.1 Value Manipulation" section: Added note about lack of specific error codes from BER functions. Cleaned up references to berval to always say "struct berval" or "berval structure." "Authors" section: Updated Tim Howes' contact information. Expires: 8 April 2000 [Page 80] =0C --------------D35DC124AD154E184BDEAFD4-- From list@netscape.com Sat Jul 29 16:32:02 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14769 for ; Sat, 29 Jul 2000 16:32:02 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6TKLjR13753; Sat, 29 Jul 2000 13:21:45 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6TKUdg14019; Sat, 29 Jul 2000 13:30:39 -0700 (PDT) Resent-Date: Sat, 29 Jul 2000 13:30:39 -0700 (PDT) Date: Sat, 29 Jul 2000 13:30:34 -0700 (PDT) Message-Id: <200007292030.e6TKUYw27105@xwing.netscape.com> From: Truchot_J@HCLO.msn.com To: ietf-ldapext@netscape.com Subject: ietf-ldapext -FOFQ X-Reply-To: Truchot_J@msn.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"r-QLFD.A.paD.u7zg5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit ietf-ldapext, Get the BEST Internet Business out there. Marketing the 4 Biggest Trends in History. The Internet-WebSites-e-Commerce-Home-Based Business Take advantage of the Explosive Growth of the Internet. Get rid of the Boss, the JOB, and join us people that are making the MONEY that will be residual income for years to come. Please E-Mail or call with info on When you want to get started.. JOHN @ 208-529-2554 From list@netscape.com Sat Jul 29 17:22:38 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20504 for ; Sat, 29 Jul 2000 17:22:38 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6TLCJR16285; Sat, 29 Jul 2000 14:12:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6TLLEE24538; Sat, 29 Jul 2000 14:21:14 -0700 (PDT) Resent-Date: Sat, 29 Jul 2000 14:21:14 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Sat, 29 Jul 2000 15:20:21 -0600 From: "Jim Sermersheim" To: , Subject: Re: Use of criticality in dupent-04 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e6TLLC124514 Resent-Message-ID: <"Ok49xD.A.I_F.Jr0g5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit I'm changing the text of the dupent draft to read "The criticality is ignored". Jim >>> "David Chadwick" 7/28/00 12:07:56 PM >>> Date forwarded: Wed, 26 Jul 2000 00:11:06 -0700 (PDT) Date sent: Wed, 26 Jul 2000 01:09:47 -0600 From: "Jim Sermersheim" To: , Subject: Re: Use of criticality in dupent-04 Forwarded by: ietf-ldapext@netscape.com > I wouldn't mind removing this, but... 2251 is ambiguous in this area. > If 2251 were to state that the criticality field is only valid and > checked in requests, and ignored for responses, I'd feel more > comfortable. Note also that there are a number of other drafts that > have the same language (see SSS and VLV). Yep - they are wrong as well. Seems like you all copied from each other David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 30 02:42:02 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18698 for ; Sun, 30 Jul 2000 02:42:01 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6U6VfR07352; Sat, 29 Jul 2000 23:31:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6U6ebw02895; Sat, 29 Jul 2000 23:40:37 -0700 (PDT) Resent-Date: Sat, 29 Jul 2000 23:40:37 -0700 (PDT) From: To: Date: Sun, 30 Jul 2000 01:07:31 Message-Id: <56.812811.637314@mail.air99.com> Subject: AD:Family Reunion T Shirts & More Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"-nt8yC.A.9s.j38g5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Message sent by: Kuppler Graphics, 32 West Main Street, Maple Shade, New Jersey, 08052, 1-800-810-4330. This list will NOT be sold. All addresses are automatically added to our remove list. Hello. My name is Bill from Kuppler Graphics. We do screenprinting on T Shirts, Sweatshirts, Jackets, Hats, Tote Bags and more! Do you or someone you know have a Family Reunion coming up? Kuppler Graphics would like to provide you with some great looking T Shirts for your Reunion. Kuppler Graphics can also provide you with custom T's and promotional items such as imprinted magnets, keychains, pens, mugs, hats, etc. for your business or any fundraising activity (church, school, business etc.) We also can provide you with quality embroidery. We are a family owned company with over 15 years of experience. All work is done at this location. No middle man. Our prices are great! Click reply to email us or call 1-800-810-4330 for more info *** If the reply to email is down then please email me at: air99mai@imailbox.com Bill Kuppler Graphics From list@netscape.com Sun Jul 30 04:52:16 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18646 for ; Sun, 30 Jul 2000 04:52:16 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6U8fuR13768; Sun, 30 Jul 2000 01:41:56 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6U8oqo02119; Sun, 30 Jul 2000 01:50:52 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 01:50:52 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C8AA50F@aspams01.cai.com> From: "Lloyd, Alan" To: Albert.Langer@Directory-Designs.org, "'Christopher Apple'" , ietf-ldup@imc.org, ietf-ldapext@netscape.com Cc: agenda@ietf.org, johns@cisco.com Subject: RE: LDUP Working Group Agenda - Summary of objections to requirem ents draft Date: Sun, 30 Jul 2000 18:51:07 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"olGGHB.A.1g.px-g5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is good and should be discussed. Lets put the goals down first - can the LDUP and URP standards make scaleable, reliable directory information systems for business use? I aggree and have voiced the opinion that once we go "sub atomic" on directory objects/entries - then that is implementation - not standardisation. For instance we dismantle in every DSA a complete DSAs NameSpace into RDB tables (32 patents) - so we can automatically index, 2 phase commit, etc.. we can do database replication (sub atomic - product feature) and ,DISP and DSP writethrough (standards feature). Can any vendor/person on this list confirm their desire to do directory entry sub - atomic interoperability testing.. and waht are the tests when they can do that. The rules of the IETF (IMHO) state that 2 or more implementations must interwork - to make an RFC. Can those involved say so.. otherwise - please consider.. Something which is "lightweight" cannot be "Unpredictable" and "Preposterously complex". regards alan -----Original Message----- From: Albert Langer [mailto:Albert.Langer@Directory-Designs.org] Sent: Thursday, July 27, 2000 4:16 PM To: 'Christopher Apple'; ietf-ldup@imc.org; ietf-ldapext@netscape.com Cc: agenda@ietf.org; johns@cisco.com Subject: RE: LDUP Working Group Agenda - Summary of objections to requirements draft [Chris] I. WG Deliverables Review "LDAP Replication Requirements" http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-03.txt Editor(s): Russ Weiser, Ellen Stokes [...] III. Discussion of LDUP Requirements Document [Albert] I am also sending this to LDAPEXT as the direction taken by LDUP could have major consequences for LDAPEXT (eg the current proposals for ACL simply will not replicate correctly and future support for transactions will be difficult if not impossible). Above link shows: *** This Internet-Draft has expired and is no longer available. Unrevised documents placed in the Internet-Drafts directories have a maximum life of six months. After that time, they must be updated, or they will be deleted. This document was deleted on July 17, 2000. *** A copy of the "final" version, which expired on 21 April 2000, is in the LDUP email archive at: http://www.imc.org/ietf-ldup/mail-archive/msg00471.html Despite assurances from at least one person who should know, I remain quite convinced that members of the LDUP WG have NOT read it carefully. It is especially unlikely that anybody else has read it recently, since it expired two months ago and has now been deleted. In view of agenda item III, I strongly urge that you do read it again, carefully. As I cannot attend the discussion, I have included a summary of my formal objection to it below. SUMMARY OF OBJECTIONS TO REQUIREMENTS DRAFT The three key points are: 1) There is no requirement for convergence or "eventual consistency". This looks like just poor expression, but in fact the LDUP architecture and Update Reconciliation Procedures do specify proposed standards that guarantee long term divergence by relying on timestamps and allowing DSAs to transmit changes out of order and drop changes when clocks are out of sync. This is easily fixed, once a requirement to fix it is agreed on. Details on how to fix it based on the Coda replication protocols also adopted by Active Directory, and a semi-formal proof that the fix would be robust in the face of DSAs crashing and being restored from backups, network partitioning etc etc, is included in my draft below. That fix is also consistent with the rest of the current architecture and URP and would not require major re-work of existing drafts. 2) There is no requirement for atomic operations. Again this is obscured by poor expression and nonsensical definitions, but in fact the architecture and URP drafts merge changes to individual attribute values made concurrently at different replicas. The fact that this obviously breaks the ACL standards being developed in LDUP, despite an overlap in authorship between the two documents, strongly confirms that the consequences for existing applications are simply not understand and should be studied through a requirements analysis by actively explaining the implications and soliciting input from other areas (operations etc) that may be affected. Fixing this would require substantial changes to the current architecture and URP. I have sketched one possible way to do so in the draft below. 3) There is no requirement to support mandatory operational attributes of LDAP. The operational attribute "modifiersName" cannot be supported meaningfully as nobody in particular can be said to be responsible for a change that has in fact been merged from two or more concurrent changes made independently and without knowledge of each other. This severely complicates system administration as the first thing anybody would want to know after receiving a problem report is "who changed what". I believe that point 1) would be taken for granted by anybody thinking about LDUP requirements. Until somebody presents an argument against convergence or "eventual consistency" I see no point in even trying to present an argument for it. The current approach is simply absurd. Point 3) is also pretty obvious and is just one of many consequences of point 2. On point 2, there are plausible arguments (which I disagree with) for breaking the current LDAP/X.500 data model. If the WG does intend to do that, it has an obligation to clearly explain its intentions in a requirements draft and actively solicit input. I cannot express the argument against doing so more clearly than has already been done, long ago, without adequate response, in the following comments "Re: LDUP warmup exercise: atomicity in LDAPv3", from Tim Howes (16 December 1998): *** "Each LDAP operation (add, modify, delete, moddn) as a whole is atomic. The whole operation either happens or it doesn't. Changes cannot be half-applied to any single LDAP server. The replication consistency model must assume and build on this basic fact to define how multiple LDAP replicas converge to the same state over time, in the absence of additional changes. This kind of loose consistency model is pretty fundamental to the notion of a directory. My two cents on what's important in a replication consistency model are that it must be 1) predictable, and that it should 2) make some kind of sense to people using the system. All this talk of consistency at different levels (e.g., between applications using the directory at the same time) is a red herring. Our job is to define a consistency model for the directory itself. Some applications may find this model sufficient for their needs. Others may have to build more elaborate models on top. But let's start with the basics. -- Tim" http://www.imc.org/ietf-ldup/mail-archive/msg00214.html *** In my view, both an explicit requirement for atomic operations and a requirement that the results be 1) predictable and 2) make some kind of sense to users, should be in the final requirements draft. The consistency model of URP, was summarized in Alison's "Contribution to Profiles Document (Consistency Discussion)": http://www.imc.org/ietf-ldup/mail-archive/msg00548.html The attached Word version, with more easily read tables, is: http://www.imc.org/ietf-ldup/mail-archive/doc00000.doc In my view it is: 1) Unpredictable. See the explanation of "Extraordinary States" and "Transient Extraordinary States" above. 2) Preposterously complex. See the extensive use of procedural pseudo code for a protocol that simply defies plain description, in the URP draft: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.txt In reviewing the LDUP archives I noted that a number of people had expressed various reservations, especially concerning the consistency model for replication, but subsequently ceased active participation. Hopefully some of them may still be involved in LDAP-EXT and could therefore see this and decide to take part in the discussion. See also my individual submission to LDUP: http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt and my response to the WG chair's request for status reports, which contains links to all relevant discussion of that objection prior to the document expiring: http://www.imc.org/ietf-ldup/mail-archive/msg00561.html Subsequent discussion can be seen by following from the thread of that message in the archive. From list@netscape.com Sun Jul 30 08:19:49 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25499 for ; Sun, 30 Jul 2000 08:19:49 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6UCDAj28277; Sun, 30 Jul 2000 05:13:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6UCIJE19157; Sun, 30 Jul 2000 05:18:19 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 05:18:19 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Jim Sermersheim" , Date: Sun, 30 Jul 2000 13:16:58 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Use of criticality in dupent-04 Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <39842ACA.28236.82A3415@localhost> Priority: normal In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"ix_vCD.A.4qE.J0Bh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date sent: Sat, 29 Jul 2000 15:20:21 -0600 From: "Jim Sermersheim" To: , Subject: Re: Use of criticality in dupent-04 > I'm changing the text of the dupent draft to read "The criticality is > ignored". > > Jim > thanks David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 30 08:19:54 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25535 for ; Sun, 30 Jul 2000 08:19:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6UC9QR23143; Sun, 30 Jul 2000 05:09:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6UCIMI19213; Sun, 30 Jul 2000 05:18:22 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 05:18:22 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Jim Sermersheim" , Date: Sun, 30 Jul 2000 13:16:59 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Syntax Issues Reply-to: d.w.chadwick@salford.ac.uk CC: Message-ID: <39842ACB.21649.82A3668@localhost> Priority: normal In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"yyjj-D.A.brE.L0Bh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT > I'm also in favor of defining a new > OID and matching rule (or rules). I'm told of a WG meeting some time > back (Chicago maybe?) where there was an overwhelming consensus NOT to > define new syntax OIDS. If this is still the case, a lesser evil might > be to use Octet String syntax, and just force exact matching (eck). > This is part of a larger issue that should be covered by a Shema BOF if there is one. I have written a PKIX id that has defined matching rules and syntaxes for certificates and CRLs etc. I dont think we can dodge this issue in general. Whilst we dont want to unnecessarily define extra syntaxes for the sake of it, we do want to allow users to have sensible and easy ways of matching on complex attributes (such as ACI and certificates) David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 30 08:19:57 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25551 for ; Sun, 30 Jul 2000 08:19:56 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6UCDLj28396; Sun, 30 Jul 2000 05:13:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6UCIUo19359; Sun, 30 Jul 2000 05:18:30 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 05:18:30 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: Bruce Greenblatt Date: Sun, 30 Jul 2000 13:16:59 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Use of criticality in dupent-04 Reply-to: d.w.chadwick@salford.ac.uk CC: Message-ID: <39842ACB.17440.82A38C5@localhost> Priority: normal In-reply-to: <4.3.1.0.20000728115522.00ad69d0@pop.walltech.com> References: <3981DA0C.26533.BA6DA98@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"DGgKJB.A.QtE.R0Bh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT > > Are you saying that it is not allowed to put a criticality field in a > control that appears in an operation response? This certainly seems > to make sense. The LDAP client has already received the result of the > operation. It doesn't really seem to matter at that point whether the > control in the response was critical or not. If the client doesn't > understand the control, it won't make use of it in either case. If > the client does understand the control, it doesn't matter what the > criticality is either. RFC 2251 should definitely say that > criticality in controls that come back to the client in a response can > be safely ignored. I believe this is the case at the moment with all existing RFCs and IDs, and is compatible with X.500. However, we might (only might note, I am not suggesting it) want to consider the case for the future, that if the client and server go into a prolonged dialogue, where the client must reply to the server and must do something that the server is asking, then the client acts on the criticality flag and says "sorry cant do" to the server if the client does not understand a critical control. But really in this case the client is no longer a client but a peer, isn't it? David > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 30 08:20:04 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25603 for ; Sun, 30 Jul 2000 08:20:04 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6UCDQj28457; Sun, 30 Jul 2000 05:13:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6UCIZE19480; Sun, 30 Jul 2000 05:18:35 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 05:18:35 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com Date: Sun, 30 Jul 2000 13:17:00 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: auth-response comments Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <39842ACC.22795.82A3C6C@localhost> Priority: normal In-reply-to: <4.3.2.7.0.20000726233331.00b35520@infidel.boolean.net> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"0TgQZ.A.quE.W0Bh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT > First, please note my general aversion to unsolicited controls. > IMO, controls should only be sent to clients which are known to > be able to make use of the information. > I would concurr with this. In the general case, the client initiates a request and might use a control. This then gives the server the opportunity to put related controls in the response. If the client does not use a control, the server should assume the client is uninformed about them. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 30 08:20:08 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25654 for ; Sun, 30 Jul 2000 08:20:07 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6UC9cR23268; Sun, 30 Jul 2000 05:09:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6UCIY219450; Sun, 30 Jul 2000 05:18:34 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 05:18:34 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "'Bruce Greenblatt'" , ietf-ldapext , "d.w.chadwick" Date: Sun, 30 Jul 2000 13:17:00 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: Use of criticality in dupent-04 Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <39842ACC.11341.82A3AEB@localhost> Priority: normal In-reply-to: <28560036253BD41191A10000F8BCBD11841BE3@zcard00g.ca.nortel.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"0ARASC.A.YuE.U0Bh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date forwarded: Fri, 28 Jul 2000 13:59:15 -0700 (PDT) From: "Mircea Pana" > > For example: > LCUP [should] makes use of criticality in the entryUpdate controls > attached to SearchResultEntries to mark deleted entries: So if the client does not understand the deleted control and it is not marked critical, it will ignore the control and will update its copy with a set of zero attributes (which is almost a deleted entry :-). If the control is critical, what should the client do, ignore the SearchResult and leave its copy of the deleted entry with all its attributes? And if it does understand the control (regardless of criticality) it will delete the entry copy, which is the intended result. So criticality serves little purpose, doesn't it? And certainly not the intended purpose of "ignore my request if you dont understand this and take no action please", since the delete has already been carried out by the server. David > " In > response to the client's synchronization request, the server > returns a set of SearchResultEntries that fits the client's > specification. To represent a deleted entry, the server attaches an > entryUpdate control to the corresponding SearchResultEntry. The > SearchResultEntry corresponding to a deleted entry MUST contain a > valid DN and a valid uniqueid but, to reduce the amount of data > sent to the client, it SHOULD not contain any other attributes." > > Mircea. > > > > > -----Original Message----- > > From: Bruce Greenblatt > > [mailto:bgreenblatt@directory-applications.com] Sent: Friday, July > > 28, 2000 4:05 PM To: d.w.chadwick@salford.ac.uk; Jim Sermersheim; > > ietf-ldapext; d.w.chadwick Subject: Re: Use of criticality in > > dupent-04 > > > > > > > > > > > > > I wouldn't mind removing this, but... 2251 is ambiguous > > in this area. > > > > If 2251 were to state that the criticality field is only valid > > > > and checked in requests, and ignored for responses, I'd feel > > > > more comfortable. Note also that there are a number of other > > drafts that > > > > have the same language (see SSS and VLV). > > > > > >Yep - they are wrong as well. Seems like you all copied from each > > >other > > > > > >David > > > > Are you saying that it is not allowed to put a criticality field in > > a control that appears in an operation response? This certainly > > seems to make sense. The LDAP client has already received the > > result of the operation. It doesn't really seem to matter at that > > point whether the control in the response was critical or not. If > > the client doesn't understand the control, it won't make use of it > > in either case. If the client does understand the control, it > > doesn't matter what the criticality is either. RFC 2251 should > > definitely say that criticality in controls that come back to the > > client in a response can be safely ignored. > > > > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Jul 30 08:37:52 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02063 for ; Sun, 30 Jul 2000 08:37:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6UCRWR25182; Sun, 30 Jul 2000 05:27:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6UCaSQ24517; Sun, 30 Jul 2000 05:36:28 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 05:36:28 -0700 (PDT) Message-Id: <4.3.2.7.0.20000730053317.00b0a730@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 30 Jul 2000 05:35:35 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: Syntax Issues Cc: "Jim Sermersheim" , , In-Reply-To: <39842ACB.21649.82A3668@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"wGjC8D.A.z-F.LFCh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com My opinion is that if you want more than BLOB semantics, then you need to define a new syntax. However, new syntaxes should have a string representation. At 01:16 PM 7/30/00 +0100, David Chadwick wrote: >> I'm also in favor of defining a new >> OID and matching rule (or rules). I'm told of a WG meeting some time >> back (Chicago maybe?) where there was an overwhelming consensus NOT to >> define new syntax OIDS. If this is still the case, a lesser evil might >> be to use Octet String syntax, and just force exact matching (eck). >> > >This is part of a larger issue that should be covered by a Shema >BOF if there is one. I have written a PKIX id that has defined >matching rules and syntaxes for certificates and CRLs etc. I dont >think we can dodge this issue in general. Whilst we dont want to >unnecessarily define extra syntaxes for the sake of it, we do want >to allow users to have sensible and easy ways of matching on >complex attributes (such as ACI and certificates) > >David > >*************************************************** > >David Chadwick >IS Institute, University of Salford, Salford M5 4WT >Tel +44 161 295 5351 Fax +44 161 745 8169 >Mobile +44 790 167 0359 >Email D.W.Chadwick@salford.ac.uk >Home Page http://www.salford.ac.uk/its024/chadwick.htm >Understanding X.500 http://www.salford.ac.uk/its024/X500.htm >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm >Entrust key validation string MLJ9-DU5T-HV8J > >*************************************************** From list@netscape.com Sun Jul 30 08:53:33 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05453 for ; Sun, 30 Jul 2000 08:53:32 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6UChDR26137; Sun, 30 Jul 2000 05:43:13 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6UCq9c27893; Sun, 30 Jul 2000 05:52:09 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 05:52:09 -0700 (PDT) X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Lloyd, Alan'" , "'Christopher Apple'" , , Cc: , Subject: RE: LDUP Working Group Agenda - Summary of objections to requirements draft Date: Sun, 30 Jul 2000 22:52:01 +1000 Message-ID: <000501bffa24$f4f92ac0$17448490@vic.bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <11981F9F5649D411BC92009027D0D18C8AA50F@aspams01.cai.com> Resent-Message-ID: <"tnfoe.A.hzG.4TCh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit [Alan] This is good and should be discussed. Lets put the goals down first - can the LDUP and URP standards make scaleable, reliable directory information systems for business use? I aggree and have voiced the opinion that once we go "sub atomic" on directory objects/entries - then that is implementation - not standardisation. For instance we dismantle in every DSA a complete DSAs NameSpace into RDB tables (32 patents) - so we can automatically index, 2 phase commit, etc.. we can do database replication (sub atomic - product feature) and ,DISP and DSP writethrough (standards feature). Can any vendor/person on this list confirm their desire to do directory entry sub - atomic interoperability testing.. and waht are the tests when they can do that. [Albert] Thanks for the agreement. However I would like to focus on user requirements rather than vendor desires. When reviewing the LDUP archives I noticed your views and others expressing various "reservations", however the previous discussion was focussed on detail design and in the context of what vendors desired to implement. I believe that focus on vendor desires rather than user requirements is what led to the fundamental technical errors in the current architecture and URP drafts. Now that the requirements draft is up for "final call" (regrettably AFTER extensive architecture and design work) a decision MUST be made as to whether these ARE the requirements that users of the directory service have, that must be satisfied by the future proposed standards for meeting them. Let's focus on that REQUIREMENTS issue. It's what is on the agenda NOW. The basic problem, underlying all three of the key issues I summarized, is that the requirements draft simply contains NO requirements whatsoever relevant to multi-master replication. It does start from similar goals to your "scaleable, reliable directory information systems for business use". But then it simply does not state what is required from the standards in order to achieve those goals. All it requires of multi-master standards is: 5.6 The replication model MUST support both master-slave and authoritative multi-updateable replica relationships. Perhaps that's why others didn't find anything to object to? They may have only been looking for requirements that could cause difficulties in their vendor implementations. But even that is completely botched by the meaningless definition: Updateable Replica - A Non-authoritative read-writeable copy of the replicated information. Such that during conflict resolution a authoritative master takes precedents in resolving conflicts. Simple proof reading is clearly required before final call. But how could ANYONE have actually READ that and thought that either the document or the intentions behind it, was ready for "final call"? There is obviously no possibility of an "authoritative master" taking precedence in resolving conflicts, since the definition of multi-master replication, copied from the WG charter correctly specifies: Multi-Master Replication - A replication model where entries can be written and updated on any of several updateable replica copies without requiring communication with other updateable replicas before the write or update is performed. There is no such thing as a "non-authoritative read-writeable copy" in multi-master. Nobody with the slightest understanding of what the WG is actually supposed to be working on could have such a complete misconception about updateable replicas, regardless of their expertize in other areas. Of course its rather hard for people to read the draft, since it is being discussed while expired and deleted, and is only available from the LDUP email archives: http://www.imc.org/ietf-ldup/mail-archive/msg00471.html [Alan] The rules of the IETF (IMHO) state that 2 or more implementations must interwork - to make an RFC. Can those involved say so.. otherwise - please consider.. Something which is "lightweight" cannot be "Unpredictable" and "Preposterously complex". regards alan [Albert] My understanding is that the current architecture and design approach is the result of a "vendor bake-off", so there must be sufficient vendor support for interoperability testing. Presumably Telstra is planning an implementation since the URP design came from there and they already have a simulator. Likewise Novell looks strongly committed together with Netscape and Sun. Even Oracle seems to be involved despite knowing a thing or two about the consequences of non-atomicity in databases. Of the majors, only Microsoft seems to have stayed well clear, perhaps laughing quietly on the way to the bank. Despite the complexities, I don't think the URP draft is unimplementable at all. Presumably there would have been loud screams from the various vendors if it was. The criteria for any testing would presumably be based on whether an implementation complies with the proposed standards. Acceptance of those proposed standards would presumably depend on whether they satisfy the requirements in the requirements document. Since that does not actually state ANY meaningful requirement for multi-master replication, it would not be difficult not to meet those requirements. Actually, as currently drafted, with not even convergence clearly required, an implementation could pass ANY test suite by simply dropping all updates and returning: the error code serverClocksOutOfSync (72). See p40 of: http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-04.txt That's what happens when you let implementors define their own requirements, though it is rather more spectacular than usual in this case, since they have come up with something simply absurd. It is the users, including system administrators, who will be hit by the complexities resulting from non-convergence, inconsistency and no audit trail. There is no shortage of vendor products that are "unpredictable" and "preposterously complex" to use. Sticking an IETF label of approved LDAP standard on such products won't help them as much as they seem to think. The question is whether what the vendors plan to implement will in fact meet user requirements for LDAP replication (whether "business" or other) and whether it will negatively impact existing LDAP standards. If there is a user requirement and LDAP standard for guaranteed eventual convergence it doesn't matter a damn if every potential implementor is ready, willing and able to do something else - the result would be useless to users. Likewise if there is a user requirement for atomic operations or modifiersName. Given the LDAP standards, anything that doesn't provide that just isn't LDAP. BTW a "proposed standard" from a WG does not require 2 or more implementations. That is only essential at a later stage of draft standard. An Informational RFC need not have any implementations at all. It can just be a poem provided it offers some information of interest to the internet community. The requirements draft now being considered for WG "final call" is naturally intended as an "Informational" RFC and would normally go through without much external review. Unfortunately it does not provide ANY useful information as to what requirements the LDUP WG intends to meet for its main focus on multi-master LDAP replication, despite considerable detail on matters common to single-master and multi-master replication. If unchallenged, that would result in the WG continuing to focus on vendor desires instead of user requirements in completing their proposed standards. Since a requirements draft is intended to guide the development of standards, and this one does not, it should be published only with simultaneous application of the status "Historic" (your spelling may vary). From list@netscape.com Sun Jul 30 10:17:04 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26576 for ; Sun, 30 Jul 2000 10:17:03 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6UE4uR29391; Sun, 30 Jul 2000 07:04:56 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6UEDqk13051; Sun, 30 Jul 2000 07:13:52 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 07:13:52 -0700 (PDT) Message-ID: <398438B2.45E739C6@caveosystems.com> Date: Sun, 30 Jul 2000 10:16:18 -0400 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: d.w.chadwick@salford.ac.uk CC: Bruce Greenblatt , ietf-ldapext@netscape.com Subject: Re: Use of criticality in dupent-04 References: <3981DA0C.26533.BA6DA98@localhost> <39842ACB.17440.82A38C5@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Resent-Message-ID: <"j7T3OD.A.pLD.fgDh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit I think it's more likely that a repository must want to include a critical control in its response that allows it to "disclaim" some of its data. For example, "these search results are not to be used for spam," "i cannot vouch for the content you'll get when you follow these referrals," etc. From list@netscape.com Sun Jul 30 12:02:53 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24390 for ; Sun, 30 Jul 2000 12:02:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6UFpTR03996; Sun, 30 Jul 2000 08:51:29 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6UG0P201644; Sun, 30 Jul 2000 09:00:25 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 09:00:25 -0700 (PDT) Date: Sun, 30 Jul 2000 09:00:17 -0700 (PDT) Message-Id: <200007301600.e6UG0GM14009@ywing.netscape.com> From: free@praisemail.com To: @netscape.com Subject: "CHAIN-LETTER" It's LEGAL,It Works,It's EASY..Make A TON OF CASH ! ! ! X-Reply-To: FREECASH@miraclemail.ca.nz Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"boZSqD.A.aZ.YEFh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit

"CHAIN-LETTER" It's Legal, It Works, It's EASY ! ! !

EVERY0NE ON THIS LIST GETS PAID EVERY TIME !!! Invest $15 and get your name on the list, you will not regret it ! ($5 to each person)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Parents of 15 yr.old Find $71,000 cash hidden in his closet.

"CASH JUST KEEPS COMING IN MY MAIL" ! !

Dear friend,

It Works, Its Legal, Its Easy, so Why Not?

Parents of 15-year-old find $71,000 cash hidden in his closet.

Does this headline look familiar?Of course it does.You most likely have just seen this story recently featured on a major nightly news program (USA).

His mother was cleaning and putting laundry away when she came across a large brown paper bag that was suspiciously buried beneath some clothes and a skateboard in the back of her 15-year-old sons closet.Nothing could have prepared her for the shock she got when she opened the bag and found it was full of cash.Five-dollar bills, twenties, fifties and hundreds - all neatly rubber-banded in labeled piles.

"My first thought was that he had robbed a bank", says the 41-year-old woman, "There was over $71,000 dollars in that bag -- thats more than my husband earns in a year".

The woman immediately called her husband at the car-dealership where he worked to tell him what she had discovered.He came home right away and they drove together to the boys school and picked him up.Little did they suspect that where the money came from was more shocking than actually finding it in the closet.

As it turns out, the boy had been sending out, via E-mail, a type of "chain-letter" to E-mail addresses that he obtained off of the Internet.Everyday after school for the past 2 months, he had been doing this right on his computer in his bedroom."I just got the E-mail one day and I figured what the heck, I put my name on it like the instructions said and I started sending it out", says the clever 15-year-old.

The E-mail letter listed 3 addresses and contained instructions to send one $5 dollar bill to each person on the list, then delete the address at the top and move the other 2 addresses up, and finally to add your name to the bottom oflist.

The letter goes on to state that you would receive several thousand dollars in five-dollar bills within 2 weeks if you sent out the letter with your name at the bottom of the 3-address list. "I get junk E-mail all the time, andreally did not think it was going to work", the boy continues.

Within the first few days of sending out the E-mail, the Post Office Box that his parents had gotten him for his video-game magazine subscriptions began to fill up with not magazines, but envelopes containing $5 bills.

"About a week later I rode [my bike] down to the post office and my box had 1 magazine and about 300 envelops stuffed in it. There was also a yellow slip that said I had to go up to the [post office] counter. I thought I was in trouble or something (laughs)". He goes on, "I went up to the counter and they had a whole box of more mail for me.I had to ride back home and empty out my backpack because I could not carry it all".

Over the next few weeks, the boy continued sending out the E-mail."The money just kept coming in and I just kept sorting it and stashing it in the closet,barely had time for my homework".He had also been riding his bike to several of the banks in his area and exchanging the $5 bills for twenties, fifties and hundreds.

"I didnt want the banks to get suspicious so I kept riding to different banks with like five thousand at a time in my backpack. I would usually tell the lady at the bank counter that my dad had sent me in [to exchange the money] and he was outside waiting for me.One time the lady gave me a really strange look and told me that she would not be able to do it for me and my dad would have to come in and do it, but I just rode to the next bank down the street (laughs)."

Surprisingly, the boy did not have any reason to be afraid.The reporting news team examined and investigated the so-called "chain-letter" the boy was sending out and found that it was not a chain-letter at all.In fact, it was completely legal according to US Postal and Lottery Laws, Title 18, Section 1302 and 1341, or Title 18, Section 3005 in the US code, also in the code of federal regulations, Volume 16, Sections 255 and 436, which state a product or service must be exchanged for money received.

Every five-dollar bill that he received contained a little note that read, "Please add me to your mailing list".This simple note made the letter legal because he was exchanging a service (adding the purchasers name to his mailing list) for a five-dollar fee.

Here is the letter that the 15-year-old was sending out by E-mail, you can do the exact same thing he was doing, simply by following the instructions in this letter.

--------------------------------------------

Here are instructions on how to make $10,000 US cash in the next 2 weeks:

There are 3 addresses listed below.

Send each person on the list a $5 bill wrapped in 2 pieces of paper (to securely hide it), along with a note that says: "Please add me to your mailing list".

Then delete the name at the top, move the other 2 up and put your name at the bottom.

Now start sending this ENTIRE e-mail back out to people.When 20 people receive it, those 20 people will move your name up to the middle position and they will each send out 20.That totals 400 people that will receive this letter with your name in the middle.

Then, those 400 people will move your name up to the top and they will each send out 20 E-mails.That totals 8,000 people that will receive this E-mail with your name on it and they will each send you a $5 bill.

8,000 people each sending you a $5 bill = $40,000 cash.Thats if everyone responds to this E-mail, but not everyone will, so you can expect more realistically to receive about $10,000 cash $5 bills in your mailbox.

This will work for anyone, anywhere in the world in any country, but send only US CASH $5 bill.

The more E-mails you send out, the more cash you will receive.If each person sends out 100 E-mails, there will be 1,000,000 people that receive this letter with your name on it. If only 1% of those people respond, you will still get $50,000 cash.

Here is the list:

--------------------------------------------

#1. Jenny Gariss

7119 196th St SW

Lynnwood,Wa. 98036

#2. Margaret Vines

9792 Edmonds Way

# 218

Edmonds, Wash. 98020

#3.Kadee Construction

13619 Mukilteo Speedway

Suite D-5 #142

Lynnwood, Wa. 98037-1606

---------------------------------------------

THERES NOTHING MORE TO DO. When you start sending this out within a few days, you will start receiving $5 bills from other people just like yourself, who are willing to invest three $5 bills to receive $10,000 cash.

EVERYONE on this list gets Paid EVERY TIME…invest $15 & get your name on the list, you will not regret it !

If you dont try it- you will never know.

=============================================

This is Not Spam,I received your e-mail address as someone interested in Internet Business Opportunities.I have purchased your e-mail address from "The E-Mail Center" for a list of people to send business opportunities to.If you opt not to be on this list, please e-mail "The E-Mail Center" at express613@hotmail.com type "remove me from your mailing lists" in the subject. From list@netscape.com Sun Jul 30 13:03:38 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10278 for ; Sun, 30 Jul 2000 13:03:38 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6UGuxj11827; Sun, 30 Jul 2000 09:57:03 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6UH29213032; Sun, 30 Jul 2000 10:02:09 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 10:02:09 -0700 (PDT) Message-ID: <004e01bff70b$dd65cb00$3029b0cb@a0p6q3> From: "Fulfill Your Dreams" To: Subject: Proof That It Really Works! Date: Wed, 26 Jul 2000 02:41:15 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01BFF6D1.3106F300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Resent-Message-ID: <"BytkXB.A.WLD.P-Fh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multi-part message in MIME format. ------=_NextPart_000_004B_01BFF6D1.3106F300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, it's me again. Federico, The following is a brief letter from Gary White, founder of the CookieCutter Marketing System. I think you'll find it very interesting. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Hello, I'm Gary White Yesterday you requested information about the CookieCutter Marketing System. And I thought you might want to hear what others have to say about the program...so I've taken three excerpts from some of the many letters sent to us by CC members." "These letters were not solicited in any way...and are on file at the CC office. Copies can be supplied on request." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= From a single mom.... "I have been a well-paid data entry/desk-top publisher/typesetter for over 18 years of my life, and I have NEVER made this much money -- this quick -- EVER-- before CookieCutter! I have found that the extra money generated from Cookie Cutter is Fantastic! I am seeing results already, and I just started the first of the year! This was a real blessing to me to have a new cash income flow so soon after the big Christmas holiday shopping spree. What a great way to start off the new year! I made my $20 start up investment back in just a few hours, and the checks are generating a steady income flow right from my email account. Any computer and any browser works with CookieCutter as long as you have a valid email address. I was told that FREE and Low-Cost start up programs like CookieCutter are just scams, and that they don't work. Well...CookieCutter must be the exception, because I have been pulling in checks from the moment I got the program set up. This one is worth every penny and more! It's the most fun I have ever had working a home-based program. They say you can make up to $300 per day with CookieCutter. In my first month - January 2nd through January 31st, 1999, "In less than a full month, I made over $2,000 in CookieCutter autosales. Not a bad start ... I can live with that for now. This was done with the least amount of time and effort since I already have a full-time 9 to 5 job, and I'm a single mom with 2 kids to deal with. Finally, an internet company that offers an honest-to-goodness way of making money with your home computer. " EC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= From an internet newbie... "This takes you "Back to the Basics" in a way that is totally clear and easy to understand. I started making money from Day One....and if I can do it, ANYONE can!" MC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D From an internet marketing professional... The feature I like most about Gary's course is every step I take, I can measure the results in cold hard cash. I have already earned ten times the $20 fee just in the first week. This program is a must for all Internet marketers. Bob Smith: Smith Family Enterprises =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D So there it is.. The proof is in the pudding. And since its launch in mid December of this year, over 3,000 people have joined...that's a lotta proof. Sincerely, Federico B. Ison, Jr. starbiz@pempe.net PS - If CookieCutter really works...but you DON'T try it, then you could be missing out on something that could revolutionize your future. On the other hand... If CookieCutter DOESN'T work...then all you're out is $20 bucks. About what you'd spend on a night at the movies. Think about it! ----------------------- If you're ready to get started...then, reply to this e-mail with "send = more info" as text. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D (NO SPAM POLICY) You Are Receiving This Mail Because We Either Had = Contact Before Or Your Name Appeared On A Safe E-Mail List That We Both = Belong To, Or It Was On An Ad To Make Money And To Receive Money. If = You Wish To Be Removed, Simply click the reply button and type REMOVE as = text. If Offended You In Any Way Shape Or Form, Please Accept My Sincere = Apology. ------=_NextPart_000_004B_01BFF6D1.3106F300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 
 
Hi, it's me again.
Federico,

The following is a brief = letter from=20 Gary White,
founder of the CookieCutter Marketing System.
I think = you'll=20 find it very = interesting.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DHello,
I'm Gary=20 White

Yesterday you requested information about the=20 CookieCutter
Marketing System. And I thought you might want to hear=20 what
others have to say about the program...so I've taken = three
excerpts=20 from some of the many letters sent to us by=20 CC
members."

"These letters were not solicited in = any=20 way...and are on
file at the CC office. Copies can be supplied on=20 request."

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

From a single=20 mom....

"I have been a well-paid data=20 entry/desk-top
publisher/typesetter for over 18 years of my life, = and
I=20 have NEVER made this much money -- this quick --
EVER-- before=20 CookieCutter!

I have found that the extra money generated = from
Cookie=20 Cutter is Fantastic! I am seeing results already,
and I just started = the=20 first of the year! This was a real
blessing to me to have a new cash = income=20 flow so
soon after the big Christmas holiday shopping spree.
What = a great=20 way to start off the new year!

I made my $20 start up investment = back in=20 just a few
hours, and the checks are generating a steady = income
flow right=20 from my email account. Any computer and
any browser works with = CookieCutter=20 as long as you
have a valid email address.

I was told that = FREE and=20 Low-Cost start up programs
like CookieCutter are just scams, and that = they=20 don't
work.  Well...CookieCutter must be the = exception,
because I=20 have been pulling in checks from the moment
I got the program set=20 up.

This one is worth every penny and more!  It's the = most
fun I=20 have ever had working a home-based program.

They say you can make = up to=20 $300 per day with
CookieCutter. In my first month - January 2nd=20 through
January 31st, 1999, "In less than a full month, I = made
over=20 $2,000 in CookieCutter autosales.

Not a bad start ... I can live = with=20 that for now.
This was done with the least amount of time and = effort
since=20 I already have a full-time 9 to 5 job, and I'm a
single mom with 2 = kids to=20 deal with.

Finally, an internet company that offers=20 an
honest-to-goodness way of making money with your
home computer. = "
EC
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
From an internet=20 newbie...

"This takes you "Back to the Basics" in = a way=20 that is totally
clear and easy to understand. I started making money=20 from
Day One....and if I can do it, ANYONE=20 can!"
MC
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
From an internet marketing=20 professional...

The feature I like most about Gary's course is = every step=20 I
take, I can measure the results in cold hard cash.  I = have
already=20 earned ten times the $20 fee just in the first week.
This program is = a must=20 for all Internet marketers.
Bob Smith:
Smith Family=20 Enterprises
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

So there it is..
The proof=20 is in the pudding. And since its launch in
mid December of this year, = over=20 3,000 people have
joined...that's a lotta=20 proof.

Sincerely,

Federico B. Ison, Jr.

starbiz@pempe.net

PS - If=20 CookieCutter really works...but you DON'T try=20 it,
         then you could = be=20 missing out on something that=20 could
        revolutionize your=20 future.

On the other hand...
If CookieCutter DOESN'T = work...then all=20 you're out is
$20 bucks. About what you'd spend on a night at = the
movies.=20 Think about it!
-----------------------

If you're ready to get = started...then, reply to this e-mail with "send more info" as=20 text.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(NO SPAM POLICY)  You=20 Are Receiving This Mail Because We Either Had Contact Before Or Your = Name=20 Appeared On A Safe E-Mail List That We Both Belong To, Or It Was On An = Ad To=20 Make Money And To Receive Money.  If You Wish To Be Removed, Simply = click=20 the reply button and type REMOVE as text. If Offended You In Any Way = Shape Or=20 Form, Please Accept My Sincere Apology.
------=_NextPart_000_004B_01BFF6D1.3106F300-- From list@netscape.com Sun Jul 30 15:37:14 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28055 for ; Sun, 30 Jul 2000 15:37:14 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6UJQrR13293; Sun, 30 Jul 2000 12:26:53 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6UJZnY10366; Sun, 30 Jul 2000 12:35:49 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 12:35:49 -0700 (PDT) Date: Sun, 30 Jul 2000 12:35:40 -0700 (PDT) Message-Id: <200007301935.e6UJZeM22770@ywing.netscape.com> From: "Anna Steptoe" To: Valued.Consumer@netscape.com Subject: STOP WASTING YOUR TIME! X-Reply-To: "Anna Steptoe" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ZHfXcD.A.khC.UOIh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Dear Freind, Are you tired of searching different e-commerces for a certain product only to find that they don't carry it? Now you can shop for a specific product without searching multiple stores. The u2shop is a web mall that features all the sites that you've come to know and trust under one roof. You can search for a product with a simple click of a mouse using our product search and within seconds a list will appear telling you all the stores in our mall that carry that product. Stop by our mega mall at www.theu2shop.bigsmart.com and check us out. YOU'LL BE GLAD YOU DID! Shopping has never been easier! If this link does not work then please cut and paste into your address bar. _____________________________________________________________________________________ The u2shop is a secure site. We at the u2shop honor your right to privacy. Your personal information will never be loaned or sold without your written and verified consent. _____________________________________________________________________________________ If you do not wish to receive future emails from the u2shop, please notify us at honey2u2@email.com and type "Remove" in the subject field. From list@netscape.com Sun Jul 30 19:57:33 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05427 for ; Sun, 30 Jul 2000 19:57:29 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6UNopj29623; Sun, 30 Jul 2000 16:50:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6UNu1I29759; Sun, 30 Jul 2000 16:56:01 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 16:56:01 -0700 (PDT) Date: Sun, 30 Jul 2000 16:55:53 -0700 (PDT) Message-Id: <200007302355.e6UNtqw18118@xwing.netscape.com> From: myqum@sernac.cl To: mocsm@sernac.cl Subject: Free Gas xpjcd Resent-Message-ID: <"Ei8GAD.A.ZQH.QCMh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Greetings, I don't know about you, but I have been getting tired of watching prices at the pump continue to soar !!! Well, we've arranged for you to receive $255 in Cash For GAS Coupons for only $19.95. HOW CAN WE DO THIS? It's actually quite simple, The National Gasoline Retailers want Your Business. They can't survive without your business. A National Survey has shown that the average American Family spends $200 per month at the Gas Pump, so their fighting to get your money.These cash rebate represent a 10% CASH DISCOUNT to YOU the Consumer. Their hoping to develop Brand Loyalty, and that you will make other purchases: cigarettes, milk,newspapers, oil, repairs etc.. TO RECEIVE YOUR $255 CASH FOR GAS COUPONS: mailto:gas@bayareaoffice.com?subject=CASH-FOR-GAS Thank You for Your Time Spent Reading this message. ************* To be removed from all future mailings reply to: vacol@asianoffice.com?subject=remove From list@netscape.com Sun Jul 30 21:05:16 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19907 for ; Sun, 30 Jul 2000 21:05:12 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6V0wdj02913; Sun, 30 Jul 2000 17:58:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6V13no12921; Sun, 30 Jul 2000 18:03:49 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 18:03:49 -0700 (PDT) Message-ID: <3984D15F.A7B60469@netscape.com> Date: Sun, 30 Jul 2000 18:07:43 -0700 From: rweltman@netscape.com (Rob Weltman) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: d.w.chadwick@salford.ac.uk CC: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com Subject: Re: auth-response comments References: <39842ACC.22795.82A3C6C@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"4-qlq.A.lJD.0BNh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit The revised version of the draft (from April, sent to the list last week) makes it a requested response. Rob David Chadwick wrote: > > > First, please note my general aversion to unsolicited controls. > > IMO, controls should only be sent to clients which are known to > > be able to make use of the information. > > > > I would concurr with this. In the general case, the client initiates a > request and might use a control. This then gives the server the > opportunity to put related controls in the response. If the client does > not use a control, the server should assume the client is uninformed > about them. > > David > > *************************************************** > > David Chadwick > IS Institute, University of Salford, Salford M5 4WT > Tel +44 161 295 5351 Fax +44 161 745 8169 > Mobile +44 790 167 0359 > Email D.W.Chadwick@salford.ac.uk > Home Page http://www.salford.ac.uk/its024/chadwick.htm > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string MLJ9-DU5T-HV8J > > *************************************************** From list@netscape.com Mon Jul 31 02:40:50 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07296 for ; Mon, 31 Jul 2000 02:40:49 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6V6UBR14594; Sun, 30 Jul 2000 23:30:12 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6V6dBY21768; Sun, 30 Jul 2000 23:39:11 -0700 (PDT) Resent-Date: Sun, 30 Jul 2000 23:39:11 -0700 (PDT) Date: Sun, 30 Jul 2000 23:39:09 -0700 (PDT) Message-Id: <200007310639.e6V6d8w09846@xwing.netscape.com> To: glgpasm@korskew.it.netscape.com From: Subject: Earn A Serious Income From Home! Resent-Message-ID: <"qzJ9s.A.2TF.O8Rh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Work Smarter ....Not Harder!! It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays... I am searching for only 10 elite individuals with the work ethic necessary to generate a cash-flow for themselves of $2,000 - $5,000per week, and to increase that to over $20,000 per month, in as little as four to six months. And you know what? If you really have a burning desire and commitment, I guarantee you that you'll reach this explosive income! Can you read a short script to our qualified leads, and then turn the interested prospects over to our electronic sales medium? (you will not be required to do any selling.) Do you have the self-discipline to ignore the TV for a couple of hours per day? Are you looking for a legitimate home-based business opportunity, that is not multi-level marketing, or a chain-letter scheme? If you would like to build an amazing income that will grow lightning-fast and have you profit $1,000.00 every time only one prospect makes a purchase, then this is for you! You can build the business under my guidance and support without having to attend meetings or sell people things they don't need. Call NOW our TOLL FREE, PRE-RECORDED Message:1-800-583-5468 We market a real product, that pays real commissions to you, $1,000.00 per sale, just for making the initial contacts. With our turn-key lead generation systems you'll always talk to people who actually WANT to talk to you. You have nothing to lose, there's no risk involved, nor is there any obligation whatsoever, and you may be qualified to earn thousands of extra dollars per month! So call now! The call is FREE, and there is absolutely no obligation, So what have you got to lose? Call Toll Free 1-800-583-5468 P.S. You literally have a once-in-a-lifetime opportunity to GET INVOLVED NOW! Don't let this one go by. You have absolutely nothing to lose! This could be the most fascinating and profitable business of your life! Please, serious inquiries only. To be removed from our mailing list please send an email to: listremoval@unbounded.com and place remove in the subject Thank you From list@netscape.com Mon Jul 31 05:06:26 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17756 for ; Mon, 31 Jul 2000 05:06:23 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6V8xnj00196; Mon, 31 Jul 2000 01:59:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6V950w02850; Mon, 31 Jul 2000 02:05:00 -0700 (PDT) Resent-Date: Mon, 31 Jul 2000 02:05:00 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 31 Jul 2000 03:04:19 -0600 From: "Vijay Kn" To: , , Subject: Schema change notifications ... Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_A5FD1430.63026C19" Resent-Message-ID: <"2hIfu.A.Qs.7EUh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_A5FD1430.63026C19 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Olga, How does LCUP propose to handle schema updates on the remote server ? = Assume the client has cached objects and then there are schema updates on = the server-side while the client is offline - how does the client get = notified of this ?=20 Also, why not have a RootDSE attribute to let clients know if a specific = server supports LCUP ? Shadow servers hosting a naming context may not = all support LCUP.=20 Thanks Vijay >>> Olga Natkovich 07/26/00 03:46AM >>> Hi Mircea,=20 Thank you for your comments. The lack of the discussion about the = referrals in the LCUP draft was not intentional but an oversight. I will = add a discussion on this to the next revision of the document.=20 I think that, because the intent of the protocol is for the clients to = contain exactly the same data as the servers, the protocol should act as = though ManageDsaIT control is attached. We can require that clients attach = the ManageDsaIT control to the search operation. Alternatively we can = require that servers treat synchronization requests as though there is a = ManageDsaIT control attached.=20 Olga=20 =20 Mircea Pana wrote:=20 =20 Mark,=20 LCUP does not describe any specific behavior for continuation references. = The document only states that "the server returns a set of SearchResultEntr= ies that fits the client's specification.". No mention of SearchResultRefer= ences.=20 Was this the intent of the authors?=20 Assuming that for a search operation, the server would normally return = continuation references, what is supposed to happen when the same search = request contains a clientUpdate control that indicates the client's intent = to initiate a synchronization session?=20 What is supposed to happen when the server acquires knowledge of a = subordinated naming context on a different server, while synchronizing a = client? What should happen in the opposite case: when knowledge of a = subordinates naming context is removed from the server? etc.=20 Should the ManageDsaIT control be used when the client has interest in the = knowledge information and its evolution? ...quite limiting, this sounds = more like a work-around than a solution.=20 Thanks,=20 Mircea. --=_A5FD1430.63026C19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Olga,
 
How does LCUP propose to handle schema updates on the remote server = ?=20 Assume the client has cached objects and then there are schema updates on = the=20 server-side while the client is offline - how does the client get notified = of=20 this ? 
 
Also, why not have a RootDSE attribute to let clients know = if a=20 specific server supports LCUP ?  Shadow servers hosting a naming = context=20 may not all support LCUP.
 
Thanks
Vijay
 
>>> Olga Natkovich <olga@netscape.com> 07/26/00 = 03:46AM=20 >>>
Hi Mircea,

Thank you for your comments. The lack of the discussion about the = referrals=20 in the LCUP draft was not intentional but an oversight. I will add a = discussion=20 on this to the next revision of the document.=20

I think that, because the intent of the protocol is for the clients = to=20 contain exactly the same data as the servers, the protocol should act as = though=20 ManageDsaIT control is attached. We can require that clients attach the=20 ManageDsaIT control to the search operation. Alternatively we can require = that=20 servers treat synchronization requests as though there is a ManageDsaIT = control=20 attached.=20

Olga
 =20

Mircea Pana wrote:=20

 =20

Mark,=20

LCUP does not describe any specific behavior for = continuation=20 references. The document only states that "the server returns a set = of=20 SearchResultEntries that fits the client's specification.". No mention = of=20 SearchResultReferences.=20

Was this the intent of the authors?=20

Assuming that for a search operation, the server = would=20 normally return continuation references, what is supposed to happen when = the=20 same search request contains a clientUpdate control that indicates = the=20 client's intent to initiate a synchronization session?=20

What is supposed to happen when the server acquires = knowledge=20 of a subordinated naming context on a different server, while synchronizi= ng a=20 client? What should happen in the opposite case: when knowledge of a=20 subordinates naming context is removed from the server? etc.=20

Should the ManageDsaIT control be used when the = client has=20 interest in the knowledge information and its evolution? ...quite = limiting,=20 this sounds more like a work-around than a solution.=20

Thanks,
Mircea.

--=_A5FD1430.63026C19-- From list@netscape.com Mon Jul 31 10:45:59 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15092 for ; Mon, 31 Jul 2000 10:45:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6VEVkR14836; Mon, 31 Jul 2000 07:31:46 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6VEekk06873; Mon, 31 Jul 2000 07:40:46 -0700 (PDT) Resent-Date: Mon, 31 Jul 2000 07:40:46 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" Date: Mon, 31 Jul 2000 15:40:00 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Syntax Issues Reply-to: d.w.chadwick@salford.ac.uk CC: "Jim Sermersheim" , Message-ID: <39859DD0.21262.DD38771@localhost> Priority: normal In-reply-to: <4.3.2.7.0.20000730053317.00b0a730@router.boolean.net> References: <39842ACB.21649.82A3668@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"0T4HDB.A.HrB.t_Yh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date sent: Sun, 30 Jul 2000 05:35:35 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: Syntax Issues Copies to: "Jim Sermersheim" , , > My opinion is that if you want more than BLOB semantics, then > you need to define a new syntax. However, new syntaxes should > have a string representation. Agreed. This is what has been done in the past, and I have done for certificates and CRLs David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Mon Jul 31 13:46:42 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16351 for ; Mon, 31 Jul 2000 13:46:41 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6VHaVR10639; Mon, 31 Jul 2000 10:36:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6VHjWs12319; Mon, 31 Jul 2000 10:45:32 -0700 (PDT) Resent-Date: Mon, 31 Jul 2000 10:45:32 -0700 (PDT) Message-Id: <200007311745.KAA20672@lsmls01.we.mediaone.net> Date: Mon, 31 Jul 00 10:40:27 Pacific Daylight Time From: "My Girl Productions" Subject: $$Successful Internet Mailing Program with a Safety Catch$$ To: X-Bulk-ID: ESHOP422301:50331648 X-Originating-IP: [192.168.0.3] X-Mailer: Email Workshop version 1 from Word Place, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="25HF53MM86DU55ZN12RY98YY" Resent-Message-ID: <"HvWyfC.A.NAD.6sbh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --25HF53MM86DU55ZN12RY98YY Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There is an Accountability list to ensure that ALL PARTICIPANTS Get paid. You cannot lose. Invest JUST $10 and see a return of $40,000 in 45 DAYS sometimes a little longer. For FREE details DO NOT PRESS REPLY email me at MyGirl411@email.com **NOTE: put PHASE 1 in Subject box! ***THIS IS NOT SPAM*** I am sending you this because we have exchanged business opportunities in the past regarding a work from home opportunity. If you have received this email by error and do not wish to receive more info regarding this opportunity, Please REPLY to MyGirl411@email.com and put remove in the subject line. Prosperous Regards, Candis --25HF53MM86DU55ZN12RY98YY Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There is an Accountability list to ensure that ALL PARTICIPANTS Get paid= . You cannot lose. Invest JUST $10 and see a return of $40,000 in 45 DAYS s= ometimes a little longer. For FREE details
DO NOT PRESS REPLY email me at MyGirl411@email.com
**NOTE: put PHASE 1 in Subject box!

***THIS IS NOT SPAM*** I am sending you this because we have exchanged b= usiness opportunities in the past regarding a work from home opportunity.
If you have received this email by error and do not wish to receive more= info regarding this opportunity, Please REPLY to MyGirl411@email.com and put remove in the subject = line.

Prosperous Regards, Candis




--25HF53MM86DU55ZN12RY98YY-- From list@netscape.com Mon Jul 31 19:49:13 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10493 for ; Mon, 31 Jul 2000 19:49:12 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6VNcUR05752; Mon, 31 Jul 2000 16:38:35 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e6VNlWc14474; Mon, 31 Jul 2000 16:47:32 -0700 (PDT) Resent-Date: Mon, 31 Jul 2000 16:47:32 -0700 (PDT) Date: Mon, 31 Jul 2000 15:33:23 -0700 (PDT) Message-Id: <200007312233.e6VMXNw05920@xwing.netscape.com> From: bestbetyet2000@angelfire.com To: Friends@netscape.com Subject: Big Weekly Returns Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ZgV4WB.A.0hD.SAhh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hello Friends, I have a program that might well interest you. Here's the basic program. Receive 15% weekly on any money invested. That's a whopping 60% monthly! Minimum to invest is $110. To get more details send to: bestbetyet2000@angelfire.com Thank you for your time. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter Cannot be considered Spam as long as the sender includes "contact information" & a method of "removal". To be removed, simply type: "remove" in the subject box. Thank You Once Again From list@netscape.com Mon Jul 31 20:43:35 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17796 for ; Mon, 31 Jul 2000 20:43:34 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e710avj00677; Mon, 31 Jul 2000 17:36:57 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e710g9g06471; Mon, 31 Jul 2000 17:42:09 -0700 (PDT) Resent-Date: Mon, 31 Jul 2000 17:42:09 -0700 (PDT) Date: Mon, 31 Jul 2000 17:41:56 -0700 (PDT) Message-Id: <200008010041.e710fuM26668@ywing.netscape.com> From: survey123@hotmail.com To: .WYRP@netscape.com Subject: Get an Honest answer -FCVS X-Reply-To: survey123@hotmail.com Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"puJeMB.A.zkB.fzhh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit

Get anyones Sex & Relationship

Survey ANSWERS Sent to You

Are you good in bed?

How does your significant other really rate sex with you?

Have they ever been unfaithful?

Are you really the only one your spouse has slept with?

How many people have they really been with before they met you?

Want to know an HONEST answer to these and over 50 other intimate questions about their relationship, sex life and faithfulness.

Let SURVEYS-R-US help you get THEIR ANSWERS.

Through our anonymous surveys you can learn ANYONE'S HONEST answers to questions you would love to know but can never bring up. Answers they are not afraid to reveal to an anonymous survey but would never tell you.

Visit our site to see sample survey questions and learn more.

Copy or type this address into your browser.

clik.to/surveys

To remove hit REPLY and type remove in the subject line. From list@netscape.com Mon Jul 31 22:09:05 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05345 for ; Mon, 31 Jul 2000 22:09:04 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e711skR22593; Mon, 31 Jul 2000 18:54:46 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e7123mA03616; Mon, 31 Jul 2000 19:03:48 -0700 (PDT) Resent-Date: Mon, 31 Jul 2000 19:03:48 -0700 (PDT) Date: Mon, 31 Jul 2000 19:03:38 -0700 (PDT) Message-Id: <200008010203.e7123YM18375@ywing.netscape.com> From: help@mymail.com To: You.NNBQ@netscape.com Subject: Please Read! -YOVA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Jvmz0.A.H4.DAjh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit $10,000 per month GUARANTEED! We've all seen messages like this, and I hope that you too are doing well with your program. However, today I'd like to take a break from the usual money making matters for a moment if I may, and address something immensely more important to all of us. For what shall it profit a man if he gain the whole world, and lose his soul? ( Matthew 6:21 ) The biggest and most dramatic need of mankind is to become right with God. To become right with God is to become saved from God's wrath and be renewed by the Holy Spirit and be given eternal life (Matthew 25:46). This is called salvation. What is salvation, and how can one become saved? The moment of salvation is the moment of truth, when we take off our rose-colored glasses through which we thought that somehow all would be well with us, and we stop kidding ourselves that we are really rather fine people. The moment of truth is when we take our heads out of the sand and face the truth about ourselves. One truth that we learn from the Scriptures is that we are desperately wicked. The Bible declares in Jeremiah 17:9, "The heart is deceitful above all things, and desperately wicked: who can know it?" The Bible says in Romans 3:10-18: As it is written, There is none righteous, no, not one: There is none that understandeth, there is none that seeketh after God. They are all gone out of the way, they are together become unprofitable; there is none that doeth good, no, not one. Their throat is an open sepulchre; with their tongues they have used deceit; the poison of asps is under their lips: Whose mouth is full of cursing and bitterness: Their feet are swift to shed blood: Destruction and misery are in their ways: And the way of peace have they not known: There is no fear of God before their eyes. These verses tell us of a horrible truth that we must honestly and frankly face. God is telling us that we are like poisonous snakes. God is telling us that we are altogether rebellious against Him in every fiber of our beings. All the good things that we have been doing are not at all pleasing to God; we do them for our own selfish reasons or because we think that through them, God will look with favor upon our spiritual corpses in which we have no life. Moreover, we are enslaved to Satan, who is our master if we are unsaved (Ephesians 2:1-3). Another truth that we must face is that because of our sins, we are under the wrath of God. God's Word declares in Romans 6:23, "the wages of sin is death." The death that God has in view is not merely physical death but it is spiritual death. That is, God declares that because of our sins, we must be eternally in hell under the wrath of God, paying for our sins. God created us good and after His image; therefore, we are accountable to Him for our actions. God says in Matthew 12:36, "But I say unto you, That every idle word that men shall speak, they shall give account thereof in the day of judgment." Our thoughts, words, and deeds, when viewed in the light of the perfection of the law of God, will prove beyond a doubt that we are sinners. To pay for these sins, we must be cast into hell and suffer eternal damnation. What a heartbreaking, impossible future there is for us if we are unsaved. We might have thought we were good people with the best still to come in our lives, and now we discover the awful fact that we are corrupt sinners subject to the eternal wrath of God. Can there be salvation? Can there be a way of escape from this horrible predicament? Another truth that we must face is that God has provided a marvelous, glorious, wonderful way of escape from our sins and the wrath of God, and that way is through the Lord Jesus Christ. The Bible tells us to believe in the Lord Jesus Christ (John 3:16). God so loved the world that He not only provided for the redemption of the universe, but He also provided for the redemption of those who recognize their bankrupt spiritual condition and cast themselves on the mercy of God. For these people, Christ became sin (II Corinthians 5:21), that is, Christ took all their sins upon Himself. As our substitute, He was judged by God as He stood before the Roman governor, Pilate. Christ was found guilty for these sins, and God poured out His wrath on Him as He, as our substitute, paid for these sins. Wonderfully, we do not have to understand how all this happened. However, it is imperative that we recognize the truth that in Christ and only in Christ is there salvation. Somehow, through Christ, God's wrath has been satisfied, and we are no longer under condemnation before God. The Bible declares in Romans 8:1, "There is therefore now no condemnation to them which are in Christ Jesus, who walk not after the flesh, but after the Spirit." Those who have placed their trust in Christ have realized their hopelessly sinful and lost condition. They realize that their sins were sending them to hell; they have begun to see the terrible nature of sin, and within their lives, there is a tremendous desire to turn from their sins. They know that Christ must be Lord of their lives. Because Christ is God who has given us His Word, the Bible, they begin to have an ongoing desire to know more and more about His Word. As they learn from God's Word, they want increasingly to be obedient to all that they find there. The Bible declares in I John 1:9, "If we confess our sins, he is faithful and just to forgive us our sins, and to cleanse us from all unrighteousness." This verse teaches us that somehow through Christ, those who trust God will have their sins forgiven. This is what salvation is -- to be saved from the wrath of God, which we otherwise deserve because of our sins. Salvation is to abandon ourselves to Christ as our only Lord and Savior. Before we are saved, both in body and soul, we are spiritually dead; we lust after sin. We are in rebellion against God and we are slaves of Satan. By God's mercy, He reaches down into our lives and begins to open our spiritual eyes and spiritual ears so that we see our utter sinfulness, and we begin to hear from God's Word the importance of turning to Christ as our only Savior, the only Way by which we can be reconciled to God the Father. As God works within our hearts, we begin to more and more sense our terrible predicament. We realize that we are only a breath away from eternity; and if we die without the Savior, we will eternally be in hell. In our uneasiness, we begin to cry to God for help. As the publican of old, we pray, "God be merciful to me a sinner" (Luke 18:13). At some point, unknown to us, God gives us brand new souls. The soul is the spirit essence of man. The soul is the part of man that leaves the body at death. If we are saved, it is in our souls that we go to live and reign with Christ in heaven. It is in our souls that we experience eternal life. It is in our souls that we become born again. It is in our souls that we are new creatures. It is in our souls that we have been raised with Christ, that is, we have experienced the resurrection. It is in our souls that we never wish to sin again. It is in our saved souls that we have an ongoing, never-ending desire to be obedient to God's Word. Because our souls are brand new after we are saved, our lives are quite different from what they were before salvation. It is true that in our bodies, we still lust after sin. Our bodies have not yet experienced the resurrection. But because we have received our new souls, we feel terrible when we sin. In our new souls, we feel violated by our sin. Therefore, we find true happiness only as we live obediently before God. Increasingly, then, we deny the lusts of the sin which our bodies crave, and we focus on the Lord Jesus Christ, whom we earnestly love and who has become the Lord of our lives. Oh, it is my sincere desire that you will come to believe this truth, as time is getting very short for us all. May the Lord bless you and give you a heart to love Him and follow Him, so that you too, may glory in Him, and in the everlasting joys of heaven, for how shall we escape the great judgment day of God if we neglect His wonderful, merciful plan of salvation? TODAY is the day of salvation my friend. Please, don't put it off till tomorrow, for you may not have tomorrow! Many of us will not! Remember, all our days are numbered! Each and every day over 145,000 people die, and the majority of them had absolutely no idea that this would be their last day! God is here right now watching you as you read this message. What will you do with it? Will you turn to Him for forgiveness, or will you continue to stick your head in the sand and hope that all will turn out well? It's your soul that we are talking about dear friend, please believe this truth and act ont it today! Time is running out on us all. I want you to know that I am praying for you. I also must add that this is NOT SPAM! God's word is NEVER spam!y From list@netscape.com Mon Jul 31 23:05:54 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13326 for ; Mon, 31 Jul 2000 23:05:53 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e712tRR27247; Mon, 31 Jul 2000 19:55:27 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e7134Ss18743; Mon, 31 Jul 2000 20:04:28 -0700 (PDT) Resent-Date: Mon, 31 Jul 2000 20:04:28 -0700 (PDT) Message-Id: <4.2.2.20000731215857.00a37300@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 31 Jul 2000 22:03:05 -0500 To: ietf-ldapext@netscape.com, Mark Wahl From: Ellen Stokes Subject: ldap access control meeting Tues Aug 1 1300-1500, meet at message board Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_922077==_" Resent-Message-ID: <"2oP9JD.A.lkE.74jh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=====================_922077==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Here's the slides I presented on access control status. I'll be using these as the basis for the ldap access control meeting scheduled for Tues Aug 1 1300-1500 - meet at the message board. Ellen --=====================_922077==_ Content-Type: application/octet-stream; name="aug2000ietfldapextaci.ppt"; x-mac-type="534C4433"; x-mac-creator="50505433" Content-Disposition: attachment; filename="aug2000ietfldapextaci.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAA EAAAHAAAAAEAAAD+////AAAAAAEAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////9S AG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFgAFAP//////////AQAAABCNgWSbT88RhuoAqgC5KegAAAAAAAAAAAAAAACgJg2SZPu/ AREAAABAAwAAAAAAAFAAbwB3AGUAcgBQAG8AaQBuAHQAIABEAG8AYwB1AG0AZQBuAHQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAgAAADRmAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEEAAAA//////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAAAjBMAAAAAAAAFAEQAbwBjAHUAbQBlAG4A dABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADMAgAAAAAAABAA AAD9////AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAA AB4AAAD+////HQAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAAP7////+//// /v///x8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAs AAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoA AAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAAD+//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////DwDo A90IAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAIAAAAAAAAAAQAAAAAAAAEPAPID 8AAAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB0wAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAAOLZiADi2YgBEsmIA+NMDMGiyYgAIAAAAaLJiAH7UAzAAAAYSAACpDwoA AAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABAAgAAAAAC AAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2AD AAAAAAAFAACABIAEAAAAAA8ACwSEAAAADwAA8HwAAAAAAAbwMAAAAAgQAAAFAAAAEwAAAAQAAAAB AAAABwAAAAIAAAAEAAAAAwAAAAQAAAAEAAAACAAAAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAA wAEBAAAI/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAA AAMAAAAAAAAAAAAAAAAAAIAAAAAADwDQB4sAAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABN AAAAZAAAAE0AAABkAAAAdLJiAH7UAzBssmIACAAAAKYXAACwDQAA1vz//6b///8BAAAAcAD7AwgA AAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAPwDZ D3IAAAAAANoPBAAAAAAALQAAALoPGAAAADMAMQAgAEoAdQBsAHkAIAAyADAAMAAwACAAug8+AAAA ZAByAGEAZgB0AC0AaQBlAHQAZgAtAGwAZABhAHAAZQB4AHQALQBhAGMAbAAtAG0AbwBkAGUAbAAt ADAANgBPANkPDAAAAAAA2g8EAAAAAAA9AA8A8A/UBQAAAADzAxQAAAAEAAAAAAAAAAIAAAAAAQAA AAAAAAAAnw8EAAAAAAAAAAAAqA8SAAAAU3VtbWFyeSBvZiBDaGFuZ2VzAAChDxwAAAATAAAAAAAA AAAAEgAAAAAAAgAkAAEAAAAAAAAAEACfDwQAAAABAAAAAACoDxoCAABCTkYgcGVyIFJGQyAyMjM0 OyB1cGRhdGVkIGV4YW1wbGVzIHRvIHJlZmxlY3QgbmV3IEJORiANQWRkZWQgYmFjayBtdWx0aXBs ZSBsaXN0IG9mIGF0dHJpYnV0ZXM7IHJlbW92ZWQgY29sbGVjdGlvbnMgDXVwZGF0ZWQvZXhwYW5k ZWQgc2V0IG9mIHBlcm1pc3Npb25zIGFuZCB0aGVpciBkZXNjcmlwdGlvbnMgDUNsYXJpZmljYXRp b24gb2YgaW50ZXJhY3Rpb25zIG9mIHByZWNlZGVuY2VzIGFuZCBldmFsdWF0aW9ucyANYWRkZWQg YWNjZXNzIGRlY2lzaW9uIGFsZ29yaXRobSBzbyBub3RoaW5nIGludHVpdGVkIGZyb20gZXhhbXBs ZXMgDUFkZGVkIHN0cmVuZ3RoIG9mIGF1dGhlbnRpY2F0aW9uIG9wdGlvbiBpbnRvIEFDSSBzeW50 YXggYmFzZWQgb24gbGRhcCBiaW5kIA1JbmNvcnBvcmF0ZWQgYXV0aG1ldGggaWQgZm9ybWF0IGlu dG8gc3ViamVjdCBjb21wb25lbnQgb2YgbGRhcGFjaSAocmVtb3ZlZCBrZXJiZXJvcyBmb3JtYXQp IA1pcEFkZHJlc3MgZm9ybWF0IGV4cGFuZGVkIHRvIGluY2x1ZGUgZG9tYWluIG5hbWVzIGFuZCB3 aWxkY2FyZHMgAAChDxgAAAAbAgAAAAAAYAAA2P/Y/xsCAAAAAAIAGAAAAKoPPgAAALYBAAAAAAAA CAAAAAEAAAADAAkAAAAAAAAACQAAAAEAAAADAAgAAAAAAAAACwAAAAEAAAADADgAAAAAAAAAAADz AxQAAAAFAAAAAAAAAAIAAAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8eAAAAU3VtbWFyeSBvZiBD aGFuZ2VzIChjb250aW51ZWQpAAChDxwAAAAfAAAAAAAAAAAAHgAAAAAAAgAkAAEAAAAAAAAAEACf DwQAAAABAAAAAACoD+4BAABhZGRlZCBhYmlsaXR5IHRvIGNvbnRyb2wgYWNjZXNzIHRvIEFDSTsg cmVtb3ZlZCBwb2xpY3kgb3duZXIgDWRlZmluZWQgbGRhcEFDSVN1YkVudHJ5IHRvIGFsbG93IHNw ZWNpZmljYXRpb24gb2YgYW55IGFjY2VzcyBjb250cm9sIG1lY2hhbmlzbSBhbnl3aGVyZSBpbiB0 aGUgdHJlZSANYWRkcmVzc2VkIGhvdyBhbGlhcyBkZS1yZWZlcmVuY2luZyBhbmQgcmVmZXJyYWxz IHdvcmsgd2l0aCByZXNwZWN0IHRvIGFjY2VzcyBjb250cm9sIA1WZXJzaW9uaW5nIGxkYXBBQ0k6 IGNvbmNsdWRlZCB0aGF0IGEgZGlmZmVyZW50IGF0dHJpYnV0ZSB3b3VsZCBiZSB1c2VkIGluIHN1 YnNlcXVlbnQgUkZDcyBvbiBsZGFwIGFjY2VzcyBjb250cm9sDXVwZGF0ZWQgdGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHNlY3Rpb25zIA11cGRhdGVkL2V4cGFuZGVkIGRlc2NyaXB0aW9uIG9m IHRoZSBhY2Nlc3MgY29udHJvbCBtb2RlbCANcmVtb3ZlZCB0ZXJtaW5vbG9neSBzZWN0aW9uDQAA oQ8qAAAA7gEAAAAAAGAAANj/2P8BAAAAAAAAAAAA7gEAAAAAAgAYAAEAAAAAAAAAAACqDywAAABF AAAAAAAAABAAAAABAAAAAwD4AAAAAAAAAAUAAAABAAAAAwCdAAAAAAAAAAAA6gMAAAAADwD4A3UI AAACAO8DGAAAAAEAAAABAgcJCAAAAAAAAAAAAAAAAAAAAGAA8AcgAAAA////AAAAAACAgIAAAAAA AADMmQAzM8wAzMz/ALKysgBgAPAHIAAAAAAA/wD///8AAAAAAP//AAD/mQAAAP//AP8AAACWlpYA YADwByAAAAD//8wAAAAAAGZmMwCAgAAAM5kzAIAAAAAAM8wA/8xmAGAA8AcgAAAA////AAAAAAAz MzMAAAAAAN3d3QCAgIAATU1NAOrq6gBgAPAHIAAAAP///wAAAAAAgICAAAAAAAD/zGYAAAD/AMwA zADAwMAAYADwByAAAAD///8AAAAAAICAgAAAAAAAwMDAAABm/wD/AAAAAJkAAGAA8AcgAAAA//// AAAAAACAgIAAAAAAADOZ/wCZ/8wAzADMALKysgAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAAAAEA ZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP///////ywAAAAAAwAAEACjD3wAAAAFAP/9PwAB ACIgAABkAAAAAAAAAGQAFAAAANgAAABAAgAAAAACAAAA///vAAAAAAD///////8gAAAAAAEAAIAF AAATINQBIAEAAAIAHACABQAAIiDQAkACAAACABgAgAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQA AAAAIACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAAAABAAgAAAAACAAAA///vAAAA AAD///////8MAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACA BIAEAAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAAAAAAAQABCQAAAAABACABAAAAAAIAAQkAAAAA AQBAAgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAAAAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAA AAAAcACjDz4AAAAFAAAAAAAAAAAAAgAcAAEAAAAAAAAAAgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAA AgASAAQAAAAAAAAAAgASAIAAow8+AAAABQAAAAAAAAAAAAIAGAABAAAAAAAAAAIAFAACAAAAAAAA AAIAEgADAAAAAAAAAAIAEAAEAAAAAAAAAAIAEAAPAAwE0wQAAA8AAvDLBAAAEAAI8AgAAAAGAAAA BgQAAA8AA/BjBAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAF AAAADwAE8NIAAAASAArwCAAAAAIEAAAACgAAkwAL8DYAAAB/AAEAAQCAAJQhdgCHAAEAAACBAQQA AAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAA AMMLCAAAAAAAAAABAHYADwAN8FQAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQg TWFzdGVyIHRpdGxlIHN0eWxlAACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwFgEA ABIACvAIAAAAAwQAAAAKAACDAAvwMAAAAH8AAQABAIAAVCJ2AIEBBAAACIMBAAAACL8BAQARAMAB AQAACP8BAQAJAAECAgAACAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAAIAdgAP AA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHls ZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8e AAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8LUA AAASAArwCAAAAAQEAAAACgAAgwAL8DAAAAB/AAEAAQCAALQidgCBAQQAAAiDAQAAAAi/AQEAEQDA AQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAPsAFgBoAQDwAR8BAAAAAAAMMLCAAAAAIAAAAHAXYA DwAN8D0AAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAACAA4A AAD4DwQAAAAAAAAADwAE8LcAAAASAArwCAAAAAUEAAAACgAAgwAL8DAAAAB/AAEAAQCAABQjdgCB AQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAPsAfQDoAQDwAR8BAA AAAAAMMLCAAAAAMAAAAJAnYADwAN8D8AAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPFgAAAAIA AAAAAAAIAAABAAIAAAAAAAIADgAAAPoPBAAAAAAAAAAPAATwtwAAABIACvAIAAAABgQAAAAKAACD AAvwMAAAAH8AAQABAIAAdCN2AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAA EPAIAAAAYA8gENAUgBAPABHwEAAAAAAAwwsIAAAABAAAAAgCdgAPAA3wPwAAAAAAnw8EAAAABAAA AAAAqA8BAAAAKgAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAOAAAA2A8EAAAAAAAAAA8ABPBI AAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA /wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKy AA8A8APeBQAAAQDxAwgAAAAAAACAAAAMMA8ADASeBQAADwAC8JYFAABAAAjwCAAAAAcAAAAHEAAA DwAD8C4FAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAD/////AAAAAAIACvAIAAAAABAAAAUAAAAP AATw0QAAABIACvAIAAAAAhAAAAAKAACDAAvwMAAAAH8AAQABAIAAhPl8AIEBBAAACIMBAAAACL8B AQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAAAAAAFAHIAEPABHwEAAAAAAAwwsIAAAAAAAA AAoCfAAPAA3wWQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAA AAIADAAAAPkPBAAAAAAAAAAAAKoPFAAAAAEAAAABAAAAAAABAAAAAQAAAAAADwAE8NMAAAASAArw CAAAAAMQAAAACgAAgwAL8DAAAAB/AAEAAQCAAOT5fACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/ AQEACQABAgIAAAgAABDwCAAAAAAAkAngECABDwAR8BAAAAAAAMMLCAAAAAEAAAAHAHwADwAN8FsA AAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADAAAAPgP BAAAAAAAAAAAAKoPFAAAAAEAAAABAAAAAAABAAAAAQAAAAAADwAE8GQAAAASAArwCAAAAAQQAAAA CgAAYwAL8CQAAAB/AAQABACHAAEAAAB/AQAAAQC/AREAEQD/AQgACQA/AgEAAQAAABDwCAAAALAB 0AIQDiAKDwAR8BAAAAAAAMMLCAAAAAIAAAAFAHwADwAE8BYBAAASAArwCAAAAAUQAAAACgAAgwAL 8DAAAAB/AAEAAQCAAET6fACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDw CAAAALAKQAKgDtAUDwAR8BAAAAAAAMMLCAAAAAMAAAAGAnwADwAN8J4AAAAAAJ8PBAAAAAIAAAAA AKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGly ZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAAC AA0AAAADAAwAAAAEAAAAqg8KAAAAUwAAAAEAAAAAAA8ABPDXAAAAEgAK8AgAAAAGEAAAAAoAAJMA C/A2AAAAfwABAAEAgACk+nwAhwACAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQIC AAAIAAAQ8AgAAABgFQAAUAeAFg8AEfAQAAAAAADDCwgAAAAEAAAACQJ8AA8ADfBZAAAAAACfDwQA AAAEAAAAAACoDwEAAAAqAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAMAAAA+g8EAAAAAAAAAAAA qg8UAAAAAQAAAAEAAAAAAAEAAAABAAAAAAAPAATw2QAAABIACvAIAAAABxAAAAAKAACTAAvwNgAA AH8AAQABAIAABPt8AIcAAgAAAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAA EPAIAAAAYBWQCeAQgBYPABHwEAAAAAAAwwsIAAAABQAAAAgCfAAPAA3wWwAAAAAAnw8EAAAABAAA AAAAqA8BAAAAKgAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAMAAAA2A8EAAAAAAAAAAAAqg8U AAAAAQAAAAEAAAAAAAEAAAABAAAAAAAPAATwSAAAABIACvAIAAAAARAAAAAMAACDAAvwMAAAAIEB AAAACIMBBQAACJMB3r1oAJQBjp+LAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA//// AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4D2AEAAAIA7wMYAAAAAQAAAA0OAAAAAAAA AAAAgAAAAAAHAAAADwAMBIgBAAAPAALwgAEAACAACPAIAAAAAwAAAAMIAAAPAAPwGAEAAA8ABPAo AAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPBsAAAAEgAK8AgA AAACCAAAIAIAAEMAC/AYAAAAgADUJnYAvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAAAAALAB0BTQ Ag8AEfAQAAAAAADDCwgAAAAAAAAADQB8AA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8GwAAAASAArw CAAAAAMIAAAgAgAAQwAL8BgAAACAADQndgC/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAKACsAHQ FAAPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAHwADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIA CvAIAAAAAQgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAI AAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4D 2AEAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAAADwAMBIgBAAAPAALwgAEAADAACPAI AAAAAwAAAAMMAAAPAAPwGAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAIA66AIEAAAIAgAK8AgA AAAADAAABQAAAA8ABPBsAAAAEgAK8AgAAAACDAAAIAIAAEMAC/AYAAAAgAAk9nwAvwEAAAEA/wEA AAEAAQMCBAAAAAAQ8AgAAAAAALAB0BQAAw8AEfAQAAAAAADDCwgAAAAAAAAADQB8AA8ADfAMAAAA AACeDwQAAAAAAAAADwAE8GwAAAASAArwCAAAAAMMAAAgAgAAQwAL8BgAAACAAOT2fAC/AQAAAQD/ AQAAAQABAwMEAAAAABDwCAAAANACsAHQFAAPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAHwADwAN8AwA AAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAQwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAA CJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAA AAAAAADMmQAzM8wAzMz/ALKysgAAAHIXGAAAAAEAUAAAAAAAYhEAAOUIAABIFwAAKBkAAAAA9Q8c AAAAAAEAAIMVAAMAAAAACBsAAAEAAAAFAAAAAQAAAA8A6AP4DAAAAQDpAygAAACAFgAA4BAAAOAQ AACAFgAABQAAAAoAAAACAAAAAAAAAAEAAAAAAAABDwDyA/AAAAAvAMgPDAAAADAA0g8EAAAAAAAA AA8A1QdMAAAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAABy2YgActmIA KLJiAPjTAzBMsmIACAAAAEyyYgB+1AMwAAAGEgAAqQ8KAAAABwAAAEMAdQByAHIAZQBuAHQAIABV AHMAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAACwAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAA AAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rjQCAADwAQAAEAAA AAEAAACIAAAAAwAAAJAAAAAPAAAAqAAAAAQAAAC0AAAABgAAALwAAAAHAAAAxAAAAAgAAADMAAAA CQAAANQAAAAKAAAA3AAAABcAAADkAAAACwAAAOwAAAAQAAAA9AAAABMAAAD8AAAAFgAAAAQBAAAN AAAADAEAAAwAAACPAQAAAgAAAOQEAAAeAAAADwAAAE9uLXNjcmVlbiBTaG93AAAeAAAABAAAAElC TQADAAAANGYAAAMAAAAeAAAAAwAAAAMAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAADAAAAMRUI AAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAUAAAAQAAAAVGltZXMgTmV3IFJv bWFuAA8AAABEZWZhdWx0IERlc2lnbgATAAAAU3VtbWFyeSBvZiBDaGFuZ2VzAB8AAABTdW1tYXJ5 IG9mIENoYW5nZXMgKGNvbnRpbnVlZCkAFgAAAE5ldyBDb21tZW50cyBvbiBEcmFmdAAMEAAABgAA AB4AAAALAAAARm9udHMgVXNlZAADAAAAAQAAAB4AAAAQAAAARGX+/wAABAACAAAAAAAAAAAAAAAA AAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAABcEwAACwAAAAEAAABgAAAAAgAAAGgAAAAEAAAA hAAAAAgAAACcAAAACQAAALQAAAASAAAAwAAAAAoAAADgAAAADAAAAOwAAAANAAAA+AAAAA8AAAAE AQAAEQAAAAwBAAACAAAA5AQAAB4AAAATAAAAU3VtbWFyeSBvZiBDaGFuZ2VzAAAeAAAADQAAAEVs bGVuIFN0b2tlcwBhbmceAAAADQAAAEVsbGVuIFN0b2tlcwBhbmceAAAAAgAAADYAbGUeAAAAFQAA AE1pY3Jvc29mdCBQb3dlclBvaW50AABQAEAAAADgWx/OCAAAAEAAAACAV9QSivq/AUAAAABgs/Pg kvq/AQMAAAAHAQAARwAAAEYSAAD/////AwAAAAgAbxBNDAAAAQAJAAADGwkAAAYAYQAAAAAAEQAA ACYGDwAYAP////8AABAAAAAAAAAAAAC6AwAAygIAAAkAAAAmBg8ACAD/////AgAAABcAAAAmBg8A IwD/////BAAbAFROUFAUAMjwADAAAAAAFAAAAEQNdgAAAAAAAAAKAAAAJgYPAAoAVE5QUAAAAgD0 AwkAAAAmBg8ACAD/////AwAAAA8AAAAmBg8AFABUTlBQBAAMAAEAAAABAAAAAAAAAAUAAAALAgAA AAAFAAAADALKAroDBAAAAAQBDQAHAAAA/AIAAP///wAAAAQAAAAtAQAACQAAAPoCBQAAAAAA//// ACIABAAAAC0BAQAEAAAALQEAAAkAAAAdBiEA8ADQAsADAAAAAAQAAAAtAQAABAAAAC0BAAAJAAAA +gIAAAAAAAAAAAAAIgAEAAAALQECABAAAAAmBg8AFgD/////AABHAAAAjwIAABEBAADBAgAACAAA ACYGDwAGAP////8BAA0AAAD7AgAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAFAAAACQIAAAAC BQAAABQCAAAAABUAAAD7Au3/AAAAAAAAkAEAAAAAAAAAElRpbWVzIE5ldyBSb21hbgAVAAQAAAAt AQQABAAAAPABAwAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAZAAAAMgqnAlIA DAAAADMxIEp1bHkgMjAwMAkACgAEAAgACQAFAAoABAAKAAkACQAKAAQAAAAuAQEABAAAAAIBAgAE AAAAAgECABAAAAAmBg8AFgD/////AABHAQAAjwIAAHkCAADBAgAACAAAACYGDwAGAP////8BAAUA AAAJAgAAAAIFAAAAFAIAAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEANgAA ADIKpwJsAR8AAABkcmFmdC1pZXRmLWxkYXBleHQtYWNsLW1vZGVsLTA2AAkABwAIAAYABQAGAAYA CAAFAAYABgAGAAkACAAKAAgACQAFAAcACAAIAAUABwAOAAkACgAIAAUABgAKAAkABAAAAC4BAQAE AAAAAgECAAQAAAACAQIAEAAAACYGDwAWAP////8AAK8CAACPAgAAeQMAAMECAAAIAAAAJgYPAAYA /////wEABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAA AAIBAQAJAAAAMgqnAmUDAQAAADEACQAEAAAALgEBAAQAAAACAQIABAAAAAIBAgAHAAAA/AIBAAAA AAAAAAQAAAAtAQMABAAAAC0BAQAHAAAAGwR5AHkDAABIAAQAAAAtAQAABAAAAC0BAgAFAAAACQIA AAACBQAAABQCAAAAABUAAAD7AtD/AAAAAAAAkAEAAAAAAAAAElRpbWVzIE5ldyBSb21hbgAhAAQA AAAtAQUABAAAAPABBAAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAiAAAAMgpO ABABEgAAAFN1bW1hcnkgb2YgQ2hhbmdlcxsAGAAlACUAFgAQABgADAAYABAADAAgABgAFQAYABgA FQATAAQAAAAuAQEABAAAAAIBAgAEAAAAAgECAAQAAAAtAQMABAAAAC0BAQAHAAAAGwSBAnkDcABI AAQAAAAtAQAABAAAAC0BAgAFAAAACQIAAAACBQAAABQCAAAAABUAAAD7AuD/AAAAAAAAkAEAAAAA AAAAElRpbWVzIE5ldyBSb21hbgAVAAQAAAAtAQQABAAAAPABBQAFAAAACQIAAAACBQAAABQCAAAA AAQAAAAuARgABAAAAAIBAQAIAAAAMgqUAFIAAQAAAJUABAAAAC4BAQAEAAAAAgECAAUAAAAJAgAA AAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBAFcAAAAyCpQAdgA1AAAAQk5GIHBlciBSRkMgMjIz NDsgdXBkYXRlZCBleGFtcGxlcyB0byByZWZsZWN0IG5ldyBCTkYAFQAYABEACAAQAA8ACgAIABYA EQAWAAgAEAAQABAAEAAJAAgAEAAQABAADgAJAA4AEAAIAA4AEAAOABkAEAAJAA4ADAAIAAkAEAAI AAsADgALAAkADgAOAAkACAAQAA4AFwAIABYAFwASAAQAAAAuAQEABAAAAAIBAgAFAAAACQIAAAAC BQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAIAAAAMgrHAFIAAQAAAJUABAAAAC4BAQAEAAAAAgEC AAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBAGAAAAAyCscAdgA7AAAAQWRkZWQg YmFjayBtdWx0aXBsZSBsaXN0IG9mIGF0dHJpYnV0ZXM7IHJlbW92ZWQgY29sbGVjdGlvbnMAFwAQ ABAADgAQAAgAEAAPAA4AEAAIABkAEAAIAAkACQAQAAkADgAIAAkACQAMAAkACAAQAAsACAAOAAkA CQAKAAkAEAAQAAkADgANAAgACAALAA4AGQAQABAADgAQAAgADgAQAAkACQAOAA8ACAAJABAAEAAN AAQAAAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAIAAAA Mgr7AFIAAQAAAJUABAAAAC4BAQAEAAAAAgECAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAE AAAAAgEBAF4AAAAyCvsAdgA6AAAAdXBkYXRlZC9leHBhbmRlZCBzZXQgb2YgcGVybWlzc2lvbnMg YW5kIHRoZWlyIGRlc2NyaXB0aW9ucxAAEAAQAA4ACQAOABAACQAOABAAEAAOABAAEAAPABAACAAM AA4ACQAIABAACwAIABAADgALABgACQANAAwACQAQABAADQAIAA4AEAAQAAgACQAQAA4ACQAKAAgA EAAOAA0ADgALAAkAEAAJAAgAEAAQAA0ABAAAAC4BAQAEAAAAAgECAAUAAAAJAgAAAAIFAAAAFAIA AAAABAAAAC4BGAAEAAAAAgEBAAgAAAAyCi8BUgABAAAAlQAEAAAALgEBAAQAAAACAQIABQAAAAkC AAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEAYQAAADIKLwF2ADwAAABDbGFyaWZpY2F0aW9u IG9mIGludGVyYWN0aW9ucyBvZiBwcmVjZWRlbmNlcyBhbmQgZXZhbHVhdGlvbnMVAAkADgALAAkA CwAIAA8ADgAJAAgAEAAQAAgAEAALAAgACQAQAAkADgALAA4ADgAJAAkAEAAQAAwACAAQAAsACAAQ AAoADwAOAA4AEAAOABAADgAOAA0ACAAOABAAEAAIAA4AEAAOAAkAEAAPAAgACQAQABAADQAEAAAA LgEBAAQAAAACAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEACAAAADIKYgFS AAEAAACVAAQAAAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIB AQBbAAAAMgpiAXYAOAAAAGFkZGVkIGFjY2VzcyBkZWNpc2lvbiBhbGdvcml0aG0gc28gbm90aGlu ZyBpbnR1aXRlZCBmcm9tDgAQABAADgAQAAgADwAOAA4ADgANAAwACAAQAA4ADgAJAA0ACQAQABAA CAAOAAkAEAAQAAoACQAJABAAGQAIAAwAEAAIABAAEAAJABAACQAQABAACAAJABAACQAQAAgACQAO ABAACAALAAsAEAAZAAQAAAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgA BAAAAAIBAQATAAAAMgqJAXYACAAAAGV4YW1wbGVzDgAQAA4AGQAQAAkADgANAAQAAAAuAQEABAAA AAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAIAAAAMgq8AVIAAQAAAJUA BAAAAC4BAQAEAAAAAgECAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBAFoAAAAy CrwBdgA3AAAAQWRkZWQgc3RyZW5ndGggb2YgYXV0aGVudGljYXRpb24gb3B0aW9uIGludG8gQUNJ IHN5bnRheAAXABAAEAAOABAACAANAAkACgAPABAAEAAIABAACAAQAAsACAAOABAACQAQAA4AEAAJ AAkADgAOAAkACQAQABAACAAQABAACQAJABAAEAAIAAgAEAAJABAACAAXABYACgAIAA0AEAAQAAkA DgAQAAQAAAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAi AAAAMgrjAXYAEgAAAGJhc2VkIG9uIGxkYXAgYmluZBAADgANAA4AEAAIABAAEAAIAAkAEAAOABAA CAAQAAkAEAAQAAQAAAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAA AAIBAQAIAAAAMgoWAlIAAQAAAJUABAAAAC4BAQAEAAAAAgECAAUAAAAJAgAAAAIFAAAAFAIAAAAA BAAAAC4BGAAEAAAAAgEBAF0AAAAyChYCdgA5AAAASW5jb3Jwb3JhdGVkIGF1dGhtZXRoIGlkIGZv cm1hdCBpbnRvIHN1YmplY3QgY29tcG9uZW50IG9mAAsAEAAOABAACwAQABAACgAOAAkADgAQAAgA DwAQAAgAEAAZAA4ACQAQAAgACQAQAAgACwAQAAoAGQAOAAkACAAJABAACQAQAAgADAAQABAACQAO AA8ACAAIAA8AEAAYABAAEAARAA4AEAAJAAgAEAAKAAQAAAAuAQEABAAAAAIBAgAFAAAACQIAAAAC BQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQASAAAAMgo9AnYABwAAAGxkYXBhY2kACQAQAA4AEAAO AA4ACQAEAAAALgEBAAQAAAACAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEA FQAAADIKPQLSAAkAAAAgKHJlbW92ZWQACAALAAsADgAZABAAEAAOABAABAAAAC4BAQAEAAAAAgEC AAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBABUAAAAyCj0CVQEJAAAAIGtlcmJl cm9zAAgAEAAOAAsAEAAOAAoAEAANAAQAAAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAA AAQAAAAuARgABAAAAAIBAQATAAAAMgo9AssBCAAAACBmb3JtYXQpCAALABAACgAZAA4ACQALAAQA AAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAIAAAAMgpw AlIAAQAAAJUABAAAAC4BAQAEAAAAAgECAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAA AgEBABUAAAAyCnACdgAJAAAAaXBBZGRyZXNzAAkAEAAXABAAEAALAA4ADAANAAQAAAAuAQEABAAA AAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQBJAAAAMgpwAvgALAAAACBm b3JtYXQgZXhwYW5kZWQgdG8gaW5jbHVkZSBkb21haW4gbmFtZXMgYW5kCAALABAACgAZAA4ACQAI AA4AEAAQAA4AEAAQAA8AEAAIAAgAEAAIAAkAEAAOAAkAEAAQAA4ACAAQABAAGQAOAAkAEAAIABAA DgAZAA4ADQAIAA4AEAAQAAQAAAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAu ARgABAAAAAIBAQAVAAAAMgqXAnYACQAAAHdpbGRjYXJkcwAXAAkACQAQAA4ADgALABAADAAEAAAA LgEBAAQAAAACAQIABAAAAAIBAgAEAAAALQEBAAQAAAAtAQMAEAAAAPsCEAAHAAAAAAC8AgAAAAAB AgIiU3lzdGVtAG4EAAAALQEFAAQAAADwAQQADwAAACYGDwAUAFROUFAEAAwAAAAAAAAAAAAAAAAA CQAAACYGDwAIAP////8BAAAAAwAAAAAARBIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAI AAAACQAAAAoAAAAMAAAA/v////7///////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////c2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAANAAAA U2xpZGUgVGl0bGVzAAMAAAADAAAAAJgAAAADAAAAAAAAACAAAAABAAAANgAAAAIAAAA+AAAAAQAA AAIAAAAKAAAAX1BJRF9HVUlEAAIAAADkBAAAQQAAAE4AAAB7ADcAQgBEADcAOQA1AEIAQQAtADAA RQA3ADcALQA0AEEAQQAwAC0AOAAzADAARQAtADIAOABDAEEAQgBEADIAMgBGAEIAAAD2DyQAAAAU AAAAX8CR4xBmAAAMAPQDAwAAAEVsbGVuIFN0b2tlcwgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgA NgB9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAA AAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAA AAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBIwAAAAPAADwhAAAAAAABvA4 AAAABBQAAAYAAAAWAAAABQAAAAEAAAAHAAAAAgAAAAQAAAADAAAABAAAAAQAAAAIAAAABQAAAAQA AABjAAvwJAAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACEAAHvEQAAAABAAA CAEAAAgCAAAI9wAAEB8A8A8cAAAAAADzAxQAAAADAAAAAAAAAAAAAAAAAACAAAAAAA8A0AeLAAAA DwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAATQAAAGQAAABNAAAAZAAAAFiyYgB+1AMwULJiAAgA AACmFwAAsA0AANb8//+m////AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABACwAAHwD/ AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAD8A2Q9yAAAAAADaDwQAAAAAAC0AAAC6DxgAAAAzADEA IABKAHUAbAB5ACAAMgAwADAAMAAgALoPPgAAAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBsAGQAYQBw AGUAeAB0AC0AYQBjAGwALQBtAG8AZABlAGwALQAwADYATwDZDwwAAAAAANoPBAAAAAAAPQAPAPAP 5wkAAAAA8wMUAAAABAAAAAAAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPEgAAAFN1bW1h cnkgb2YgQ2hhbmdlcwAAoQ8cAAAAEwAAAAAAAAAAABIAAAAAAAIAJAABAAAAAAAAABAAnw8EAAAA AQAAAAAAqA8aAgAAQk5GIHBlciBSRkMgMjIzNDsgdXBkYXRlZCBleGFtcGxlcyB0byByZWZsZWN0 IG5ldyBCTkYgDUFkZGVkIGJhY2sgbXVsdGlwbGUgbGlzdCBvZiBhdHRyaWJ1dGVzOyByZW1vdmVk IGNvbGxlY3Rpb25zIA11cGRhdGVkL2V4cGFuZGVkIHNldCBvZiBwZXJtaXNzaW9ucyBhbmQgdGhl aXIgZGVzY3JpcHRpb25zIA1DbGFyaWZpY2F0aW9uIG9mIGludGVyYWN0aW9ucyBvZiBwcmVjZWRl bmNlcyBhbmQgZXZhbHVhdGlvbnMgDWFkZGVkIGFjY2VzcyBkZWNpc2lvbiBhbGdvcml0aG0gc28g bm90aGluZyBpbnR1aXRlZCBmcm9tIGV4YW1wbGVzIA1BZGRlZCBzdHJlbmd0aCBvZiBhdXRoZW50 aWNhdGlvbiBvcHRpb24gaW50byBBQ0kgc3ludGF4IGJhc2VkIG9uIGxkYXAgYmluZCANSW5jb3Jw b3JhdGVkIGF1dGhtZXRoIGlkIGZvcm1hdCBpbnRvIHN1YmplY3QgY29tcG9uZW50IG9mIGxkYXBh Y2kgKHJlbW92ZWQga2VyYmVyb3MgZm9ybWF0KSANaXBBZGRyZXNzIGZvcm1hdCBleHBhbmRlZCB0 byBpbmNsdWRlIGRvbWFpbiBuYW1lcyBhbmQgd2lsZGNhcmRzIAAAoQ8YAAAAGwIAAAAAAGAAANj/ 2P8bAgAAAAACABgAAACqDz4AAAC2AQAAAAAAAAgAAAABAAAAAwAJAAAAAAAAAAkAAAABAAAAAwAI AAAAAAAAAAsAAAABAAAAAwA4AAAAAAAAAAAA8wMUAAAABQAAAAAAAAACAAAAAQEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPHgAAAFN1bW1hcnkgb2YgQ2hhbmdlcyAoY29udGludWVkKQAAoQ8cAAAAHwAA AAAAAAAAAB4AAAAAAAIAJAABAAAAAAAAABAAnw8EAAAAAQAAAAAAqA/uAQAAYWRkZWQgYWJpbGl0 eSB0byBjb250cm9sIGFjY2VzcyB0byBBQ0k7IHJlbW92ZWQgcG9saWN5IG93bmVyIA1kZWZpbmVk IGxkYXBBQ0lTdWJFbnRyeSB0byBhbGxvdyBzcGVjaWZpY2F0aW9uIG9mIGFueSBhY2Nlc3MgY29u dHJvbCBtZWNoYW5pc20gYW55d2hlcmUgaW4gdGhlIHRyZWUgDWFkZHJlc3NlZCBob3cgYWxpYXMg ZGUtcmVmZXJlbmNpbmcgYW5kIHJlZmVycmFscyB3b3JrIHdpdGggcmVzcGVjdCB0byBhY2Nlc3Mg Y29udHJvbCANVmVyc2lvbmluZyBsZGFwQUNJOiBjb25jbHVkZWQgdGhhdCBhIGRpZmZlcmVudCBh dHRyaWJ1dGUgd291bGQgYmUgdXNlZCBpbiBzdWJzZXF1ZW50IFJGQ3Mgb24gbGRhcCBhY2Nlc3Mg Y29udHJvbA11cGRhdGVkIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9ucyANdXBk YXRlZC9leHBhbmRlZCBkZXNjcmlwdGlvbiBvZiB0aGUgYWNjZXNzIGNvbnRyb2wgbW9kZWwgDXJl bW92ZWQgdGVybWlub2xvZ3kgc2VjdGlvbg0AAKEPKgAAAO4BAAAAAABgAADY/9j/AQAAAAAAAAAA AO4BAAAAAAIAGAABAAAAAAAAAAAAqg8sAAAARQAAAAAAAAAQAAAAAQAAAAMA+AAAAAAAAAAFAAAA AQAAAAMAnQAAAAAAAAAAAPMDFAAAAAYAAAAAAAAAAgAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACo DxUAAABOZXcgQ29tbWVudHMgb24gRHJhZnQAAKEPHAAAABYAAAAAAAAAAAAVAAAAAAACACQAAQAA AAAAAAAQAJ8PBAAAAAEAAAAAAKAPPAMAAGQAaQBzAGMAbABvAHMAZQBPAG4ARQByAHIAbwByADoA IAAgAGMAaABhAG4AZwBlACAAZgByAG8AbQAgAHMAZQByAHYAZQByACAAYgBhAHMAaQBzACAAdABv ACAAYQAgAHAAZQByAG0AaQBzAHMAaQBvAG4APwANAEMAbABhAHIAaQBmAHkAIAB0AGgAYQB0ACAA ZABlAGwAZQB0AGUAIABwAGUAcgBtAGkAcwBzAGkAbwBuACAAdwBvAHIAawBzACAAbwBuACAAbABl AGEAZgAgAGUAbgB0AHIAeQAgACgAcABlAHIAIABYAC4ANQAwADAAKQANAHMAZQBhAHIAYwBoACAA cABlAHIAbQBpAHMAcwBpAG8AbgA6ACAAIAByAGUAdgBpAHMAaQB0AC8AdQBwAGQAYQB0AGUAIABw AGUAcgBtAGkAcwBzAGkAbwBuAHMAIABiACwAIAByACwAIABzAA0AcwBoAG8AdQBsAGQAIABsAGQA YQBwAEEAQwBJACAAYQB0AHQAcgBpAGIAdQB0AGUAIABiAGUAIABzAHAAbABpAHQAIABpAG4AdABv ACAAcwB1AGIAdAByAGUAZQBBAEMASQAgAGEAbgBkACAAZQBuAHQAcgB5AEEAQwBJACAAYQB0AHQA cgBpAGIAdQB0AGUAcwA/AA0AQwBsAGEAcgBpAGYAeQAgAHUAcwBlACAAbwBmACAAHCBbAGEAbABs AF0AHSAgAGEAbgBkACAAHCBbAGUAbgB0AHIAeQBdAB0gIAB3AHIAdAAgAHMAdQBiAHQAcgBlAGUA IABzAGMAbwBwAGUADQBhAHUAdABoAG4AIABsAGUAdgBlAGwAOgAgACAAYwBsAGEAcgBpAGYAeQAg AGgAbwB3ACAAaQB0ACAAdwBvAHIAawBzACAAdwBpAHQAaAAgAGQAZQBuAHkAOwAgAHMAaABvAHUA bABkACAAYQBkAGQAaQB0AGkAbwBuAGEAbAAgAGUAeABwAGwAaQBjAGkAdAAgAGMAaABvAGkAYwBl AHMAIABiAGUAIABzAHAAZQBjAGkAZgBpAGUAZAAsACAAZQAuAGcALgAgAFgANQAwADkAPwANAAAA oQ8UAAAAnwEAAAAAAAAAAJ8BAAAAAAIAGAAAAKoPNgAAAA8AAAABAAAAAwDKAAAAAAAAAAsAAAAB AAAAAwAEAAAAAAAAAAkAAAABAAAAAwCuAAAAAAAAAAAA6gMAAAAADwDuA9gBAAACAO8DGAAAAAEA AAANDgAAAAAAAAAAAIAAAAAABwAAAA8ADASIAQAADwAC8IABAABQAAjwCAAAAAMAAAADFAAADwAD 8BgBAAAPAATwKAAAAAEACfAQAAAABAAAAMADAADQAgAAAAAAAAIACvAIAAAAABQAAAUAAAAPAATw bAAAABIACvAIAAAAAhQAACACAABDAAvwGAAAAIAARDTiAL8BAAABAP8BAAABAAEDAgQAAAAAEPAI AAAAAACwAdAU0AIPABHwEAAAAAAAwwsIAAAAAAAAAA0AfAAPAA3wDAAAAAAAng8EAAAAAAAAAA8A BPBsAAAAEgAK8AgAAAADFAAAIAIAAEMAC/AYAAAAgACkNOIAvwEAAAEA/wEAAAEAAQMDBAAAAAAQ 8AgAAADQArAB0BQADw8AEfAQAAAAAADDCwgAAAABAAAADgB8AA8ADfAMAAAAAACeDwQAAAABAAAA DwAE8EgAAAASAArwCAAAAAEUAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM /wCysrIAAAByFxAAAAABABAATBsAAAYAEABMKAAAAAD1DxwAAAACAQAAgxUAAygbAAAsKgAAAQAA AAYAAAABAAAADwDoAzYNAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAIAAAAAAAAA AQAAAAAAAAEPAPID8AAAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB0wAAAAAALcPRAAAAFQAaQBt AGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAHLZiABy2YgAosmIA+NMDMEyyYgAIAAAATLJiAH7U AzAAAAYSAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAA AAAAAABAAgAAAAACAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkAC AAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwSMAAAADwAA8IQAAAAAAAbwOAAAAAQUAAAG AAAAFgAAAAUAAAABAAAABwAAAAIAAAAEAAAAAwAAAAQAAAAEAAAACAAAAAUAAAAEAAAAYwAL8CQA AACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAhAAB7xEAAAAAQAAAgBAAAIAgAA CPcAABAfAPAPHAAAAAAA8wMUAAAAAwAAAAAAAAAAAAAAAAAAgAAAAAAPANAHiwAAAA8A+gNnAAAA AAD+AwMAAAAAAQAAAP0DNAAAAE0AAABkAAAATQAAAGQAAABYsmIAftQDMFCyYgAIAAAAphcAALAN AADW/P//pv///wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAA BAwAAAAAAAAAAAAAAAIAAAA/ANkPcgAAAAAA2g8EAAAAAAAtAAAAug8YAAAAMwAxACAASgB1AGwA eQAgADIAMAAwADAAIAC6Dz4AAABkAHIAYQBmAHQALQBpAGUAdABmAC0AbABkAGEAcABlAHgAdAAt AGEAYwBsAC0AbQBvAGQAZQBsAC0AMAA2AE8A2Q8MAAAAAADaDwQAAAAAAD0ADwDwDyUKAAAAAPMD FAAAAAQAAAAAAAAAAgAAAAABAAAAAAAAAACfDwQAAAAAAAAAAACoDxIAAABTdW1tYXJ5IG9mIENo YW5nZXMAAKEPHAAAABMAAAAAAAAAAAASAAAAAAACACQAAQAAAAAAAAAQAJ8PBAAAAAEAAAAAAKgP GgIAAEJORiBwZXIgUkZDIDIyMzQ7IHVwZGF0ZWQgZXhhbXBsZXMgdG8gcmVmbGVjdCBuZXcgQk5G IA1BZGRlZCBiYWNrIG11bHRpcGxlIGxpc3Qgb2YgYXR0cmlidXRlczsgcmVtb3ZlZCBjb2xsZWN0 aW9ucyANdXBkYXRlZC9leHBhbmRlZCBzZXQgb2YgcGVybWlzc2lvbnMgYW5kIHRoZWlyIGRlc2Ny aXB0aW9ucyANQ2xhcmlmaWNhdGlvbiBvZiBpbnRlcmFjdGlvbnMgb2YgcHJlY2VkZW5jZXMgYW5k IGV2YWx1YXRpb25zIA1hZGRlZCBhY2Nlc3MgZGVjaXNpb24gYWxnb3JpdGhtIHNvIG5vdGhpbmcg aW50dWl0ZWQgZnJvbSBleGFtcGxlcyANQWRkZWQgc3RyZW5ndGggb2YgYXV0aGVudGljYXRpb24g b3B0aW9uIGludG8gQUNJIHN5bnRheCBiYXNlZCBvbiBsZGFwIGJpbmQgDUluY29ycG9yYXRlZCBh dXRobWV0aCBpZCBmb3JtYXQgaW50byBzdWJqZWN0IGNvbXBvbmVudCBvZiBsZGFwYWNpIChyZW1v dmVkIGtlcmJlcm9zIGZvcm1hdCkgDWlwQWRkcmVzcyBmb3JtYXQgZXhwYW5kZWQgdG8gaW5jbHVk ZSBkb21haW4gbmFtZXMgYW5kIHdpbGRjYXJkcyAAAKEPGAAAABsCAAAAAABgAADY/9j/GwIAAAAA AgAYAAAAqg8+AAAAtgEAAAAAAAAIAAAAAQAAAAMACQAAAAAAAAAJAAAAAQAAAAMACAAAAAAAAAAL AAAAAQAAAAMAOAAAAAAAAAAAAPMDFAAAAAUAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAA AACoDx4AAABTdW1tYXJ5IG9mIENoYW5nZXMgKGNvbnRpbnVlZCkAAKEPHAAAAB8AAAAAAAAAAAAe AAAAAAACACQAAQAAAAAAAAAQAJ8PBAAAAAEAAAAAAKgP7gEAAGFkZGVkIGFiaWxpdHkgdG8gY29u dHJvbCBhY2Nlc3MgdG8gQUNJOyByZW1vdmVkIHBvbGljeSBvd25lciANZGVmaW5lZCBsZGFwQUNJ U3ViRW50cnkgdG8gYWxsb3cgc3BlY2lmaWNhdGlvbiBvZiBhbnkgYWNjZXNzIGNvbnRyb2wgbWVj aGFuaXNtIGFueXdoZXJlIGluIHRoZSB0cmVlIA1hZGRyZXNzZWQgaG93IGFsaWFzIGRlLXJlZmVy ZW5jaW5nIGFuZCByZWZlcnJhbHMgd29yayB3aXRoIHJlc3BlY3QgdG8gYWNjZXNzIGNvbnRyb2wg DVZlcnNpb25pbmcgbGRhcEFDSTogY29uY2x1ZGVkIHRoYXQgYSBkaWZmZXJlbnQgYXR0cmlidXRl IHdvdWxkIGJlIHVzZWQgaW4gc3Vic2VxdWVudCBSRkNzIG9uIGxkYXAgYWNjZXNzIGNvbnRyb2wN dXBkYXRlZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbnMgDXVwZGF0ZWQvZXhw YW5kZWQgZGVzY3JpcHRpb24gb2YgdGhlIGFjY2VzcyBjb250cm9sIG1vZGVsIA1yZW1vdmVkIHRl cm1pbm9sb2d5IHNlY3Rpb24NAAChDyoAAADuAQAAAAAAYAAA2P/Y/wEAAAAAAAAAAADuAQAAAAAC ABgAAQAAAAAAAAAAAKoPLAAAAEUAAAAAAAAAEAAAAAEAAAADAPgAAAAAAAAABQAAAAEAAAADAJ0A AAAAAAAAAADzAxQAAAAGAAAAAAAAAAIAAAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8VAAAATmV3 IENvbW1lbnRzIG9uIERyYWZ0AAChDxwAAAAWAAAAAAAAAAAAFQAAAAAAAgAkAAEAAAAAAAAAEACf DwQAAAABAAAAAACgD3oDAABkAGkAcwBjAGwAbwBzAGUATwBuAEUAcgByAG8AcgA6ACAAIABjAGgA YQBuAGcAZQAgAGYAcgBvAG0AIABzAGUAcgB2AGUAcgAgAGIAYQBzAGkAcwAgAHQAbwAgAGEAIABw AGUAcgBtAGkAcwBzAGkAbwBuAD8ADQBDAGwAYQByAGkAZgB5ACAAdABoAGEAdAAgAGQAZQBsAGUA dABlACAAcABlAHIAbQBpAHMAcwBpAG8AbgAgAHcAbwByAGsAcwAgAG8AbgAgAGwAZQBhAGYAIABl AG4AdAByAHkAIAAoAHAAZQByACAAWAAuADUAMAAwACkADQBTAGUAYQByAGMAaAAgAHAAZQByAG0A aQBzAHMAaQBvAG4AOgAgACAAcgBlAHYAaQBzAGkAdAAvAHUAcABkAGEAdABlACAAcABlAHIAbQBp AHMAcwBpAG8AbgBzACAAYgAsACAAcgAsACAAcwANAFMAaABvAHUAbABkACAAbABkAGEAcABBAEMA SQAgAGEAdAB0AHIAaQBiAHUAdABlACAAYgBlACAAcwBwAGwAaQB0ACAAaQBuAHQAbwAgAHMAdQBi AHQAcgBlAGUAQQBDAEkAIABhAG4AZAAgAGUAbgB0AHIAeQBBAEMASQAgAGEAdAB0AHIAaQBiAHUA dABlAHMAPwANAEMAbABhAHIAaQBmAHkAIAB1AHMAZQAgAG8AZgAgABwgWwBhAGwAbABdAB0gIABh AG4AZAAgABwgWwBlAG4AdAByAHkAXQAdICAAdwByAHQAIABzAHUAYgB0AHIAZQBlACAAcwBjAG8A cABlAA0AQQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuACAAbABlAHYAZQBsADoAIAAgAGMAbABh AHIAaQBmAHkAIABoAG8AdwAgAGkAdAAgAHcAbwByAGsAcwAgAHcAaQB0AGgAIABkAGUAbgB5ADsA IABzAGgAbwB1AGwAZAAgAGEAZABkAGkAdABpAG8AbgBhAGwAIABlAHgAcABsAGkAYwBpAHQAIABj AGgAbwBpAGMAZQBzACAAYgBlACAAcwBwAGUAYwBpAGYAaQBlAGQALAAgAGUALgBnAC4AIABYADUA MAA5AD8ADQBVAHMAZQAgAG8AZgAgAGYAaQBsAHQAZQByAHMAIABpAG4AIABBAEMASQA/AAAAoQ8U AAAAvgEAAAAAAAAAAL4BAAAAAAIAGAAAAKoPNgAAAA8AAAABAAAAAwDKAAAAAAAAAAsAAAABAAAA AwAEAAAAAAAAAAkAAAABAAAAAwDNAAAAAAAAAAAA6gMAAAAAAAByFwgAAAABABAAaCoAAAAA9Q8c AAAAAgEAAIMVAANEKgAApjcAAAEAAAAGAAAAAQAAAA8A6APSDQAAAQDpAygAAACAFgAA4BAAAOAQ AACAFgAABQAAAAoAAAACAAAAAAAAAAEAAAAAAAABDwDyA/AAAAAvAMgPDAAAADAA0g8EAAAAAAAA AA8A1QdMAAAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAABy2YgActmIA KLJiAPjTAzBMsmIACAAAAEyyYgB+1AMwAAAGEgAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD/ /T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////GAAAAAAB AAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEjAAA AA8AAPCEAAAAAAAG8DgAAAAEFAAABgAAABYAAAAFAAAAAQAAAAcAAAACAAAABAAAAAMAAAAEAAAA BAAAAAgAAAAFAAAABAAAAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQIC AAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAMAAAAAAAAAAAAAAAAA AIAAAAAADwDQB4sAAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABNAAAAZAAAAE0AAABkAAAA WLJiAH7UAzBQsmIACAAAAKYXAACwDQAA1vz//6z///8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMI AAAAAQAAAEALAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAPwDZD3IAAAAAANoPBAAAAAAA LQAAALoPGAAAADMAMQAgAEoAdQBsAHkAIAAyADAAMAAwACAAug8+AAAAZAByAGEAZgB0AC0AaQBl AHQAZgAtAGwAZABhAHAAZQB4AHQALQBhAGMAbAAtAG0AbwBkAGUAbAAtADAANgBPANkPDAAAAAAA 2g8EAAAAAAA9AA8A8A/BCgAAAADzAxQAAAAEAAAAAAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8SAAAAU3VtbWFyeSBvZiBDaGFuZ2VzAAChDxwAAAATAAAAAAAAAAAAEgAAAAAAAgAkAAEA AAAAAAAAEACfDwQAAAABAAAAAACoDxoCAABCTkYgcGVyIFJGQyAyMjM0OyB1cGRhdGVkIGV4YW1w bGVzIHRvIHJlZmxlY3QgbmV3IEJORiANQWRkZWQgYmFjayBtdWx0aXBsZSBsaXN0IG9mIGF0dHJp YnV0ZXM7IHJlbW92ZWQgY29sbGVjdGlvbnMgDXVwZGF0ZWQvZXhwYW5kZWQgc2V0IG9mIHBlcm1p c3Npb25zIGFuZCB0aGVpciBkZXNjcmlwdGlvbnMgDUNsYXJpZmljYXRpb24gb2YgaW50ZXJhY3Rp b25zIG9mIHByZWNlZGVuY2VzIGFuZCBldmFsdWF0aW9ucyANYWRkZWQgYWNjZXNzIGRlY2lzaW9u IGFsZ29yaXRobSBzbyBub3RoaW5nIGludHVpdGVkIGZyb20gZXhhbXBsZXMgDUFkZGVkIHN0cmVu Z3RoIG9mIGF1dGhlbnRpY2F0aW9uIG9wdGlvbiBpbnRvIEFDSSBzeW50YXggYmFzZWQgb24gbGRh cCBiaW5kIA1JbmNvcnBvcmF0ZWQgYXV0aG1ldGggaWQgZm9ybWF0IGludG8gc3ViamVjdCBjb21w b25lbnQgb2YgbGRhcGFjaSAocmVtb3ZlZCBrZXJiZXJvcyBmb3JtYXQpIA1pcEFkZHJlc3MgZm9y bWF0IGV4cGFuZGVkIHRvIGluY2x1ZGUgZG9tYWluIG5hbWVzIGFuZCB3aWxkY2FyZHMgAAChDxgA AAAbAgAAAAAAYAAA2P/Y/xsCAAAAAAIAGAAAAKoPPgAAALYBAAAAAAAACAAAAAEAAAADAAkAAAAA AAAACQAAAAEAAAADAAgAAAAAAAAACwAAAAEAAAADADgAAAAAAAAAAADzAxQAAAAFAAAAAAAAAAIA AAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8eAAAAU3VtbWFyeSBvZiBDaGFuZ2VzIChjb250aW51 ZWQpAAChDxwAAAAfAAAAAAAAAAAAHgAAAAAAAgAkAAEAAAAAAAAAEACfDwQAAAABAAAAAACoD+4B AABhZGRlZCBhYmlsaXR5IHRvIGNvbnRyb2wgYWNjZXNzIHRvIEFDSTsgcmVtb3ZlZCBwb2xpY3kg b3duZXIgDWRlZmluZWQgbGRhcEFDSVN1YkVudHJ5IHRvIGFsbG93IHNwZWNpZmljYXRpb24gb2Yg YW55IGFjY2VzcyBjb250cm9sIG1lY2hhbmlzbSBhbnl3aGVyZSBpbiB0aGUgdHJlZSANYWRkcmVz c2VkIGhvdyBhbGlhcyBkZS1yZWZlcmVuY2luZyBhbmQgcmVmZXJyYWxzIHdvcmsgd2l0aCByZXNw ZWN0IHRvIGFjY2VzcyBjb250cm9sIA1WZXJzaW9uaW5nIGxkYXBBQ0k6IGNvbmNsdWRlZCB0aGF0 IGEgZGlmZmVyZW50IGF0dHJpYnV0ZSB3b3VsZCBiZSB1c2VkIGluIHN1YnNlcXVlbnQgUkZDcyBv biBsZGFwIGFjY2VzcyBjb250cm9sDXVwZGF0ZWQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IHNlY3Rpb25zIA11cGRhdGVkL2V4cGFuZGVkIGRlc2NyaXB0aW9uIG9mIHRoZSBhY2Nlc3MgY29u dHJvbCBtb2RlbCANcmVtb3ZlZCB0ZXJtaW5vbG9neSBzZWN0aW9uDQAAoQ8qAAAA7gEAAAAAAGAA ANj/2P8BAAAAAAAAAAAA7gEAAAAAAgAYAAEAAAAAAAAAAACqDywAAABFAAAAAAAAABAAAAABAAAA AwD4AAAAAAAAAAUAAAABAAAAAwCdAAAAAAAAAAAA8wMUAAAABgAAAAAAAAACAAAAAgEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPFQAAAE5ldyBDb21tZW50cyBvbiBEcmFmdAAAoQ8cAAAAFgAAAAAAAAAA ABUAAAAAAAIAJAABAAAAAAAAABAAnw8EAAAAAQAAAAAAoA8EBAAAZABpAHMAYwBsAG8AcwBlAE8A bgBFAHIAcgBvAHIAOgAgACAAYwBoAGEAbgBnAGUAIABmAHIAbwBtACAAcwBlAHIAdgBlAHIAIABi AGEAcwBpAHMAIAB0AG8AIABhACAAcABlAHIAbQBpAHMAcwBpAG8AbgA/AA0AZABlAGwAZQB0AGUA IABwAGUAcgBtAGkAcwBzAGkAbwBuADoAIABjAGwAYQByAGkAZgB5ACAAaQB0ACAAdwBvAHIAawBz ACAAbwBuACAAbABlAGEAZgAgAGUAbgB0AHIAeQAgACgAcABlAHIAIABYAC4ANQAwADAAKQANAFMA ZQBhAHIAYwBoACAAcABlAHIAbQBpAHMAcwBpAG8AbgA6ACAAIAByAGUAdgBpAHMAaQB0AC8AdQBw AGQAYQB0AGUAIABwAGUAcgBtAGkAcwBzAGkAbwBuAHMAIABiACwAIAByACwAIABzAA0AUgBlAG4A YQBtAGUAIABwAGUAcgBtAGkAcwBzAGkAbwBuADoAIAAgAHIAZQBuAGEAbQBlACAAcABlAHIAbQAg AG8AcgAgAGMAbwBtAGIAaQBuAGEAdABpAG8AbgAgAG8AZgAgAHcALAAgAG8ALAAgAGkALAAgAGUA IABwAGUAcgBtAHMAPwANAFMAaABvAHUAbABkACAAbABkAGEAcABBAEMASQAgAGEAdAB0AHIAaQBi AHUAdABlACAAYgBlACAAcwBwAGwAaQB0ACAAaQBuAHQAbwAgAHMAdQBiAHQAcgBlAGUAQQBDAEkA IABhAG4AZAAgAGUAbgB0AHIAeQBBAEMASQAgAGEAdAB0AHIAaQBiAHUAdABlAHMAPwANAEMAbABh AHIAaQBmAHkAIAB1AHMAZQAgAG8AZgAgABwgWwBhAGwAbABdAB0gIABhAG4AZAAgABwgWwBlAG4A dAByAHkAXQAdICAAdwByAHQAIABzAHUAYgB0AHIAZQBlACAAcwBjAG8AcABlAA0AQQB1AHQAaABl AG4AdABpAGMAYQB0AGkAbwBuAGcAIABsAGUAdgBlAGwAOgAgACAAYwBsAGEAcgBpAGYAeQAgAGgA bwB3ACAAaQB0ACAAdwBvAHIAawBzACAAdwBpAHQAaAAgAGQAZQBuAHkAOwAgAHMAaABvAHUAbABk ACAAYQBkAGQAaQB0AGkAbwBuAGEAbAAgAGUAeABwAGwAaQBjAGkAdAAgAGMAaABvAGkAYwBlAHMA IABiAGUAIABzAHAAZQBjAGkAZgBpAGUAZAAsACAAZQAuAGcALgAgAFgANQAwADkAPwANAFUAcwBl ACAAbwBmACAAZgBpAGwAdABlAHIAcwAgAGkAbgAgAEEAQwBJAD8ADQAAAKEPFAAAAAMCAAAAAAAA AAADAgAAAAACABgAAACqD0gAAAAPAAAAAQAAAAMADQEAAAAAAAALAAAAAQAAAAMABAAAAAAAAAAJ AAAAAQAAAAMAQwAAAAAAAAAPAAAAAQAAAAMAfQAAAAAAAAAAAOoDAAAAAAAAchcIAAAAAQAQANo3 AAAAAPUPHAAAAAIBAACDFQADtjcAALRFAAABAAAABgAAAAEAAAAPAOgDVA4AAAEA6QMoAAAAgBYA AOAQAADgEAAAgBYAAAUAAAAKAAAAAgAAAAAAAAABAAAAAAAAAQ8A8gPwAAAALwDIDwwAAAAwANIP BAAAAAAAAAAPANUHTAAAAAAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAAc tmIAHLZiACiyYgD40wMwTLJiAAgAAABMsmIAftQDMAAABhIAAKkPCgAAAAcAAAACAAkEAABAAKMP bgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP////// /xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAA DwALBIwAAAAPAADwhAAAAAAABvA4AAAABBQAAAYAAAAWAAAABQAAAAEAAAAHAAAAAgAAAAQAAAAD AAAABAAAAAQAAAAIAAAABQAAAAQAAABjAAvwJAAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8B CAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8cAAAAAADzAxQAAAADAAAAAAAA AAAAAAAAAACAAAAAAA8A0AeLAAAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAATQAAAGQAAABN AAAAZAAAAFiyYgB+1AMwULJiAAgAAACmFwAAsA0AANb8//9KAQAAAQAAAHAA+wMIAAAAAAAAAHAI AABwAPsDCAAAAAEAAABACwAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAD8A2Q9yAAAAAADa DwQAAAAAAC0AAAC6DxgAAAAzADEAIABKAHUAbAB5ACAAMgAwADAAMAAgALoPPgAAAGQAcgBhAGYA dAAtAGkAZQB0AGYALQBsAGQAYQBwAGUAeAB0AC0AYQBjAGwALQBtAG8AZABlAGwALQAwADYATwDZ DwwAAAAAANoPBAAAAAAAPQAPAPAPQwsAAAAA8wMUAAAABAAAAAAAAAACAAAAAAEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPEgAAAFN1bW1hcnkgb2YgQ2hhbmdlcwAAoQ8cAAAAEwAAAAAAAAAAABIAAAAA AAIAJAABAAAAAAAAABAAnw8EAAAAAQAAAAAAqA8aAgAAQk5GIHBlciBSRkMgMjIzNDsgdXBkYXRl ZCBleGFtcGxlcyB0byByZWZsZWN0IG5ldyBCTkYgDUFkZGVkIGJhY2sgbXVsdGlwbGUgbGlzdCBv ZiBhdHRyaWJ1dGVzOyByZW1vdmVkIGNvbGxlY3Rpb25zIA11cGRhdGVkL2V4cGFuZGVkIHNldCBv ZiBwZXJtaXNzaW9ucyBhbmQgdGhlaXIgZGVzY3JpcHRpb25zIA1DbGFyaWZpY2F0aW9uIG9mIGlu dGVyYWN0aW9ucyBvZiBwcmVjZWRlbmNlcyBhbmQgZXZhbHVhdGlvbnMgDWFkZGVkIGFjY2VzcyBk ZWNpc2lvbiBhbGdvcml0aG0gc28gbm90aGluZyBpbnR1aXRlZCBmcm9tIGV4YW1wbGVzIA1BZGRl ZCBzdHJlbmd0aCBvZiBhdXRoZW50aWNhdGlvbiBvcHRpb24gaW50byBBQ0kgc3ludGF4IGJhc2Vk IG9uIGxkYXAgYmluZCANSW5jb3Jwb3JhdGVkIGF1dGhtZXRoIGlkIGZvcm1hdCBpbnRvIHN1Ympl Y3QgY29tcG9uZW50IG9mIGxkYXBhY2kgKHJlbW92ZWQga2VyYmVyb3MgZm9ybWF0KSANaXBBZGRy ZXNzIGZvcm1hdCBleHBhbmRlZCB0byBpbmNsdWRlIGRvbWFpbiBuYW1lcyBhbmQgd2lsZGNhcmRz IAAAoQ8YAAAAGwIAAAAAAGAAANj/2P8bAgAAAAACABgAAACqDz4AAAC2AQAAAAAAAAgAAAABAAAA AwAJAAAAAAAAAAkAAAABAAAAAwAIAAAAAAAAAAsAAAABAAAAAwA4AAAAAAAAAAAA8wMUAAAABQAA AAAAAAACAAAAAQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPHgAAAFN1bW1hcnkgb2YgQ2hhbmdlcyAo Y29udGludWVkKQAAoQ8cAAAAHwAAAAAAAAAAAB4AAAAAAAIAJAABAAAAAAAAABAAnw8EAAAAAQAA AAAAqA/uAQAAYWRkZWQgYWJpbGl0eSB0byBjb250cm9sIGFjY2VzcyB0byBBQ0k7IHJlbW92ZWQg cG9saWN5IG93bmVyIA1kZWZpbmVkIGxkYXBBQ0lTdWJFbnRyeSB0byBhbGxvdyBzcGVjaWZpY2F0 aW9uIG9mIGFueSBhY2Nlc3MgY29udHJvbCBtZWNoYW5pc20gYW55d2hlcmUgaW4gdGhlIHRyZWUg DWFkZHJlc3NlZCBob3cgYWxpYXMgZGUtcmVmZXJlbmNpbmcgYW5kIHJlZmVycmFscyB3b3JrIHdp dGggcmVzcGVjdCB0byBhY2Nlc3MgY29udHJvbCANVmVyc2lvbmluZyBsZGFwQUNJOiBjb25jbHVk ZWQgdGhhdCBhIGRpZmZlcmVudCBhdHRyaWJ1dGUgd291bGQgYmUgdXNlZCBpbiBzdWJzZXF1ZW50 IFJGQ3Mgb24gbGRhcCBhY2Nlc3MgY29udHJvbA11cGRhdGVkIHRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBzZWN0aW9ucyANdXBkYXRlZC9leHBhbmRlZCBkZXNjcmlwdGlvbiBvZiB0aGUgYWNj ZXNzIGNvbnRyb2wgbW9kZWwgDXJlbW92ZWQgdGVybWlub2xvZ3kgc2VjdGlvbg0AAKEPKgAAAO4B AAAAAABgAADY/9j/AQAAAAAAAAAAAO4BAAAAAAIAGAABAAAAAAAAAAAAqg8sAAAARQAAAAAAAAAQ AAAAAQAAAAMA+AAAAAAAAAAFAAAAAQAAAAMAnQAAAAAAAAAAAPMDFAAAAAYAAAAAAAAAAgAAAAIB AAAAAAAAAACfDwQAAAAAAAAAAACoDxUAAABOZXcgQ29tbWVudHMgb24gRHJhZnQAAKEPHAAAABYA AAAAAAAAAAAVAAAAAAACACQAAQAAAAAAAAAQAJ8PBAAAAAEAAAAAAKAPhgQAAGQAaQBzAGMAbABv AHMAZQBPAG4ARQByAHIAbwByADoAIAAgAGMAaABhAG4AZwBlACAAZgByAG8AbQAgAHMAZQByAHYA ZQByACAAYgBhAHMAaQBzACAAdABvACAAYQAgAHAAZQByAG0AaQBzAHMAaQBvAG4APwANAEQAZQBs AGUAdABlACAAcABlAHIAbQBpAHMAcwBpAG8AbgA6ACAAYwBsAGEAcgBpAGYAeQAgAGkAdAAgAHcA bwByAGsAcwAgAG8AbgAgAGwAZQBhAGYAIABlAG4AdAByAHkAIAAoAHAAZQByACAAWAAuADUAMAAw ACkADQBTAGUAYQByAGMAaAAgAHAAZQByAG0AaQBzAHMAaQBvAG4AOgAgACAAcgBlAHYAaQBzAGkA dAAvAHUAcABkAGEAdABlACAAcABlAHIAbQBpAHMAcwBpAG8AbgBzACAAYgAsACAAcgAsACAAcwAN AFIAZQBuAGEAbQBlACAAcABlAHIAbQBpAHMAcwBpAG8AbgA6ACAAIAByAGUAbgBhAG0AZQAgAHAA ZQByAG0AIABvAHIAIABjAG8AbQBiAGkAbgBhAHQAaQBvAG4AIABvAGYAIAB3ACwAIABvACwAIABp ACwAIABlACAAcABlAHIAbQBzAD8ADQBTAGgAbwB1AGwAZAAgAGwAZABhAHAAQQBDAEkAIABhAHQA dAByAGkAYgB1AHQAZQAgAGIAZQAgAHMAcABsAGkAdAAgAGkAbgB0AG8AIABzAHUAYgB0AHIAZQBl AEEAQwBJACAAYQBuAGQAIABlAG4AdAByAHkAQQBDAEkAIABhAHQAdAByAGkAYgB1AHQAZQBzAD8A DQBDAGwAYQByAGkAZgB5ACAAdQBzAGUAIABvAGYAIAAcIFsAYQBsAGwAXQAdICAAYQBuAGQAIAAc IFsAZQBuAHQAcgB5AF0AHSAgAHcAcgB0ACAAcwB1AGIAdAByAGUAZQAgAHMAYwBvAHAAZQANAEEA dQB0AGgAZQBuAHQAaQBjAGEAdABpAG8AbgAgAGwAZQB2AGUAbAA6ACAAIABjAGwAYQByAGkAZgB5 ACAAaABvAHcAIABpAHQAIAB3AG8AcgBrAHMAIAB3AGkAdABoACAAZABlAG4AeQA7ACAAcwBoAG8A dQBsAGQAIABhAGQAZABpAHQAaQBvAG4AYQBsACAAZQB4AHAAbABpAGMAaQB0ACAAYwBoAG8AaQBj AGUAcwAgAGIAZQAgAHMAcABlAGMAaQBmAGkAZQBkACwAIABlAC4AZwAuACAAWAA1ADAAOQA/AA0A VQBzAGUAIABvAGYAIABmAGkAbAB0AGUAcgBzACAAaQBuACAAQQBDAEkAPwANAEQAZQBwAGUAbgBk AGUAbgBjAHkAIABvAG4AIABsAGQAYQBwAFMAdQBiAEUAbgB0AHIAeQAgAHMAcABlAGMAaQBmAGkA YwBjAGEAdABpAG8AbgA/AA0AUwBwAGUAYwBpAGYAaQBjAGkAdAB5ACAAcAByAGUAYwBlAGQAZQBu AGMAZQANAAAAoQ8UAAAARAIAAAAAAAAAAEQCAAAAAAIAGAAAAKoPSAAAAA8AAAABAAAAAwANAQAA AAAAAAsAAAABAAAAAwAEAAAAAAAAAAkAAAABAAAAAwDbAAAAAAAAABsAAAABAAAAAwAaAAAAAAAA AAAA6gMAAAAAAAByFwgAAAABABAA6EUAAAAA9Q8cAAAAAgEAAIMVAAPERQAARFQAAAEAAAAGAAAA AQAAAA8A6AOYDwAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAACAAAAAAAAAAEAAAAA AAABDwDyA/AAAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1QdMAAAAAAC3D0QAAABUAGkAbQBlAHMA IABOAGUAdwAgAFIAbwBtAGEAbgAAABy2YgActmIAKLJiAPjTAzBMsmIACAAAAEyyYgB+1AMwAAAG EgAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAA QAIAAAAAAgAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAA BQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEjAAAAA8AAPCEAAAAAAAG8DgAAAAEFAAABgAAABYA AAAFAAAAAQAAAAcAAAACAAAABAAAAAMAAAAEAAAABAAAAAgAAAAFAAAABAAAAGMAC/AkAAAAgQEE AAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQ HwDwDxwAAAAAAPMDFAAAAAMAAAAAAAAAAAAAAAAAAIAAAAAADwDQB4sAAAAPAPoDZwAAAAAA/gMD AAAAAAEAAAD9AzQAAABNAAAAZAAAAE0AAABkAAAAWLJiAH7UAzBQsmIACAAAAKYXAACwDQAA1vz/ /6b///8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfAP8DFAAAAAIAAAQMAAAA AAAAAAAAAAACAAAAPwDZD3IAAAAAANoPBAAAAAAALQAAALoPGAAAADMAMQAgAEoAdQBsAHkAIAAy ADAAMAAwACAAug8+AAAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGwAZABhAHAAZQB4AHQALQBhAGMA bAAtAG0AbwBkAGUAbAAtADAANgBPANkPDAAAAAAA2g8EAAAAAAA9AA8A8A+HDAAAAADzAxQAAAAE AAAAAAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8SAAAAU3VtbWFyeSBvZiBDaGFuZ2Vz AAChDxwAAAATAAAAAAAAAAAAEgAAAAAAAgAkAAEAAAAAAAAAEACfDwQAAAABAAAAAACoDxoCAABC TkYgcGVyIFJGQyAyMjM0OyB1cGRhdGVkIGV4YW1wbGVzIHRvIHJlZmxlY3QgbmV3IEJORiANQWRk ZWQgYmFjayBtdWx0aXBsZSBsaXN0IG9mIGF0dHJpYnV0ZXM7IHJlbW92ZWQgY29sbGVjdGlvbnMg DXVwZGF0ZWQvZXhwYW5kZWQgc2V0IG9mIHBlcm1pc3Npb25zIGFuZCB0aGVpciBkZXNjcmlwdGlv bnMgDUNsYXJpZmljYXRpb24gb2YgaW50ZXJhY3Rpb25zIG9mIHByZWNlZGVuY2VzIGFuZCBldmFs dWF0aW9ucyANYWRkZWQgYWNjZXNzIGRlY2lzaW9uIGFsZ29yaXRobSBzbyBub3RoaW5nIGludHVp dGVkIGZyb20gZXhhbXBsZXMgDUFkZGVkIHN0cmVuZ3RoIG9mIGF1dGhlbnRpY2F0aW9uIG9wdGlv biBpbnRvIEFDSSBzeW50YXggYmFzZWQgb24gbGRhcCBiaW5kIA1JbmNvcnBvcmF0ZWQgYXV0aG1l dGggaWQgZm9ybWF0IGludG8gc3ViamVjdCBjb21wb25lbnQgb2YgbGRhcGFjaSAocmVtb3ZlZCBr ZXJiZXJvcyBmb3JtYXQpIA1pcEFkZHJlc3MgZm9ybWF0IGV4cGFuZGVkIHRvIGluY2x1ZGUgZG9t YWluIG5hbWVzIGFuZCB3aWxkY2FyZHMgAAChDxgAAAAbAgAAAAAAYAAA2P/Y/xsCAAAAAAIAGAAA AKoPPgAAALYBAAAAAAAACAAAAAEAAAADAAkAAAAAAAAACQAAAAEAAAADAAgAAAAAAAAACwAAAAEA AAADADgAAAAAAAAAAADzAxQAAAAFAAAAAAAAAAIAAAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8e AAAAU3VtbWFyeSBvZiBDaGFuZ2VzIChjb250aW51ZWQpAAChDxwAAAAfAAAAAAAAAAAAHgAAAAAA AgAkAAEAAAAAAAAAEACfDwQAAAABAAAAAACoD+4BAABhZGRlZCBhYmlsaXR5IHRvIGNvbnRyb2wg YWNjZXNzIHRvIEFDSTsgcmVtb3ZlZCBwb2xpY3kgb3duZXIgDWRlZmluZWQgbGRhcEFDSVN1YkVu dHJ5IHRvIGFsbG93IHNwZWNpZmljYXRpb24gb2YgYW55IGFjY2VzcyBjb250cm9sIG1lY2hhbmlz bSBhbnl3aGVyZSBpbiB0aGUgdHJlZSANYWRkcmVzc2VkIGhvdyBhbGlhcyBkZS1yZWZlcmVuY2lu ZyBhbmQgcmVmZXJyYWxzIHdvcmsgd2l0aCByZXNwZWN0IHRvIGFjY2VzcyBjb250cm9sIA1WZXJz aW9uaW5nIGxkYXBBQ0k6IGNvbmNsdWRlZCB0aGF0IGEgZGlmZmVyZW50IGF0dHJpYnV0ZSB3b3Vs ZCBiZSB1c2VkIGluIHN1YnNlcXVlbnQgUkZDcyBvbiBsZGFwIGFjY2VzcyBjb250cm9sDXVwZGF0 ZWQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb25zIA11cGRhdGVkL2V4cGFuZGVk IGRlc2NyaXB0aW9uIG9mIHRoZSBhY2Nlc3MgY29udHJvbCBtb2RlbCANcmVtb3ZlZCB0ZXJtaW5v bG9neSBzZWN0aW9uDQAAoQ8qAAAA7gEAAAAAAGAAANj/2P8BAAAAAAAAAAAA7gEAAAAAAgAYAAEA AAAAAAAAAACqDywAAABFAAAAAAAAABAAAAABAAAAAwD4AAAAAAAAAAUAAAABAAAAAwCdAAAAAAAA AAAA8wMUAAAABgAAAAAAAAACAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFQAAAE5ldyBDb21t ZW50cyBvbiBEcmFmdAAAoQ8cAAAAFgAAAAAAAAAAABUAAAAAAAIAJAABAAAAAAAAABAAnw8EAAAA AQAAAAAAoA/ABQAAZABpAHMAYwBsAG8AcwBlAE8AbgBFAHIAcgBvAHIAOgAgACAAYwBoAGEAbgBn AGUAIABmAHIAbwBtACAAcwBlAHIAdgBlAHIAIABiAGEAcwBpAHMAIAB0AG8AIABhACAAcABlAHIA bQBpAHMAcwBpAG8AbgA/AA0ARABlAGwAZQB0AGUAIABwAGUAcgBtAGkAcwBzAGkAbwBuADoAIABj AGwAYQByAGkAZgB5ACAAaQB0ACAAdwBvAHIAawBzACAAbwBuACAAbABlAGEAZgAgAGUAbgB0AHIA eQAgACgAcABlAHIAIABYAC4ANQAwADAAKQANAFMAZQBhAHIAYwBoACAAcABlAHIAbQBpAHMAcwBp AG8AbgA6ACAAIAByAGUAdgBpAHMAaQB0AC8AdQBwAGQAYQB0AGUAIABwAGUAcgBtAGkAcwBzAGkA bwBuAHMAIABiACwAIAByACwAIABzAA0AUgBlAG4AYQBtAGUAIABwAGUAcgBtAGkAcwBzAGkAbwBu ADoAIAAgAHIAZQBuAGEAbQBlACAAcABlAHIAbQAgAG8AcgAgAGMAbwBtAGIAaQBuAGEAdABpAG8A bgAgAG8AZgAgAHcALAAgAG8ALAAgAGkALAAgAGUAIABwAGUAcgBtAHMAPwANAFMAaABvAHUAbABk ACAAbABkAGEAcABBAEMASQAgAGEAdAB0AHIAaQBiAHUAdABlACAAYgBlACAAcwBwAGwAaQB0ACAA aQBuAHQAbwAgAHMAdQBiAHQAcgBlAGUAQQBDAEkAIABhAG4AZAAgAGUAbgB0AHIAeQBBAEMASQAg AGEAdAB0AHIAaQBiAHUAdABlAHMAPwANAEMAbABhAHIAaQBmAHkAIAB1AHMAZQAgAG8AZgAgABwg WwBhAGwAbABdAB0gIABhAG4AZAAgABwgWwBlAG4AdAByAHkAXQAdICAAdwByAHQAIABzAHUAYgB0 AHIAZQBlACAAcwBjAG8AcABlAA0AQQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuACAAbABlAHYA ZQBsADoAIAAgAGMAbABhAHIAaQBmAHkAIABoAG8AdwAgAGkAdAAgAHcAbwByAGsAcwAgAHcAaQB0 AGgAIABkAGUAbgB5ADsAIABzAGgAbwB1AGwAZAAgAGEAZABkAGkAdABpAG8AbgBhAGwAIABlAHgA cABsAGkAYwBpAHQAIABjAGgAbwBpAGMAZQBzACAAYgBlACAAcwBwAGUAYwBpAGYAaQBlAGQALAAg AGUALgBnAC4AIABYADUAMAA5AD8ADQBVAHMAZQAgAG8AZgAgAGYAaQBsAHQAZQByAHMAIABpAG4A IABBAEMASQA/AA0ARABlAHAAZQBuAGQAZQBuAGMAeQAgAG8AbgAgAGwAZABhAHAAUwB1AGIARQBu AHQAcgB5ACAAcwBwAGUAYwBpAGYAaQBjAGEAdABpAG8AbgA/AA0AUwBwAGUAYwBpAGYAaQBjAGkA dAB5ACAAcAByAGUAYwBlAGQAZQBuAGMAZQANAE0AaQBzAGMAIABjAGwAYQByAGkAZgBpAGMAYQB0 AGkAbwBuAHMAIAAoACAAZQAuAGcALgAgAGEAZABkACwAIABpAG0AcABvAHIAdAAsACAAZQB4AHAA bwByAHQAIABwAGUAcgBtAHMAOwAgAGUAbQBwAHQAeQAgAGcAcgBhAG4AdAAgAGwAaQBzAHQAOwAg AHMAdQBiAGoAZQBjAHQAIABkAGUAZgBpAG4AaQB0AGkAbwBuAHMAKQANAFUAcABkAGEAdABlACAA YwBvAG4AdAByAG8AbAAvAGUAeAB0AGUAbgBkAGUAZAAgAG8AcABlAHIAYQB0AGkAbwBuACAAdABv ACAAcgBlAGYAbABlAGMAdAAgAGMAbwByAHIAZQBjAHQAIABjAG8AbgB2AGUAbgB0AGkAbwBuAHMA DQAAAKEPHgAAAOECAAAAAAAAAADfAgAAAAACABQAAgAAAAAAAgAYAAAAqg9IAAAADwAAAAEAAAAD AA0BAAAAAAAACwAAAAEAAAADAAQAAAAAAAAACQAAAAEAAAADANsAAAAAAAAADQAAAAEAAAADAMUA AAAAAAAAAADqAwAAAAAPAO4D2AEAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAAADwAM BIgBAAAPAALwgAEAAFAACPAIAAAAAwAAAAMUAAAPAAPwGAEAAA8ABPAoAAAAAQAJ8BAAAAAEAAAA wAMAANACAAAAAAAAAgAK8AgAAAAAFAAABQAAAA8ABPBsAAAAEgAK8AgAAAACFAAAIAIAAEMAC/AY AAAAgABENOIAvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAAAAALAB0BTQAg8AEfAQAAAAAADDCwgA AAAAAAAADQB8AA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8GwAAAASAArwCAAAAAMUAAAgAgAAQwAL 8BgAAACAAKQ04gC/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAHACsAGQFQAPDwAR8BAAAAAAAMML CAAAAAEAAAAOAHwADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAARQAAAAMAACD AAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA 8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAAAHIXEAAAAAEAEAB4VAAABgAQ ABhkAAAAAPUPHAAAAAIBAACDFQADVFQAAPhlAAABAAAABgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --=====================_922077==_ Content-Type: application/pdf; name="aug2000ietfldapextaci.PDF" Content-Disposition: attachment; filename="aug2000ietfldapextaci.PDF" Content-Transfer-Encoding: base64 JVBERi0xLjIgDQol4uPP0w0KIA0KOCAwIG9iag0KPDwNCi9MZW5ndGggOSAwIFINCi9GaWx0ZXIg L0ZsYXRlRGVjb2RlIA0KPj4NCnN0cmVhbQ0KSImllM1u2zAMx58g78BjenAqyZ9BT222At1hh63H XhRZTtTakiHLbfr2oyTHSbsvFIWDgLAp8sc/SVGg+NgdLNIC8FcyAnlGwEpoFjf3i3W5yqEoVmUO cP9lQcA/3v3ylgDNVsy/bxYJWZGceFsA2jllaL7AMqXwbWxfgRFCLuD+ccEoxYDEB/OOpGJVOESi f2154xIlXZO0Ne/lwSVctElnatkmpAgh0rLyODEGWaVlTLuk4WuSZaX/nOVkggaPiqUdObM8iymP Jub9OXYdt69gGtjsud7JIQajGUPcJPf/x1AsO4ai+Tn7A2N5rLGc4Qhh66Mok42eN99voZcWftxu gLE0u4Kxr7mTNcgD7/pWDuAMtqBppXCg5QvgiQiEsZO0irIHBf/H4BOzYq44muh5XdeYb8vFE3Rj 6xRmhVYNzkvAnbNqOzo5XCFFZ57RU5jW0yijhzOS9Ycw6ExBo99U9qU89Fx7nkEGABSnU8PgkwF+ ALeXykItB2FV/zmGtJwhgomem5Zb1SjBfWSfXmknLY/FBhwrhaylFjLiyGfejvw9x0e7QqbBnU30 5KErXGCmAesVymsAvN0Zq9y+g8GANm6v9M5DjsrPTGNNF6ITSNj6DIJU9JziOFv/Rv4b7LqaYYM5 j9DgrNQ7tw+DM2KntJulDL3ypAauN3cwvGrHD7+z+qBFddqTYkqw5QMmwAj+LoCt0vVn5KZz56OJ nndaGNsbG3bPw3cSC1GoqbEdd5F8GLePfg+F6XqjsTys9M96Z1lxzuGpuVDBt1if7oQ0Z3Ot0UZn eFhOqxb816G8mZ5Skk70k+mPPEm7ldbEjlbVKj+7d9LspGc67fxU1sPFJGPF/BX5cSmLNMIsVY8z YHFWI3P55mpn5HTrkLcEMC886qu0aMdaQm06rjRo3sU1i5Ah6Dud06w8h3xRbS24rSPF1/vFLwqV xOkNCmVuZHN0cmVhbQ0KZW5kb2JqDQo5IDAgb2JqDQo3MTYNCmVuZG9iag0KNCAwIG9iag0KPDwN Ci9UeXBlIC9QYWdlDQovUGFyZW50IDUgMCBSDQovUmVzb3VyY2VzIDw8DQovRm9udCA8PA0KL0Yw IDYgMCBSIA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDggMCBSDQo+Pg0KZW5k b2JqDQoxMSAwIG9iag0KPDwNCi9MZW5ndGggMTIgMCBSDQovRmlsdGVyIC9GbGF0ZURlY29kZSAN Cj4+DQpzdHJlYW0NCkiJrVRNc9MwEP0F+Q97bA9OZfkrhhOUdgaONMOpF8WSE4E/giTj5t+zK1tx CoVhOkwymY29fu/teyvHEOPH7GGV5IDfgjPIUgZGQb16v12VxTqDPF8XGcD2w4oBfaj95p5BnK45 Xa9XEVuzjFFdAdZZzLEc4SqJ4dPQnIAzxq5h+3XF4xgBGYFRI9vwjX+ITf3SiNpFWrk6aqQ4qicX iaqJ2l6qJmK5h0iKDcmZMNg6KSbaK+7vRlmS0u00LWbRQFJxtKCT5eVEGUrkfRjaVpgT9DXcHkS3 VxYer6q+c7oblHy8nqEz1D79BlyeBtw4uxzkkfNsGrg4K2Uxy4NDc42dQkolQex0o90JXA9Ea/oG RFUpa+nKu9uPbzGRtv+Bnce+0dXJYzOI+GYWQwrSjF9q6MdOmUk5qoiS8tw4O/aiSJak012pat0p 6RsKfpEZCzShRC6guFDnw7C7Q/mTvrgoaUGWJ+NgUijpSRxQNE0/gj2qSte6Ek73HUUhutMsP4sJ aJmWqMvibOZUk5mTZ8HCVlWYprYtQY0HhVutO3AHBc4o9Rdr/pzizHnOziAfpnJA/aLRwoJUkVE1 UnWV7vZILMH/N6KxMPbmG4zaHX7LzzufLBP5GikQH21x3qVnw71Gvc8Az2TIwJfY+UUZi56T3jnH N0RTNQPtpjsIBwKkrv1YWDtn9G5w6sUp4mWIGX7sh0bCTsFAVmECdthZ9X1ArFlfvgiMi3TWN1W0 Ip/vb63vzNly9P0wZXIeppwdA1wemuJFv5I8IYT/4NlwlMJ5dxRYVQ2Gji9yWS2V8Sts6bovLrLa TK/Mf1s2pON8eWVw/oz6Rj0dcb1Qg1S2MvoYzg1J+vUk0Bv0tSvD+HLgg4bwOnLKtLrrm35/CuN6 gLvt6ic/Gah1DQplbmRzdHJlYW0NCmVuZG9iag0KMTIgMCBvYmoNCjY4MA0KZW5kb2JqDQoxMCAw IG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDUgMCBSDQovUmVzb3VyY2VzIDw8DQovRm9u dCA8PA0KL0YwIDYgMCBSIA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDExIDAg Ug0KPj4NCmVuZG9iag0KMTQgMCBvYmoNCjw8DQovTGVuZ3RoIDE1IDAgUg0KL0ZpbHRlciAvRmxh dGVEZWNvZGUgDQo+Pg0Kc3RyZWFtDQpIiaVWbW/bNhD+Bf4P9zEFbIUvem0+FG2SARuwFWhSoMCy D7JExexoUSDpOP73PYqUbG8rttWQARHU8bnn7p47mgLFxzzDgueAv4IRyFICRkC3+PC4qIokgzxP igzg8W5BwD/e/PonAjRNmN/vFiuSkIz4dQO4zijD5R6uOIVfduoAjBDyBh6/LhilCEg8mDckJSvH QyTYt6bu3EoK161UWw/i1a3qRq22uhVqRfIRghelpxMwSMKL4PaKj19XacE9qzQjkTR4qhia54ke CSsmmnGNfn8Te7jV263onQXdw53nEfAoLWCVslMwRk7i5hOBGMITY1kItTiJsyqqwLKVtlHaio/9 vTHajJaUUw84W1PC2MyxzHgAfgvQbOr+GStj9BasMC/CwLq20oLTUMMgzFZaK3X/LlLPSo+7YmWS Tdj/iS4SyGcCKY8E7oQSTpy4eQuNqo3sDiAd7LX5c8ydEnUHmEhzgKcrNIYvSUbI05vACd38AB9W 0GPR8jKYPojaNJszPqjbF2mlu94NbX3G1cJ6CWYJ9oRGFcr4f3ik0SgheZT4J9HXW/FXFvMeaAON 3q5lXzv8CLqD/RL0EuQSgoV9d0lm0pJOjMosj4nZ6J1qwXfQ+9ufoXbOyPUO07EWYAeFxZI9KiZ0 E8lP0CjhEY1VRUyz3a2dEcIjjSfGkTAfYencTpxmWThS921E58dWHduAnrX7qBIEjp3LiyDXdOaT V6ERruYY/jVb38sTz2NkcYnub6N6d1b4uuBB/nut1B+4SMHHMO6MJMPe3jiI6QDb6EFcJCaaplPp irwKlu93boMOZRPUosSLUL7xI9ON3h97bS/dBlrRH27AhorXbSv9uVqN3shpLkmVV3MP0Ukq4hX1 0CBks9GyETZIRDSyk6JFhSbPCXzJSHWRRhmfNBqXaPk55LyTygljUZCAOrjMC50qzFFn08gaRI8p ag5+MoVhi5U61yQvp7ykeRlF73vnYbe+H8dYOEezM91Tdkop5iyUbQ6DBT3/ozS+G0V5jCIO3ocI Lt0BBiMa4SMSF+WqnPqc5lkM+Ve8maLQYhwWB3iQAAoLJ9Z20MahKF79O8yuGxDbAWk9m7p3oKR1 N3+XHl6h1RxUls5j5atoHAq4k/2oWnvZHUHT46VZTHfW53APNBoLqdU1/qHwemgBe9eEFsNBaESn PJVGGxPe/YtvQqQ0url/XHwDV0xapQ0KZW5kc3RyZWFtDQplbmRvYmoNCjE1IDAgb2JqDQo5MTEN CmVuZG9iag0KMTMgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCA1IDAgUg0KL1Jlc291 cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCj4+DQovUHJvY1NldCAyIDAgUg0KPj4NCi9D b250ZW50cyAxNCAwIFINCj4+DQplbmRvYmoNCjYgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1 YnR5cGUgL1RydWVUeXBlDQovTmFtZSAvRjANCi9CYXNlRm9udCAvVGltZXNOZXdSb21hbg0KL0Zp cnN0Q2hhciAzMQ0KL0xhc3RDaGFyIDI1NQ0KL1dpZHRocyBbIDc3OCAyNTAgMzMzIDQwOCA1MDAg NTAwIDgzMyA3NzggMTgwIDMzMyAzMzMgNTAwIDU2NCAyNTAgMzMzIDI1MCANCjI3OCA1MDAgNTAw IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMjc4IDI3OCA1NjQgNTY0IDU2NCANCjQ0 NCA5MjEgNzIyIDY2NyA2NjcgNzIyIDYxMSA1NTYgNzIyIDcyMiAzMzMgMzg5IDcyMiA2MTEgODg5 IDcyMiANCjcyMiA1NTYgNzIyIDY2NyA1NTYgNjExIDcyMiA3MjIgOTQ0IDcyMiA3MjIgNjExIDMz MyAyNzggMzMzIDQ2OSANCjUwMCAzMzMgNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAy NzggMjc4IDUwMCAyNzggNzc4IDUwMCANCjUwMCA1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAg NzIyIDUwMCA1MDAgNDQ0IDQ4MCAyMDAgNDgwIDU0MSANCjc3OCA1MDAgNzc4IDMzMyA1MDAgNDQ0 IDEwMDAgNTAwIDUwMCAzMzMgMTAwMCA1NTYgMzMzIDg4OSA3NzggNzc4IA0KNzc4IDc3OCAzMzMg MzMzIDQ0NCA0NDQgMzUwIDUwMCAxMDAwIDMzMyA5ODAgMzg5IDMzMyA3MjIgNzc4IDc3OCANCjcy MiAyNTAgMzMzIDUwMCA1MDAgNTAwIDUwMCAyMDAgNTAwIDMzMyA3NjAgMjc2IDUwMCA1NjQgMzMz IDc2MCANCjUwMCA0MDAgNTQ5IDMwMCAzMDAgMzMzIDU3NiA0NTMgMjUwIDMzMyAzMDAgMzEwIDUw MCA3NTAgNzUwIDc1MCANCjQ0NCA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA4ODkgNjY3IDYxMSA2 MTEgNjExIDYxMSAzMzMgMzMzIDMzMyANCjMzMyA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIg NTY0IDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDU1NiANCjUwMCA0NDQgNDQ0IDQ0NCA0NDQgNDQ0 IDQ0NCA2NjcgNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCAyNzggMjc4IDI3OCANCjI3OCA1MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgNTQ5IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCANCjUwMCBd DQovRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0KL0ZvbnREZXNjcmlwdG9yIDcgMCBSDQo+Pg0K ZW5kb2JqDQo3IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnREZXNjcmlwdG9yDQovRm9udE5hbWUgL1Rp bWVzTmV3Um9tYW4NCi9GbGFncyAzNA0KL0ZvbnRCQm94IFsgLTI1MCAtMjYzIDEyNjQgODQyIF0N Ci9NaXNzaW5nV2lkdGggNzg5DQovU3RlbVYgNzYNCi9TdGVtSCA3Ng0KL0l0YWxpY0FuZ2xlIDAN Ci9DYXBIZWlnaHQgODQyDQovWEhlaWdodCA1ODkNCi9Bc2NlbnQgODQyDQovRGVzY2VudCAtMjYz DQovTGVhZGluZyAxNTgNCi9NYXhXaWR0aCAxMDUzDQovQXZnV2lkdGggNDIxDQo+Pg0KZW5kb2Jq DQoyIDAgb2JqDQpbIC9QREYgL1RleHQgIF0NCmVuZG9iag0KNSAwIG9iag0KPDwNCi9LaWRzIFs0 IDAgUiAxMCAwIFIgMTMgMCBSIF0NCi9Db3VudCAzDQovVHlwZSAvUGFnZXMNCi9NZWRpYUJveCBb IDAgMCA3OTIgNjEyIF0NCj4+DQplbmRvYmoNCjEgMCBvYmoNCjw8DQovQ3JlYXRvciA8RkVGRjAw NEQwMDY5MDA2MzAwNzIwMDZGMDA3MzAwNkYwMDY2MDA3NDAwMjAwMDUwMDA2RjAwNzcwMDY1MDA3 MjAwNTAwMDZGMDA2OTAwNkUwMDc0MDAyMD4NCi9DcmVhdGlvbkRhdGUgKEQ6MjAwMDA3MzEyMjAw MzQpDQovVGl0bGUgPEZFRkYwMDYxMDA3NTAwNjcwMDMyMDAzMDAwMzAwMDMwMDA2OTAwNjUwMDc0 MDA2NjAwNkMwMDY0MDA2MTAwNzAwMDY1MDA3ODAwNzQwMDYxMDA2MzAwNjk+DQovQXV0aG9yIDxG RUZGMDA2NTAwNzMwMDc0MDA2RjAwNkIwMDY1MDA3Mz4NCi9Qcm9kdWNlciAoQWNyb2JhdCBQREZX cml0ZXIgNC4wIGZvciBXaW5kb3dzKQ0KPj4NCmVuZG9iag0KMyAwIG9iag0KPDwNCi9QYWdlcyA1 IDAgUg0KL1R5cGUgL0NhdGFsb2cNCi9EZWZhdWx0R3JheSAxNiAwIFINCi9EZWZhdWx0UkdCICAx NyAwIFINCj4+DQplbmRvYmoNCjE2IDAgb2JqDQpbL0NhbEdyYXkNCjw8DQovV2hpdGVQb2ludCBb MC45NjQzIDEgMC44MjUxIF0NCi9HYW1tYSAxLjkgDQo+Pg0KXQ0KZW5kb2JqDQoxNyAwIG9iag0K Wy9DYWxSR0INCjw8DQovV2hpdGVQb2ludCBbMC45NjQzIDEgMC44MjUxIF0NCi9HYW1tYSBbMS45 IDEuOSAxLjkgXQ0KL01hdHJpeCBbMC41MTEgMC4yOTAzIDAuMDI3MyAwLjMyNjQgMC42NDk5IDAu MTI3OSAwLjEyNjggMC4wNTk4IDAuNjY5OSBdDQo+Pg0KXQ0KZW5kb2JqDQp4cmVmDQowIDE4DQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDQ1ODggMDAwMDAgbg0KMDAwMDAwNDQ0OCAwMDAwMCBu DQowMDAwMDA0OTM4IDAwMDAwIG4NCjAwMDAwMDA4NDMgMDAwMDAgbg0KMDAwMDAwNDQ4MiAwMDAw MCBuDQowMDAwMDAzMDQ5IDAwMDAwIG4NCjAwMDAwMDQxNjkgMDAwMDAgbg0KMDAwMDAwMDAyMSAw MDAwMCBuDQowMDAwMDAwODIxIDAwMDAwIG4NCjAwMDAwMDE3NjMgMDAwMDAgbg0KMDAwMDAwMDk3 NCAwMDAwMCBuDQowMDAwMDAxNzQwIDAwMDAwIG4NCjAwMDAwMDI5MTYgMDAwMDAgbg0KMDAwMDAw MTg5NiAwMDAwMCBuDQowMDAwMDAyODkzIDAwMDAwIG4NCjAwMDAwMDUwMzUgMDAwMDAgbg0KMDAw MDAwNTEyMCAwMDAwMCBuDQp0cmFpbGVyDQo8PA0KL1NpemUgMTgNCi9Sb290IDMgMCBSDQovSW5m byAxIDAgUg0KL0lEIFs8ZmJjM2Y2OWM1OTBkNzgxNjYzY2Q3OWIzZDA3OTk0YTM+PGZiYzNmNjlj NTkwZDc4MTY2M2NkNzliM2QwNzk5NGEzPl0NCj4+DQpzdGFydHhyZWYNCjUyODgNCiUlRU9GDQo= --=====================_922077==_-- From list@netscape.com Mon Jul 31 23:48:35 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18467 for ; Mon, 31 Jul 2000 23:48:34 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e713g0j16974; Mon, 31 Jul 2000 20:42:00 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e713lBM29916; Mon, 31 Jul 2000 20:47:11 -0700 (PDT) Resent-Date: Mon, 31 Jul 2000 20:47:11 -0700 (PDT) Message-Id: <4.2.2.20000731223829.00a3fb60@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 31 Jul 2000 22:45:46 -0500 To: ietf-ldapext@netscape.com, ietf-ldup@imc.com From: Ellen Stokes Subject: Dinner BOF - Evolving LDAP Schema Entries (ELSE) Wed Aug 2 1730-1930 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"5QhTM.A.KTH.-gkh5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Here's some information on the informal (dinner) ELSE BOF. For those interested, meet at the message board Wed Aug 2 at 1730. Ellen -------------------------- Evolving LDAP Schema Entries (ELSE) BOF IETF Applications Area LDAPv3 (RFC 2251-2252) describes how clients can locate and retrieve the attribute types, object classes and other schema rules which govern an entry in the directory (its subschema). The underlying schema model is defined in X.500(93 and later). Neither LDAPv3 nor X.500 currently define how administrative clients can change the subschema over protocol. Several distinct implementations have been proposed, and interoperability is needed to allow applications to place their schema into any appropriate LDAPv3 server, and allow administrators to evolve their schema. The goal of this BOF is to determine whether there is sufficient interest in forming an IETF working group for this topic. This working group would define how LDAPv3 clients can create and change subschema. In particular it would consider (but not limited to): - grouping of LDAP schema attribute values - procedures for partitioning subschema administrative areas - procedures for merging new schema elements into a subschema area - determining allowable changes to existing schema - procedures for updating and removing existing schema elements The working group would not define any schemas itself, and schema repositories, non-LDAP directories and non-directory databases are out of scope of the working group. The working group might also consider additional schema model elements beyond those required in RFC 2251 that would be suitable for inclusion or refinement in the subschema entry. BOF Agenda - Problem statement - Work item prioritization - Working group charter review