From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 2 19:00:47 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14690 for ; Fri, 2 Apr 2004 19:00:47 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i32NnFS3032625; Fri, 2 Apr 2004 23:59:57 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i32Nie5j032243; Fri, 2 Apr 2004 23:44:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 2 Apr 2004 23:44:40 +0000 Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i32NiZc8032205 for ; Fri, 2 Apr 2004 23:44:39 GMT (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i32NiYlL022711 for ; Fri, 2 Apr 2004 15:44:34 -0800 Received: from D-140-142-21-68.dhcp4.washington.edu (D-140-142-21-68.dhcp4.washington.edu [140.142.21.68]) (authenticated bits=0) by smtp.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i32NiYSS015406 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 2 Apr 2004 15:44:34 -0800 Date: Fri, 2 Apr 2004 15:44:29 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: IETF ldapbis WG Subject: minutes from ldapbis WG meeting at IETF 59, 2004-03-02 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I sent these minutes to proceedings@ietf.org earlier today for inclusion in the official proceedings. They're still accepting updates, though, so if there are any fixes to be made please let me (and/or the list) know. - RL "Bob" --- IETF ldapbis WG meeting notes IETF 59, Seoul, South Korea 2004-03-02 submitted by: RL "Bob" Morgan also thanks to Alexey Melnikov for Jabber scribing The meeting was called to order at 1545 by the chairs, Kurt Zeilenga and RL "Bob" Morgan. The first agenda item was WG status. Kurt noted that only two documents are still being worked on. The protocol document (draft-ietf-ldapbis-protocol-22.txt) is very close to being done. Its editor, Jim Sermersheim, will submit one more revision, and a last call will be done. The authmeth document (draft-ietf-ldapbis-authmeth-10.txt) still needs review and revision. Jim Sermersheim talked about items regarding the protocol document. A number of items have had discussion on the WG list. The issue about "attributes with no equality matching rule" should be handled by an update to the draft-ietf-ldapbis-models document. There was discussion about the "server-enforced control criticality" issue raised by Hallvard Furuseth, which has seen lots of list discussion: what does a server do if a client sends a control with its criticality flag set differently than specified in the control's definition? Hallvard has said (on the list) that the server should return an error. It was asked whether this is useful in real operations or only in debugging. Hallvard will be requested to supply a real-life use case. It was noted that if Hallvard's suggestion is adopted some existing servers will have to change their behavior; whereas there are no known implementations that work in the way Hallvard is suggesting. Jim said that another remaining change is that some text is still planned to move from the protocol doc to the authmeth doc. A last-callable version of -protocol- can be published as soon as the criticality issue is resolved. Jim went on to talk about the authmeth document, for Roger Harrison who couldn't attend. Outstanding items include: clarifying that password considerations apply only to plaintext passwords being sent in the clear; moving language about mandatory-to-implement features to its own section; and removing the statement that anonymous authentication is typical when not updating. Another item is about STARTTLS sequencing: the logical requirement is that clients have to wait for all operations to finish before sending STARTTLS, but some clients are known not to. The current spec has language saying what might happen in this case, but the proposal is to clarify the situation by saying simply that clients MUST wait. Another clarification is proposed regarding choice of SASL mechanisms (section 8.5). New language would say that client and server must confirm that negotiated security level meets their requirements before proceeding to use the connection. Roger is working on a new version, and should publish soon. Kurt emphasized that the document needs good review from the WG before it can be taken to last call, so please review! In other issues: Kurt proposes that the LDAP handling of missing equality matching rules conform to the X.501 approach. This is a change from current LDAPv3 spec, but appears to be what is done by known implementations. It was asked whether the models document needs another last call, and noted that some other already-through-last-call documents have had minor tweaks to them. There will be an all-documents last call before they are sent to IESG in any case. Kurt also asked whether matching rules that are in RFC 3698 should be added to the syntaxes document. These are in X.520, and have been in use. JimS asked whether any of these will be mandatory to implement. In response it was asked whether the current doc says that any syntaxes are mandatory; this will be looked at. Lastly milestones were discussed. The intent is to finish the protocol document in March, the authmeth document in April, and to finish the roadmap and final last call for all in May, and submit the package to the IESG. Then an interop report could be prepared for 6 months following approval of the documents as RFCs. The meeting was adjourned at 1635. From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 4 04:21:12 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22513 for ; Sun, 4 Apr 2004 04:21:12 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i348Jl8v028640; Sun, 4 Apr 2004 08:20:12 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i348GaoR028579; Sun, 4 Apr 2004 08:16:36 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 4 Apr 2004 08:16:36 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i348GWBb028547; Sun, 4 Apr 2004 08:16:33 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1BA2nt-0007Uj-CG; Sun, 04 Apr 2004 10:16:29 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.30) id 1BA2np-000607-QM; Sun, 04 Apr 2004 10:16:25 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BA2nl-000426-00; Sun, 4 Apr 2004 10:16:21 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-ldapbis@OpenLDAP.org Subject: Re: authmeth: password issues In-Reply-To: <405AD57E.2090704@isode.com> References: <6.0.1.1.0.20040318184340.04bb4ab0@127.0.0.1> <405AD57E.2090704@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 4 Apr 2004 10:16:21 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Alexey Melnikov writes: >Kurt D. Zeilenga wrote: >> At 01:32 PM 3/14/2004, Hallvard B Furuseth wrote: >> >>> I'd like to see a section like the following in Authmeth, to help people >>> decide which authentication methods to support and what password >>> security to expect. >> >> Are you trying to help implementor to decide which mechanisms >> to support, or help deployers to decide which mechanisms to >> use? I gather the latter. Yes. Well, developers could put some of it in documentation, or server management tools and the like, of course. >> I would rather this focus more on the former (as our primary >> audience is implementors of LDAP). Perhaps I should have made it a security consideration. Plenty of info for deployers there. >> In particular, it could >> note that while DIGEST-MD5 is specifically designed to allow >> storage of a realm-specific but password-equivalent hash of >> the password. That fits in [DIGEST-MD5] as Alexey suggests, but I think it gets too technical about DIGEST-MD5 for the LDAP spec: It would have to explain what a DIGEST-MD5 realm is first, or depend on the reader to already know it. >> Servers implementing simple DN/password mechanism >> in addition to DIGEST-MD5, have three basic choices: >> 1) use the DIGEST-MD5 hash to verify the simple password; >> 2) store the actual password: generating the DIGEST-MD5 >> hash as needed, using it directly for simple password; or >> 3) store both the DIGEST-MD5 hash and a separate hash >> of the password for use in verifying the simple password. >> >> It might be useful to briefly describe the trade-offs. >> >> 1) doesn't work to well if you also need to support >> a mechanism that require another hash of the password, but >> if you're only supporting DIGEST-MD5 and simple (and PLAIN), >> 1) seems better than 2). >> >> 2) is appropriate where a server needs to support multiple >> authentication mechanisms which either require knowledge >> of the password, or differing hashes of the password. Only if it is deemed acceptable to store the actual password anywhere at all, and the LDAP server is secured sufficiently to be such a place. >> 3) doesn't scale well to multiple mechanisms... I don't see why. The 'multiple mechanisms' are just two currently. >> only is as strong as weakest hash, True if the hash, or part of it, is available to outsiders. And the same if true of (2), which uses a _very_ weak hash:-) >> but even less due to added complexity. Can be a problem. Can be insignificant. > Kurt, I will point out that what you've written is not specific to LDAP. > So it might be better if this is incorporated into DIGEST-MD5 itself. Sounds fine for DIGEST-MD5. I still like a section about the trade-offs between LDAP password mechanisms for the LDAP spec. I'd be happy if anyone could cut down my text, though:-) >> One of the reasons for incorporating SASL into LDAP is that >> if major new attacks are found with DIGEST-MD5, it can easily >> be replaced. Hence, I generally think 2) is the best >> implementation approach. Won't happen at our site. We don't want to store plaintext passwords anywhere. >>> The server administrator will need the plaintext of all the server's >>> DIGEST-MD5 passwords in order to generate a new set of secret >>> DIGEST-MD5 password hashes, or all users with passwords unknown to >>> the administrator will need new passwords so one can generate new >>> hashes. >> >> Note that the server can obtain the user's password by >> forcing use of simple bind until the user's entry in >> the new database is prepared, using the old database >> for verification of the simple bind used prepare the >> entry in the new database. (The old database should >> not be used for DIGEST-MD5 for obvious reasons.) >> Where a a server supports realm transition, the >> administrator just needs to tell the supporting server >> to undertake the transition. Very nice, but it also gives me the creeps... *If* one uses DIGEST-MD5 partly because one is afraid users will contact rogue servers, and because DIGEST-MD5 does not reveal the password to the server, then one should absolutely not teach users to 'just use another mechanism if the server reject DIGEST-MD5'. So while this would be a nice suggestion to put somewhere (probably DIGEST-MD5), it should be with a big caveat. Anyway, my text should have been, The server must switch to a new DIGEST-MD5 "realm", so old hashes become useless. To generate new, secret DIGEST-MD5 password hashes, the plaintexts of the passwords will be needed. ...maybe plus something of your solution above. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 4 07:11:41 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25755 for ; Sun, 4 Apr 2004 07:11:40 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i34BAckU035669; Sun, 4 Apr 2004 11:10:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i34Awt7B034913; Sun, 4 Apr 2004 10:58:55 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 4 Apr 2004 10:58:55 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i34Awrrx034900 for ; Sun, 4 Apr 2004 10:58:54 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1BA5L0-0002y2-8A; Sun, 04 Apr 2004 12:58:50 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.30) id 1BA5Ky-0002Tl-9m; Sun, 04 Apr 2004 12:58:48 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BA5Kt-0004OE-00; Sun, 4 Apr 2004 12:58:43 +0200 From: Hallvard B Furuseth Message-Id: To: Jim Sermersheim Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Distinguished values In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 4 Apr 2004 12:58:43 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Jim Sermersheim writes: > I suggest: > > - newrdn: the new RDN of the entry. If the operation moves the > entry to a new superior without changing its RDN, the old RDN > is supplied for this parameter. > Attribute values of the new RDN not matching any attribue value > of the entry are added to the entry and an appropriate error is > returned if this fails. Fine. I just noticed something else about distinguished values: > 4.7. Add Operation > - attributes: the list of attributes that, along with those from the > RDN, make up the content of the entry being added. I never noticed that one need not include the distinguished values in the attributes in the Add operation. But given that, I suppose we should state that one MAY include them in the attributes. Or that one MUST NOT do so, if a lot of us have misunderstood it very badly:-) The rest of my reply is not very interesting since we agree about a wording for Modify DN, but anyway, >>>> Hallvard B Furuseth 3/16/04 6:38:36 AM >>>> >>> - newrdn: the new RDN of the entry. If an attribute value in the >>> newrdn does not already exist in the entry (either as part of the >> ^^^^^^^^^^^^^^^^^^^^^ >>> old RDN or as a non-distinguished value), it is added. If it >> ^^^^^^^ >>> cannot be added, an appropriate error is returned. >> >>But the RDN - and thus the values it contains - is not part of the >>entry. Besides, this wording implies that the values in the RDN must be >>identical to the distinguished values, not merely equivalent. Maybe: > > I don't understand what you're asserting here. As I understand it, each > AVA in the entry's RDN is made up of distinguished attribute values held > in the entry. No, it is made up of values _matching_ those held in the entry, not of the values _in_ the entry. Copies, and maybe inexact ones. The current text indicates that a a distinguised value in the entry acts as a reference into the RDN, or maybe the other way around (that the RDN refers into the entry). > Maybe your definition of "identical" means "the same copy", and you're > asserting that the RDN may use equivalent copies of the distinguished > values held in the entry. Yes. Also that the wording is unfortunate because it gives the impression that the RDN is somehow part of the entry. Not so. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 4 12:56:07 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04874 for ; Sun, 4 Apr 2004 12:56:06 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i34GtI70056767; Sun, 4 Apr 2004 16:55:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i34GYddX055733; Sun, 4 Apr 2004 16:34:39 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 4 Apr 2004 16:34:39 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i34GYbJT055702; Sun, 4 Apr 2004 16:34:37 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BAAZt-0000ip-TZ; Sun, 04 Apr 2004 18:34:33 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BAAZq-0006kE-64; Sun, 04 Apr 2004 18:34:30 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BAAZp-00059S-00; Sun, 4 Apr 2004 18:34:29 +0200 From: Hallvard B Furuseth Message-Id: To: "Ramsay, Ron" Cc: "Kurt D. Zeilenga" , ietf-ldapbis@OpenLDAP.org Subject: RE: Distinguished values In-Reply-To: <1395B4B334FCC143B36AF788E68B63810127147E@ausyms21.ca.com> References: <1395B4B334FCC143B36AF788E68B63810127147E@ausyms21.ca.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 4 Apr 2004 18:34:29 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Ramsay, Ron writes: > Yes, but you can't match attributes, only attribute values! > >Kurt D. Zeilenga writes: >> For instance, 2.2.1's >> These AVAs are chosen from the attributes of the entry. >> could be replaced with: >> These AVAs are chosen to match attributes of the entry. "These AVAs are chosen to match values from the attributes of the entry?" I suppose one could quibble that one can then choose RDN cn=foo to match street:foo when there is no cn:foo in the entry, but... um. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 4 15:34:24 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08979 for ; Sun, 4 Apr 2004 15:34:24 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i34JXORo066593; Sun, 4 Apr 2004 19:33:24 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i34JDxJ6065273; Sun, 4 Apr 2004 19:13:59 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 4 Apr 2004 19:13:59 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i34JDuSK065235; Sun, 4 Apr 2004 19:13:56 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1BAD44-0006Kx-Lq; Sun, 04 Apr 2004 21:13:52 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.30) id 1BAD43-00059C-DC; Sun, 04 Apr 2004 21:13:51 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BAD42-0005VX-00; Sun, 4 Apr 2004 21:13:50 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Authentication issues (Re: authmeth review notes [long]) In-Reply-To: <6.0.1.1.0.20040313080748.04897250@127.0.0.1> References: <6.0.1.1.0.20040227070642.04cd3330@127.0.0.1> <6.0.1.1.0.20040311183843.047d2950@127.0.0.1> <6.0.1.1.0.20040311213043.047c2260@127.0.0.1> <6.0.1.1.0.20040313080748.04897250@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 4 Apr 2004 21:13:50 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Back to the discussion which started thus: Kurt D. Zeilenga writes: >>>> DSAs that map the DN sent in the bind request to a directory entry >>>> with an associated set of one or more passwords will compare the >>>> presented password to the set of passwords associated with that >>>> entry. >> >>> s/more passwords/more passwords, each an OCTET STRING,/ >>> s/compare/compare octet wise/ >> >> No! > > This mechanism's shared secret has always been an OCTET STRING, > to be compared octet wise. We cannot change that without causing > loads of problems. Kurt D. Zeilenga writes: > As LDAP servers are to act in accordance with X.500, understanding > how simple bind works in X.500 is key to understanding how LDAP > servers are to act. X.500 is quite clear that simple bind shared > secret is an octet string and is to be compared in an octet wise > manner. I think LDAP already differs too much from X.500 to reintroduce this X.500 requirement now. Both in implementation, and in the entire situation about what one needs from Bind and password handling. For one thing, LDAP implementations have been using password comparison routines native to the system since Umich LDAP, and some of those in use may not fit your interpretation of X.500's requirements. Maybe some system ignores whitespace or case, for example. And I don't know if you think Unix /etc/passwd-type password hashes are OK: See below. OTOH, LDAP simple bind lacks X.500's Simple Bind option with allows the client to hash the password - with a seed which contains a random component - before sending it to the server. So LDAP Simple Bind actually differs from X.500 in _both_ directions. For the "formal" situation: LDAP has DIGEST-MD5, Simple Bind with plaintext passwords over TLS, and EXTERNAL which may or may not use TLS certificates. X.500 has "native" certificates, and the above option to hash Simple Bind passwords. And maybe something parallel to TLS, I don't know. > One can argue that X.500 is even more restrictive > (requires userPassword), but I think it also can be reasonable > be argued the X.500 allowed a limited amount wiggle room here. I don't see where. X.509 section 6 states plainly that Simple Bind compares with userPassword, and even that it does so with the Compare operation. Also, if the X.500 client hashes the password sent with Simple Bind (it also sends the seed), the server can't compute the same hash to compare with unless it knows the plaintext password. However, I don't know if X.500 installations that support Simple Bind are required to enable this option. For that matter, I do not see the point in making part of the X.500 spec explicit in LDAP at the same time as you state the intent of wiggling out of that part of the spec. Though you could resolve that with another wording which more clearly says what you actually want. > I think simply saying that the LDAP simple bind shared secret > is an OCTET STRING to be compared in an octet wise manner gives > plenty of wiggle room, but then it seems I am taking a more > liberal view of what 'shared' and what 'manner' means here. Yup. At least the 'manner' part. I expect 'shared secret' may be OK if the reader is expected to know the terminology of modern Internet security, or something. I hope they are not: I do not know it well. > And 'manner' doesn't necessarily imply that this verification > needs to be perfect, but that the server can use a reasonable > verification method. That is, I think this allows use > of hashes because comparison of hashes is reasonable > verification that the client shares the secret. So, getting back to a few examples: Will Unix crypt() from /etc/passwd do for a hash function when we must compare 'in an octet wise manner'? It doesn't sound like that to me, since the octets after the eight first ones are ignored. Do you intend to forbid that hash function? Or if you allow that, can you at the same time forbid a hash function which first translates the passwords to lowercase? Both variants systematically ignore parts of the password. > The key SASLprep point is, when textual passwords are used, > that shared secret is the output of SASLprep. That is what > the client puts on the wire and that's what is to be > verified. OK. > This comparison can be said to act in an octet wise manner > as it reasonable verification that the client has knowledge > of the shared secret, an OCTET STRING. Agreed, it can be said to do so. Your suggested wording, however, can easily be interpreted very differently. So if we are going to introduce this change, I suggest you provide a wording which doesn't need a lot of explanation in order not to be misunderstood. However, I still don't know why we should change it. I've named some things the change might break. As I said, I like the current flexibility (if one ignores the X.500 requirements), and I don't quite buy that there will be 'loads of problems' if we 'change' the spec to retain the rfc2251 meaning. No, not quite the way you put it, I know:-) Finally, I'm wondering about a possible oversight: Did you really intend these restrictions to only apply to passwords associated with directory entries? If so I _really_ don't understand why you argue for strict X.500 compatibility, at the same time leaving such a hole open. What of a DN/password store outside the directory which accidentally-on-purpose "happens" to only include DNs that exist in the directory? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 4 16:26:43 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10265 for ; Sun, 4 Apr 2004 16:26:42 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i34KPbrC069071; Sun, 4 Apr 2004 20:25:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i34KOL2N069041; Sun, 4 Apr 2004 20:24:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 4 Apr 2004 20:24:21 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i34KOHT3069010; Sun, 4 Apr 2004 20:24:17 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BAEA9-00042W-IQ; Sun, 04 Apr 2004 22:24:13 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BAEA7-0005PN-Vq; Sun, 04 Apr 2004 22:24:11 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BAEA7-0005eM-00; Sun, 4 Apr 2004 22:24:11 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Intro issues (Was: authmeth review notes [long]) In-Reply-To: <6.0.1.1.0.20040311173602.047bf528@127.0.0.1> References: <6.0.1.1.0.20040227070642.04cd3330@127.0.0.1> <6.0.1.1.0.20040311173602.047bf528@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 4 Apr 2004 22:24:11 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt D. Zeilenga writes: >At 10:09 AM 3/9/2004, Hallvard B Furuseth wrote: > >>>> (2) Client authorization by means of access control based on the >>>> requestor's authenticated identity, >>> >>> Given that LDAP doesn't offer an authorization (access control) >>> model, this seems dubious (even with the note below). However, I >>> don't have a suggestion (at the moment) on how to better address >>> this. >> >> Put "Servers are expected to support" in front of the sentence? > > I don't think servers are necessarily expected to support a means of > access control. There are, after all, servers which do not support > any form of authentication. But more importantly, this list is of > security services LDAP provides. I don't think LDAP provide this > expectation and, even if it did, it's only an expectation. All true, but on the other hand, parts of Authmeth - at least the authorization identity - are mostly pointless without access control, while Bind in general is mostly done for access control in many situations. So I think we do need to mention it somehow. Maybe (2) Servers can implement client authorization by means of access control based on the requestor's authenticated identity, though this is not part of this standard, or turn it around a bit: (2) Server implementations can make use of the requestor's authenticated identity to implement client authorization by means of access control, though how to do so is not part of this standard, Anyway, I've said my piece now and won't kick if (2) is deleted. >>>> Given the presence of the Directory, there is a strong desire to see >>>> mechanisms where identities take the form of an LDAP distinguished >>>> name [LDAPDN] and authentication data can be stored in the >>>> directory. >>> >>> s/see/use/ >>> s/take the form of an LDAP distinguished name/ >>> s/are represented as distinguished names [X.501][Models] in string >>> form [LDAPDN]/. >> >>>> This means that this data must be updated outside the >>>> protocol or only updated in sessions well protected against >>>> snooping. >>> >>> s/snooping/eavesdropping/ (use RFC2828 term) >> >> This sentence has nothing to do with DN identities and authentication >> data in the directory. It also applies if the server supports an >> extended operation to modify passwords stored outside the directory, >> with non-DN identities. I think it belongs in Section 11 - unless > > This section is introductory. It's providing some background as to > why particular security services are offered and why particular > applicability statements have been made. Section 11 is basically > stating a security consideration. OK. But then 'This means that' should be removed, and that sentence be moved out of that paragraph. At least I don't see the logic of why it follows from the previous sentence. The same applies to passwords _not_ stored in the directory, if there is an extended operation which can update non-directory passwords. Maybe the sentence should go to Section 11, maybe just to the next paragraph, I don't know. >>> suggest: >>> It is also desirable to allow authentication methods to >>> carry identities (other than DNs) that are familiar to the >>> user or that are used in other systems. >> >> ...and also to authenticate against existing credentials maintained and >> stored outside the LDAP installation. > > It can be argued that "used" encompasses both "maintained" and "stored". True, but since this is an introductory text and not a text for implementors to carefully interpret, it's better to be clear. "used and/or stored" should be ample, though. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 4 17:38:49 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12115 for ; Sun, 4 Apr 2004 17:38:49 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i34LbU0J072085; Sun, 4 Apr 2004 21:37:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i34LYgQA072010; Sun, 4 Apr 2004 21:34:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 4 Apr 2004 21:34:42 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i34LYflq072000 for ; Sun, 4 Apr 2004 21:34:41 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i34LYfMs090315; Sun, 4 Apr 2004 21:34:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040404132611.0497f588@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 04 Apr 2004 14:34:33 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Authentication issues (Re: authmeth review notes [long]) Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.1.1.0.20040227070642.04cd3330@127.0.0.1> <6.0.1.1.0.20040311183843.047d2950@127.0.0.1> <6.0.1.1.0.20040311213043.047c2260@127.0.0.1> <6.0.1.1.0.20040313080748.04897250@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: While I do not agree with many of your points (and could argue them point by point), I'd like to refocus this discussion on the offered text and how it could be word-smithed to be more consistent the consensus already reached on a number of issues in this area. In particular, >>>> s/more passwords/more passwords, each an OCTET STRING,/ >>>> s/compare/compare in an octet wise/ [as clarified] is, I agree, problematic. Mainly because it implies that the each of the stored values is an OCTET STRING. I also did not intend to disallow use of various hash functions (or even other functions such as U-Mich's ces) to be used in comparisons. I do believe consensus did support changing the TS to allow such (if it could be done in a reasonable manner). My intent was more to clarify that the presented value is an OCTET STRING and servers must be prepared to handle (but not necessarily support) arbitrary content of this protocol field. While mostly a protocol issue, because of past problems in this area, I think it something which [authmeth] should at least hint to (and clarification to the earlier part of this section should be sufficient). Additionaly, as we discussed before, there are a number of limitations on the kinds of password storage mechanisms that can be used. In particular, one's which require recovering user input before application of SASLprep. This likely can be handled as a note to implementors. To more this forward, I will shortly offer new changes for the WG to consider. From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 4 22:44:39 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22469 for ; Sun, 4 Apr 2004 22:44:38 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i352VUGu082806; Mon, 5 Apr 2004 02:43:30 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i352RR6V082699; Mon, 5 Apr 2004 02:27:27 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 5 Apr 2004 02:27:27 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i352RPcC082689 for ; Mon, 5 Apr 2004 02:27:25 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i352ROMs094278; Mon, 5 Apr 2004 02:27:25 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040404183926.049add40@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 04 Apr 2004 19:27:16 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Intro issues (Was: authmeth review notes [long]) Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.1.1.0.20040227070642.04cd3330@127.0.0.1> <6.0.1.1.0.20040311173602.047bf528@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 01:24 PM 4/4/2004, Hallvard B Furuseth wrote: >So I think we do need to mention it somehow. > >Maybe > > (2) Servers can implement client authorization by means of access > control based on the requestor's authenticated identity, though > this is not part of this standard, > >or turn it around a bit: > > (2) Server implementations can make use of the requestor's > authenticated identity to implement client authorization by > means of access control, though how to do so is not part of > this standard, > >Anyway, I've said my piece now and won't kick if (2) is deleted. Each of the paragraphs should be something which LDAP, as defined in this specification, offers. While it is true that LDAP implementations can offer access controls, LDAP doesn't. However, it can be said that LDAP offers facilities to support local access control mechanisms (e.g., insufficientAccessRights result code). So, maybe: (2) mechanisms to support vendor-specific access control facilities (LDAP does not offer a standard access control facility) Alternatively, we could expand (1) to note that authentication methods can be used in support of vendor-specific access control facilities. >>>>> Given the presence of the Directory, there is a strong desire to see >>>>> mechanisms where identities take the form of an LDAP distinguished >>>>> name [LDAPDN] and authentication data can be stored in the >>>>> directory. >>>> >>>> s/see/use/ >>>> s/take the form of an LDAP distinguished name/ >>>> s/are represented as distinguished names [X.501][Models] in string >>>> form [LDAPDN]/. >>> >>>>> This means that this data must be updated outside the >>>>> protocol or only updated in sessions well protected against >>>>> snooping. >>>> >>>> s/snooping/eavesdropping/ (use RFC2828 term) >>> >>> This sentence has nothing to do with DN identities and authentication >>> data in the directory. It also applies if the server supports an >>> extended operation to modify passwords stored outside the directory, >>> with non-DN identities. I think it belongs in Section 11 - unless >> >> This section is introductory. It's providing some background as to >> why particular security services are offered and why particular >> applicability statements have been made. Section 11 is basically >> stating a security consideration. > >OK. But then 'This means that' should be removed, and that sentence be >moved out of that paragraph. At least I don't see the logic of why it >follows from the previous sentence. I think it kind of follows from the concern "or worse, they will support only clear text passwords that provide inadequate security for most circumstances." However, it's weak in that implies the mechanism be used doesn't provide adequate protection itself (and not only for itself, but also the session). >The same applies to passwords _not_ >stored in the directory, as well as to cases were the authentication identity is not in the form of a DN. >if there is an extended operation which can >update non-directory passwords. Maybe the sentence should go to Section >11, maybe just to the next paragraph, I don't know. I think it appropriate in the Introduction to state that because of the strong desire to use simple DN+password, other plain text authentication mechanisms, or mechanisms which do not provide data security services for the session, it is desirable to define a mechanism for establishing data security services at the transport layer. Then in security considerations, we can focus on particular cases where it important to establish data security services. >>>> suggest: >>>> It is also desirable to allow authentication methods to >>>> carry identities (other than DNs) that are familiar to the >>>> user or that are used in other systems. >>> >>> ...and also to authenticate against existing credentials maintained and >>> stored outside the LDAP installation. >> >> It can be argued that "used" encompasses both "maintained" and "stored". > >True, but since this is an introductory text and not a text for >implementors to carefully interpret, it's better to be clear. >"used and/or stored" should be ample, though. I think "and/or stored" is distracting and hence less clear. (It seems quite irrelevant whether or not the identity used is ever stored.) Are just concerned that "used" is somehow more restrictive than "used and/or stored"? A different wording might better address that concern. How about? It is also desirable to allow authentication methods to carry identities other than DNs, including ones familiar to the user or ones used in another system. From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 4 22:46:53 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22556 for ; Sun, 4 Apr 2004 22:46:52 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i352bPOe083216; Mon, 5 Apr 2004 02:46:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i352Wep6083008; Mon, 5 Apr 2004 02:32:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 5 Apr 2004 02:32:40 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i352WceO082970; Mon, 5 Apr 2004 02:32:38 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 12:32:16 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6547.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Distinguished values Date: Mon, 5 Apr 2004 12:32:16 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638101395FBE@ausyms21.ca.com> Thread-Topic: Distinguished values Thread-Index: AcQaYr8hkS4mbNwOQmiZ7a3rqKsLYAAUyOLA From: "Ramsay, Ron" To: "Hallvard B Furuseth" Cc: "Kurt D. Zeilenga" , X-OriginalArrivalTime: 05 Apr 2004 02:32:16.0767 (UTC) FILETIME=[362040F0:01C41AB6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id i352WceO082979 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Have you got lost in the semantics. The values in the AVA *are* values from the entry. Naturally, when you specify a DN, you may choose values that match, but this is a choice that you make. The meaning of the AVA is that it identifies a distinguished value. Ron -----Original Message----- From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no] Sent: Monday, 5 April 2004 02:34 To: Ramsay, Ron Cc: Kurt D. Zeilenga; ietf-ldapbis@OpenLDAP.org Subject: RE: Distinguished values Ramsay, Ron writes: > Yes, but you can't match attributes, only attribute values! > >Kurt D. Zeilenga writes: >> For instance, 2.2.1's >> These AVAs are chosen from the attributes of the entry. >> could be replaced with: >> These AVAs are chosen to match attributes of the entry. "These AVAs are chosen to match values from the attributes of the entry?" I suppose one could quibble that one can then choose RDN cn=foo to match street:foo when there is no cn:foo in the entry, but... um. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 7 09:40:29 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20654 for ; Wed, 7 Apr 2004 09:40:29 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i37DVk3E081935; Wed, 7 Apr 2004 13:39:23 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i37DNrve080919; Wed, 7 Apr 2004 13:23:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 7 Apr 2004 13:23:53 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i37DNCbl080821; Wed, 7 Apr 2004 13:23:13 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BBD1I-0005pf-OA; Wed, 07 Apr 2004 15:23:08 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BBD1G-0005Y5-CO; Wed, 07 Apr 2004 15:23:06 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BBD1F-0007J1-00; Wed, 7 Apr 2004 15:23:05 +0200 From: Hallvard B Furuseth Message-Id: To: "Ramsay, Ron" Cc: "Kurt D. Zeilenga" , ietf-ldapbis@OpenLDAP.org Subject: RE: Distinguished values In-Reply-To: <1395B4B334FCC143B36AF788E68B638101395FBE@ausyms21.ca.com> References: <1395B4B334FCC143B36AF788E68B638101395FBE@ausyms21.ca.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 7 Apr 2004 15:23:05 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Ramsay, Ron writes: > Have you got lost in the semantics. The values in the AVA *are* values > from the entry. Not if they are different from the values in the entry. Unless you mean something else with "are" than I do:-) > Naturally, when you specify a DN, you may choose values that match, ...but are not identical, you mean? Yes, that's my point. > but this is a choice that you make. The meaning of the AVA is that it > identifies a distinguished value. Sure. Anyway, if we are talking past each other here, maybe that means Kurt's original suggestion is best despite your original objection. >From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no] >Ramsay, Ron writes: >> >> Yes, but you can't match attributes, only attribute values! >> >>Kurt D. Zeilenga writes: >>> For instance, 2.2.1's >>> These AVAs are chosen from the attributes of the entry. >>> could be replaced with: >>> These AVAs are chosen to match attributes of the entry. > > "These AVAs are chosen to match values from the attributes of the > entry?" > > I suppose one could quibble that one can then choose RDN cn=foo to > match street:foo when there is no cn:foo in the entry, but... um. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 15 14:04:58 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09862 for ; Thu, 15 Apr 2004 14:04:57 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3FI3K2d017704; Thu, 15 Apr 2004 18:03:41 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3FHwtmh017131; Thu, 15 Apr 2004 17:58:55 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 15 Apr 2004 17:58:55 +0000 Received: from boole.openldap.org (kurt@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3FHwjx2017098 for ; Thu, 15 Apr 2004 17:58:45 GMT (envelope-from kurt@boole.openldap.org) Received: (from kurt@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) id i3FHwjXH017097 for ietf-ldapbis@openldap.org; Thu, 15 Apr 2004 10:58:45 -0700 (PDT) (envelope-from kurt) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3FHqf84016000 for ; Thu, 15 Apr 2004 17:52:42 GMT (envelope-from marty.schleiff@boeing.com) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA03880 for ; Thu, 15 Apr 2004 10:52:20 -0700 (PDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id KAA23459 for ; Thu, 15 Apr 2004 10:52:18 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i3FHo8Q11983 for ; Thu, 15 Apr 2004 12:50:08 -0500 (CDT) Received: from XCH-NW-08.nw.nos.boeing.com ([192.42.226.83]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Thu, 15 Apr 2004 10:50:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42312.167D9A28" Subject: FW: Active Directory question Date: Thu, 15 Apr 2004 10:50:06 -0700 Message-ID: Thread-Topic: Active Directory question Thread-Index: AcQiTZV+rK3aXZICTbKgaHIh4GRABQAxCfRw From: "Schleiff, Marty" To: X-OriginalArrivalTime: 15 Apr 2004 17:50:07.0058 (UTC) FILETIME=[16B54B20:01C42312] Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C42312.167D9A28 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gentlemen, =20 Can you please let me know your impressions about the MS Active = Directory response with ranges of multi-valued attribute values? Also, = using tools lke ldapsearch, how could I retrieve subsequent ranges? =20 Thx, Marty.Schleiff@boeing.com; CISSP=20 Associate Technical Fellow - Cyber Identity Specialist=20 IT Access & Security Services=20 (425) 957-5667=20 -----Original Message----- From: Chris Harding [mailto:c.harding@opengroup.org]=20 Sent: Wednesday, April 14, 2004 11:20 AM To: Schleiff, Marty Subject: RE: Active Directory question Hi, Marty - Thanks - sounds like this is definitely one for the IETF experts! At 18:52 14/04/2004, you wrote: Hi Dr. harding, =20 Thanks for your response. I'd like to point out that this issue is not = about a server limiting the number of entries to return; instead it's = about the number of values within a single multi-valued attribute to = return. The entry gets returned, but not all its attribute values. =09 Marty.Schleiff@boeing.com; CISSP=20 Associate Technical Fellow - Cyber Identity Specialist=20 IT Access & Security Services=20 (425) 957-5667=20 =09 -----Original Message----- =09 From: Chris Harding [mailto:c.harding@opengroup.org]=20 =09 Sent: Wednesday, April 14, 2004 9:32 AM =09 To: Schleiff, Marty =09 Subject: Re: Active Directory question =09 =09 Hi, Marty - =09 =09 Our Product Standard is based on the IETF RFCs, so I think this would = be legal behavior for an LDAP Certified server only if it is legal = according to RFC 2251. Now the RFC says that "Servers may enforce a = maximum number of entries to return" (section 4.5.1 under "sizelimit") = so it looks to me as though the behavior may be legal. However, I have = got my fingers burnt before trying to interpret this RFC, and I suggest = you send mail to the ldapbis list (ietf-ldapbis@OpenLDAP.org) if you = want to find out what the IETF experts think. =09 =09 At 22:57 13/04/2004, you wrote: =09 Hi Dr. Harding, =09 =09 Microsoft Active Directory responds to queries on groups having more = than 1024 members with the first 1000 members, with the 'member' = attribute changed to 'member;range=3D0-999'. See: = http://www.hut.fi/cc/docs/kerberos/nss_ldap.html =09 =09 In TOG's efforts to brand "ldap-compliant" servers and applications, = is this practice condoned? So far I've not been able to figure out how = to get the next batch of members; I'm not sure it's possible via LDAP. =09 =09 Marty.Schleiff@boeing.com; CISSP =09 Associate Technical Fellow - Cyber Identity Specialist =09 IT Access & Security Services =09 (425) 957-5667 Regards, =09 =09 Chris =09 +++++ =09 =09 = =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=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=3D=3D=3D=3D =09 Dr. Christopher J. Harding =09 T H E Executive Director for the Directory Interoperability Forum =09 O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK =09 G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 =09 WWW: http://www.opengroup.org = Mobile: +44 774 063 1520 =09 = =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=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=3D=3D=3D=3D =09 Boundaryless Information Flow: Managing the Flow =09 Brussels Hilton Hotel, Brussels, Belgium. April 19-23, 2004 =09 http://www.opengroup.org/brussels2004/ =09 = =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=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=3D=3D=3D=3D =09 Regards, Chris +++++ =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=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=3D=3D=3D=3D Dr. Christopher J. Harding T H E Executive Director for the Directory Interoperability Forum 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 902 3018 WWW: http://www.opengroup.org = Mobile: +44 774 063 1520 =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=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=3D=3D=3D=3D Boundaryless Information Flow: Managing the Flow Brussels Hilton Hotel, Brussels, Belgium. April 19-23, 2004 http://www.opengroup.org/brussels2004/ =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=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=3D=3D=3D=3D ------_=_NextPart_001_01C42312.167D9A28 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gentlemen, Can=20 you please let me know your impressions about the MS Active Directory = response=20 with ranges of multi-valued attribute values? Also, using tools lke = ldapsearch,=20 how could I retrieve subsequent ranges? Thx, Marty.Schleiff@boeing.com;=20 CISSP Associate=20 Technical Fellow - Cyber Identity Specialist IT Access & Security=20 Services (425)=20 957-5667 -----Original Message----- From: Chris Harding=20 [mailto:c.harding@opengroup.org] Sent: Wednesday, April 14, = 2004=20 11:20 AM To: Schleiff, Marty Subject: RE: Active = Directory=20 question Hi, Marty - Thanks - sounds like = this is=20 definitely one for the IETF experts! At 18:52 14/04/2004, you = wrote: Hi Dr. harding, Thanks for your response. I'd like to point out that this = issue is not=20 about a server limiting the number of entries to return; instead it's = about=20 the number of values within a single multi-valued attribute to return. = The=20 entry gets returned, but not all its attribute = values. Marty.Schleiff@boeing.com; CISSP Associate=20 Technical Fellow - Cyber Identity Specialist IT Access & Security Services (425) 957-5667 -----Original Message----- From: Chris Harding [mailto:c.harding@opengroup.org] Sent: Wednesday, April 14, 2004 9:32 AM To: Schleiff, Marty Subject: Re: Active Directory question Hi, Marty - Our Product Standard is based on the IETF RFCs, so I think this = would be=20 legal behavior for an LDAP Certified server only if it is legal = according to=20 RFC 2251. Now the RFC says that "Servers may enforce a maximum = number of=20 entries to return" (section 4.5.1 under "sizelimit") so it looks to = me as=20 though the behavior may be legal. However, I have got my fingers = burnt=20 before trying to interpret this RFC, and I suggest you send mail to = the=20 ldapbis list (ietf-ldapbis@OpenLDAP.org) if you want to find out = what the=20 IETF experts think. At 22:57 13/04/2004, you wrote: Hi Dr. Harding, Microsoft Active Directory responds to queries on groups = having more=20 than 1024 members with the first 1000 members, with the 'member' = attribute=20 changed to 'member;range=3D0-999'. See: http://www.hut.fi/cc/docs/kerberos/nss_ldap.html In TOG's efforts to brand "ldap-compliant" servers and = applications,=20 is this practice condoned? So far I've not been able to figure out = how to=20 get the next batch of members; I'm not sure it's possible via=20 LDAP. Marty.Schleiff@boeing.com; CISSP Associate Technical Fellow - Cyber Identity Specialist IT Access & Security Services (425) 957-5667 Regards, Chris +++++ = =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=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=3D=3D=3D=3D<= BR> Dr. = Christopher J. Harding T H E Executive Director for the = Directory=20 Interoperability Forum O P E N Apex Plaza, Forbury Road, Reading RG1 = 1AX,=20 UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 = 902=20 3018 = WWW: http://www.opengroup.org Mobile: +44 774 063 = 1520 = =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=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=3D=3D=3D=3D<= BR> Boundaryless Information Flow: Managing the Flow Brussels Hilton Hotel, Brussels, Belgium. April 19-23, = 2004 http://www.opengroup.org/brussels2004/ = =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=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=3D=3D=3D=3D<= BR> Regards, Chris +++++ =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=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=3D=3D=3D=3D = =20 Dr. Christopher J. Harding T H E Executive = Director=20 for the Directory Interoperability Forum O P E N = Apex=20 Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 = 3018 = WWW: http://www.opengroup.org=20 Mobile: +44 774 063=20 1520 =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=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=3D=3D=3D=3D= Boundaryless=20 Information Flow: Managing the Flow Brussels Hilton Hotel, Brussels,=20 Belgium. April 19-23, 2004 http://www.opengroup.org/brussels2004/ =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=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=3D=3D=3D=3D =00 ------_=_NextPart_001_01C42312.167D9A28-- ------_=_NextPart_001_01C42312.167D9A28-- From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 15 21:21:20 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16172 for ; Thu, 15 Apr 2004 21:21:19 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3G1JvKf068387; Fri, 16 Apr 2004 01:19:58 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3G14nFB067185; Fri, 16 Apr 2004 01:04:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 16 Apr 2004 01:04:49 +0000 Received: from boole.openldap.org (kurt@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3G14mG4067172 for ; Fri, 16 Apr 2004 01:04:48 GMT (envelope-from kurt@boole.openldap.org) Received: (from kurt@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) id i3G14mgN067171 for ietf-ldapbis@openldap.org; Thu, 15 Apr 2004 18:04:48 -0700 (PDT) (envelope-from kurt) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3FHqf84016000 for ; Thu, 15 Apr 2004 17:52:42 GMT (envelope-from marty.schleiff@boeing.com) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA03880 for ; Thu, 15 Apr 2004 10:52:20 -0700 (PDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id KAA23459 for ; Thu, 15 Apr 2004 10:52:18 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i3FHo8Q11983 for ; Thu, 15 Apr 2004 12:50:08 -0500 (CDT) Received: from XCH-NW-08.nw.nos.boeing.com ([192.42.226.83]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Thu, 15 Apr 2004 10:50:07 -0700 content-class: urn:content-classes:message Subject: FW: Active Directory question Date: Thu, 15 Apr 2004 10:50:06 -0700 Message-ID: Thread-Topic: Active Directory question Thread-Index: AcQiTZV+rK3aXZICTbKgaHIh4GRABQAxCfRw From: "Schleiff, Marty" To: X-OriginalArrivalTime: 15 Apr 2004 17:50:07.0058 (UTC) FILETIME=[16B54B20:01C42312] Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Gentlemen, Can you please let me know your impressions about the MS Active Directory response with ranges of multi-valued attribute values? Also, using tools lke ldapsearch, how could I retrieve subsequent ranges? Thx, Marty.Schleiff@boeing.com; CISSP Associate Technical Fellow - Cyber Identity Specialist IT Access & Security Services (425) 957-5667 -----Original Message----- From: Chris Harding [mailto:c.harding@opengroup.org] Sent: Wednesday, April 14, 2004 11:20 AM To: Schleiff, Marty Subject: RE: Active Directory question Hi, Marty - Thanks - sounds like this is definitely one for the IETF experts! At 18:52 14/04/2004, you wrote: Hi Dr. harding, Thanks for your response. I'd like to point out that this issue is not about a server limiting the number of entries to return; instead it's about the number of values within a single multi-valued attribute to return. The entry gets returned, but not all its attribute values. Marty.Schleiff@boeing.com; CISSP Associate Technical Fellow - Cyber Identity Specialist IT Access & Security Services (425) 957-5667 -----Original Message----- From: Chris Harding [mailto:c.harding@opengroup.org] Sent: Wednesday, April 14, 2004 9:32 AM To: Schleiff, Marty Subject: Re: Active Directory question Hi, Marty - Our Product Standard is based on the IETF RFCs, so I think this would be legal behavior for an LDAP Certified server only if it is legal according to RFC 2251. Now the RFC says that "Servers may enforce a maximum number of entries to return" (section 4.5.1 under "sizelimit") so it looks to me as though the behavior may be legal. However, I have got my fingers burnt before trying to interpret this RFC, and I suggest you send mail to the ldapbis list (ietf-ldapbis@OpenLDAP.org) if you want to find out what the IETF experts think. At 22:57 13/04/2004, you wrote: Hi Dr. Harding, Microsoft Active Directory responds to queries on groups having more than 1024 members with the first 1000 members, with the 'member' attribute changed to 'member;range=0-999'. See: http://www.hut.fi/cc/docs/kerberos/nss_ldap.html In TOG's efforts to brand "ldap-compliant" servers and applications, is this practice condoned? So far I've not been able to figure out how to get the next batch of members; I'm not sure it's possible via LDAP. Marty.Schleiff@boeing.com; CISSP Associate Technical Fellow - Cyber Identity Specialist IT Access & Security Services (425) 957-5667 Regards, Chris +++++ =========================================================================== Dr. Christopher J. Harding T H E Executive Director for the Directory Interoperability Forum 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 902 3018 WWW: http://www.opengroup.org Mobile: +44 774 063 1520 =========================================================================== Boundaryless Information Flow: Managing the Flow Brussels Hilton Hotel, Brussels, Belgium. April 19-23, 2004 http://www.opengroup.org/brussels2004/ =========================================================================== Regards, Chris +++++ =========================================================================== Dr. Christopher J. Harding T H E Executive Director for the Directory Interoperability Forum 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 902 3018 WWW: http://www.opengroup.org Mobile: +44 774 063 1520 ======================= ==================================================== Boundaryless Information Flow: Managing the Flow Brussels Hilton Hotel, Brussels, Belgium. April 19-23, 2004 http://www.opengroup.org/brussels2004/ =========================================================================== From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 15 23:10:59 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21886 for ; Thu, 15 Apr 2004 23:10:58 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3G39HZ1074383; Fri, 16 Apr 2004 03:09:23 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3G37go1074332; Fri, 16 Apr 2004 03:07:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 16 Apr 2004 03:07:42 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3G37eLm074322 for ; Fri, 16 Apr 2004 03:07:40 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3G37UMs059972; Fri, 16 Apr 2004 03:07:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040415182406.048bccf8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 15 Apr 2004 20:07:27 -0700 To: "Schleiff, Marty" From: "Kurt D. Zeilenga" Subject: Re: FW: Active Directory question Cc: ldapext@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Marty, I've adjusted the cc/bcc lists to move this discussion towards the LDAPEXT mailing list. That's the usual forum for discussing the Internet engineering of LDAP extensions. This is an example of, amongst other things, a horribly designed LDAP extension. It's most serious flaw is that the extension is truly non-optional. If the server elects to implement this extension, so must its clients (if they want to get all available values). Kurt At 10:50 AM 4/15/2004, Schleiff, Marty wrote: >Gentlemen, > >Can you please let me know your impressions about the MS Active >Directory response with ranges of multi-valued attribute values? >Also, using tools lke ldapsearch, how could I retrieve subsequent >ranges? > >Thx, > >Marty.Schleiff@boeing.com; CISSP >Associate Technical Fellow - Cyber Identity Specialist >IT Access & Security Services >(425) 957-5667 >-----Original Message----- >From: Chris Harding [mailto:c.harding@opengroup.org] >Sent: Wednesday, April 14, 2004 11:20 AM >To: Schleiff, Marty >Subject: RE: Active Directory question > >Hi, Marty - > >Thanks - sounds like this is definitely one for the IETF experts! > >At 18:52 14/04/2004, you wrote: >Hi Dr. harding, > >Thanks for your response. I'd like to point out that this issue is >not about a server limiting the number of entries to return; instead >it's about the number of values within a single multi-valued >attribute to return. The entry gets returned, but not all its >attribute values. > >Marty.Schleiff@boeing.com; CISSP >Associate Technical Fellow - Cyber Identity Specialist >IT Access & Security Services >(425) 957-5667 >-----Original Message----- >From: Chris Harding [mailto:c.harding@opengroup.org] >Sent: Wednesday, April 14, 2004 9:32 AM >To: Schleiff, Marty >Subject: Re: Active Directory question > >Hi, Marty - > >Our Product Standard is based on the IETF RFCs, so I think this >would be legal behavior for an LDAP Certified server only if it >is legal according to RFC 2251. Now the RFC says that "Servers may >enforce a maximum number of entries to return" (section 4.5.1 under >"sizelimit") so it looks to me as though the behavior may be legal. >However, I have got my fingers burnt before trying to interpret >this RFC, and I suggest you send mail to the ldapbis list >(ietf-ldapbis@OpenLDAP.org) if you want to find out what the IETF >experts think. > >At 22:57 13/04/2004, you wrote: >Hi Dr. Harding, > >Microsoft Active Directory responds to queries on groups having >more than 1024 members with the first 1000 members, with the >'member' attribute changed to 'member;range=0-999'. See: >http://www.hut.fi/cc/docs/kerberos/nss_ldap.html In TOG's efforts >to brand "ldap-compliant" servers and applications, is this practice >condoned? So far I've not been able to figure out how to get the >next batch of members; I'm not sure it's possible via LDAP. > >Marty.Schleiff@boeing.com; CISSP >Associate Technical Fellow - Cyber Identity Specialist >IT Access & Security Services >(425) 957-5667 > > > >Regards, > >Chris >+++++ > >=========================================================================== > Dr. Christopher J. Harding > T H E Executive Director for the Directory Interoperability Forum > 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 902 3018 > WWW: http://www.opengroup.org Mobile: +44 774 063 1520 >=========================================================================== >Boundaryless Information Flow: Managing the Flow >Brussels Hilton Hotel, Brussels, Belgium. April 19-23, 2004 >http://www.opengroup.org/brussels2004/ >=========================================================================== > > > >Regards, > >Chris >+++++ > >=========================================================================== > Dr. Christopher J. Harding > T H E Executive Director for the Directory Interoperability Forum > 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 902 3018 > WWW: http://www.opengroup.org Mobile: +44 774 063 1520 >======================= ==================================================== >Boundaryless Information Flow: Managing the Flow >Brussels Hilton Hotel, Brussels, Belgium. April 19-23, 2004 >http://www.opengroup.org/brussels2004/ >=========================================================================== From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 10:47:10 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13398 for ; Fri, 16 Apr 2004 10:47:10 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GEjMMC003670; Fri, 16 Apr 2004 14:45:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3GEiplV003612; Fri, 16 Apr 2004 14:44:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 16 Apr 2004 14:44:51 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GEieGS003592 for ; Fri, 16 Apr 2004 14:44:41 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1BEUa4-0000nh-JS for ietf-ldapbis@openldap.org; Fri, 16 Apr 2004 16:44:36 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.30) id 1BEUZz-00083a-7X for ietf-ldapbis@openldap.org; Fri, 16 Apr 2004 16:44:31 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BEUZx-0003es-00 for ietf-ldapbis@openldap.org; Fri, 16 Apr 2004 16:44:29 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: models: objectClass;option Date: Fri, 16 Apr 2004 16:44:29 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Should [Models] say anything about objectClass attributes with options? I can't say it worries me, but maybe someone else cares. That is, MAY/SHOULD/MUST [NOT] the implementation treat an object class attribute with a recognized option as a normal object class unless the option description says differently? Example: dn: l=foo,o=mysil l: foo objectClass: locality objectClass;lang-no: person objectClass;lang-en: country -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 11:31:04 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16348 for ; Fri, 16 Apr 2004 11:31:03 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GFSOMA006741; Fri, 16 Apr 2004 15:29:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3GFAOsi005555; Fri, 16 Apr 2004 15:10:24 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 16 Apr 2004 15:10:24 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GFAFgu005528 for ; Fri, 16 Apr 2004 15:10:16 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3GFAFMs071261; Fri, 16 Apr 2004 15:10:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040416080131.049f0570@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 16 Apr 2004 08:10:11 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: models: objectClass;option Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 07:44 AM 4/16/2004, Hallvard B Furuseth wrote: >Should [Models] say anything about objectClass attributes with >options? Well, should [Models] say anything about subtypes of this or various other attributes. I think not namely because one could devise an extension where that made sense. For sense, one could have 'objectClass;auxiliary' 'objectClass;abstract' and 'objectClass;structural' which separately listed classes of each kind, if requested that way. I don't see much problem with that. I do see a problem, in general, with extensions which are not truly optional. While I think that's mostly a topic for an extension guidelines document, I think it would be wise for to make a statement in this area in an appropriate place. LDAP is an extensible protocol. Extensions are expected to be truly optional. >I can't say it worries me, but maybe someone else cares. > >That is, MAY/SHOULD/MUST [NOT] the implementation treat an object class >attribute with a recognized option as a normal object class unless the >option description says differently? > >Example: > dn: l=foo,o=mysil > l: foo > objectClass: locality > objectClass;lang-no: person > objectClass;lang-en: country > >-- >Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 16:21:11 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04894 for ; Fri, 16 Apr 2004 16:21:11 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GKFX1g034463; Fri, 16 Apr 2004 20:19:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3GKF2nm034415; Fri, 16 Apr 2004 20:15:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 16 Apr 2004 20:15:02 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GKF11t034380 for ; Fri, 16 Apr 2004 20:15:01 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 2004 14:14:40 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 16 Apr 2004 14:13:48 -0600 From: "Jim Sermersheim" To: , Subject: Re: Protocol: Omitting default values Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartFADB376C.0__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: 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. --=__PartFADB376C.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit My feeling is that it is safer to leave the current text and force future extension implementations to specify their own encoding rules when those of Section 5.1 are overly restrictive. Jim >>> Hallvard B Furuseth 3/9/04 6:52:35 AM >>> Protocol-22 says: > 5.1. Protocol Encoding > The protocol elements of LDAP SHALL be encoded for exchange using the > Basic Encoding Rules [BER] of [ASN.1] with the following > restrictions: > (...) > - If a value of a type is its default value, it is absent. Only some > BOOLEAN and INTEGER types have default values in this protocol > definition. This restriction can be impractical to implement for default values of complex types. It might be better if it only applied to simple types That's not relevant for the core protocol, but can be for controls and extended requests/responses whose values are encoded as ASN.1: 4.1.11. Controls When a controlValue is defined in terms of ASN.1, and BER encoded according to Section 5.1, it also follows the extensibility rules in Section 4. 4.12. Extended Operation Values that are defined in terms of ASN.1 and BER encoded according to Section 5.1, also follow the extensibility rules in Section 4. Note that these texts do not say that ASN.1 values need to obey these restrictions; the extensions could instead define their own restrictions without the one I quoted. But I suspect extensions that do use ASN.1 with complex defaults would prefer to do just that, so it would be simpler if they didn't have to. OTOH, changing this now will change the spec of such extensions that already depend on this restriction. So I'm not sure what is best. -- Hallvard --=__PartFADB376C.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My feeling is that it is safer to leave the current text and force = future extension implementations to specify their own encoding rules when = those of Section 5.1 are overly restrictive.
 
Jim

>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.= no> 3/9/04 6:52:35 AM >>>
Protocol-22 says:

> = 5.1. Protocol Encoding

> The protocol elements of LDAP SHALL be = encoded for exchange using the
> Basic Encoding Rules [BER] of = [ASN.1] with the following
> restrictions:
> (...)
> - = If a value of a type is its default value, it is absent. Only some
> = BOOLEAN and INTEGER types have default values in this protocol
> = definition.

This restriction can be impractical to implement for = default values of
complex types. It might be better if it only applied = to simple types
That's not relevant for the core protocol, but can be = for controls and
extended requests/responses whose values are encoded = as ASN.1:

4.1.11. Controls
When a controlValue is defined in = terms
of ASN.1, and BER encoded according to Section 5.1, it also = follows
the extensibility rules in Section 4.
4.12. Extended = Operation
Values that are defined in terms of ASN.1 and BER encoded =
according to Section 5.1, also follow the extensibility rules in =
Section 4.

Note that these texts do not say that ASN.1 values = need to obey these
restrictions; the extensions could instead define = their own restrictions
without the one I quoted. But I suspect = extensions that do use ASN.1
with complex defaults would prefer to do = just that, so it would be
simpler if they didn't have to. OTOH, = changing this now will change
the spec of such extensions that already = depend on this restriction.
So I'm not sure what is best.

-- =
Hallvard
--=__PartFADB376C.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 16:28:20 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05663 for ; Fri, 16 Apr 2004 16:28:20 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GKR5rS035413; Fri, 16 Apr 2004 20:27:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3GKOxCJ035304; Fri, 16 Apr 2004 20:24:59 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 16 Apr 2004 20:24:59 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GKOsJt035282 for ; Fri, 16 Apr 2004 20:24:58 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 2004 14:24:34 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 16 Apr 2004 14:23:38 -0600 From: "Jim Sermersheim" To: , Subject: Re: protocol-22 comments Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part3213FFDA.0__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: 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. --=__Part3213FFDA.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >>> Hallvard B Furuseth h.b.furuseth@usit.uio.no> 3/9/04 7:20:19 AM >> >> 4.1.11. Controls > >> When an extension calls for a particular response control to be sent >> in response to a request control, the response and request controls >> are termed to be "paired". >> (...) >> The controlType field is the dotted-decimal representation of an >> OBJECT IDENTIFIER which uniquely identifies the control, or the >> request control and its paired response control. > >These paragraphs seem to imply that a request control may only solicit a >response control with the same OID as the request control, >and it cannot >solicit two response controls (with different OIDs). I think that's >wrong. You're right, it is often the case that a request is paired with a single response which is identified by the same OID, but not the rule. Also, there are a number of control specifications that return one type of response control with search entries and a different one with the search result done, thus I don't think the use of the term 'paired' is helpful. I'll fix. --=__Part3213FFDA.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

>> 4.1.11. Controls
>
>> When an extension = calls for a particular response control to be sent
>> in response = to a request control, the response and request controls
>> are = termed to be "paired".
>> (...)
>> The controlType field = is the dotted-decimal representation of an
>> OBJECT IDENTIFIER = which uniquely identifies the control, or the
>> request control = and its paired response control.
>
>These paragraphs seem to = imply that a request control may only solicit a
>response control = with the same OID as the request control,
>and it cannot
>solicit two response controls (with = different OIDs). I think that's
>wrong.
You're right, it is often the case that a request is paired with a = single response which is identified by the same OID, but not the rule. = Also, there are a number of control specifications that return one type of = response control with search entries and a different one with the search = result done, thus I don't think the use of the term 'paired' is helpful. = I'll fix.
 
--=__Part3213FFDA.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 16:46:48 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07722 for ; Fri, 16 Apr 2004 16:46:47 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GKj6fb036412; Fri, 16 Apr 2004 20:45:12 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3GKfYSb036149; Fri, 16 Apr 2004 20:41:34 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 16 Apr 2004 20:41:34 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GKfWdt036131 for ; Fri, 16 Apr 2004 20:41:33 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 2004 14:41:12 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 16 Apr 2004 14:40:21 -0600 From: "Jim Sermersheim" To: , Subject: Re: protocol-22 comments Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part496884A5.0__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: 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. --=__Part496884A5.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >>> Hallvard B Furuseth h.b.furuseth@usit.uio.no> 3/9/04 7:20:19 AM >> >> 4.1.11. Controls >> Additionally, unless order-dependent semantics are given in a >> specification, the order of a combination of controls in the SEQUENCE >> is ignored. > >This implies that controls (A, B) MUST behave identically with controls >(B, A). I think it should be, "the effect of the ordering of a >combination of controls in the SEQUENCE is unspecified"? When the control specification doesn't describe these ordering semantics, interoperability problems arise where one server may arbitrarily assign semantics to the order of two controls, and another may not. Clients will come to expect behavior that is not specified. Is there a reason for allowing order semantics as unspecified which outweighs the interoperability problems that come with it? Jim --=__Part496884A5.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>> Hallvard B Furuseth 3/9/04 7:20:19 AM >>">h.b.furuseth@usit.uio.no> 3/9/04 7:20:19 = AM >>
>> 4.1.11. Controls
>> Additionally, = unless order-dependent semantics are given in a
>> specification, = the order of a combination of controls in the SEQUENCE
>> is = ignored.
>
>This implies that controls (A, B) MUST behave = identically with controls
>(B, A). I think it should be, "the effect = of the ordering of a
>combination of controls in the SEQUENCE is = unspecified"?
When the control specification doesn't describe these ordering = semantics, interoperability problems arise where one server may arbitrarily= assign semantics to the order of two controls, and another may not. = Clients will come to expect behavior that is not specified.
 
Is there a reason for allowing order semantics as unspecified whi= ch outweighs the interoperability problems that come with it?
 
Jim
--=__Part496884A5.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 17:16:47 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10916 for ; Fri, 16 Apr 2004 17:16:47 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GLF4L8037962; Fri, 16 Apr 2004 21:15:54 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3GL66E6037380; Fri, 16 Apr 2004 21:06:06 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 16 Apr 2004 21:06:06 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GL63qo037364 for ; Fri, 16 Apr 2004 21:06:04 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1BEaXA-0005gx-Ej; Fri, 16 Apr 2004 23:06:00 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.30) id 1BEaX6-0005rG-4w; Fri, 16 Apr 2004 23:05:56 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BEaX4-0004WE-00; Fri, 16 Apr 2004 23:05:54 +0200 From: Hallvard B Furuseth Message-Id: To: Jim Sermersheim Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: protocol-22 comments In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 16 Apr 2004 23:05:54 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Jim Sermersheim writes: >>>> Hallvard B Furuseth h.b.furuseth@usit.uio.no> 3/9/04 7:20:19 AM >> >>> 4.1.11. Controls >>> Additionally, unless order-dependent semantics are given in a >>> specification, the order of a combination of controls in the SEQUENCE >>> is ignored. >> >> This implies that controls (A, B) MUST behave identically with controls >> (B, A). I think it should be, "the effect of the ordering of a >> combination of controls in the SEQUENCE is unspecified"? > > When the control specification doesn't describe these ordering > semantics, interoperability problems arise where one server may > arbitrarily assign semantics to the order of two controls, and another > may not. Clients will come to expect behavior that is not specified. > > Is there a reason for allowing order semantics as unspecified which > outweighs the interoperability problems that come with it? Only a vague suspicion that it may put a burden on implementations. I wonder if the simplest way to be sure this requirement is obeyed might be for the server to order request controls in ascending order by Octet String Ordering Match, or something, before parsing them. Which seems a bit excessive to me. I'm thinking partly of controls that are executed one at a time rather than setting a variable and acting on it later. However, also consider what to do if the same control appears twice, but containing different parameters, and the control is implemented by setting a variable for the operation to that parameter. With the current text, the server is required to always pick e.g. the parameter with lowest value, instead of just using the parameter in the last control. Or it could detect the situation and return unwillingToPerform, but then it will still need extra state info in order to notice the situation. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 17:28:33 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11264 for ; Fri, 16 Apr 2004 17:28:32 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GLRAVO038912; Fri, 16 Apr 2004 21:27:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3GLMmUN038722; Fri, 16 Apr 2004 21:22:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 16 Apr 2004 21:22:48 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GLMkmG038711 for ; Fri, 16 Apr 2004 21:22:47 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 2004 15:22:26 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 16 Apr 2004 15:21:27 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: protocol-22 comments Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartA1806C47.0__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: 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. --=__PartA1806C47.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >>>> Hallvard B Furuseth 4/16/04 3:05:54 PM >>> >>Jim Sermersheim writes: >>>>> Hallvard B Furuseth h.b.furuseth@usit.uio.no > 3/9/04 7:20:19 AM >> >>>> 4.1.11. Controls >>>> Additionally, unless order-dependent semantics are given in a >>>> specification, the order of a combination of controls in the SEQUENCE >>>> is ignored. >>> >>> This implies that controls (A, B) MUST behave identically with controls >>> (B, A). I think it should be, "the effect of the ordering of a >>> combination of controls in the SEQUENCE is unspecified"? >> >> When the control specification doesn't describe these ordering >> semantics, interoperability problems arise where one server may >> arbitrarily assign semantics to the order of two controls, and another >> may not. Clients will come to expect behavior that is not specified. >> >> Is there a reason for allowing order semantics as unspecified which >> outweighs the interoperability problems that come with it? > >Only a vague suspicion that it may put a burden on implementations. I >wonder if the simplest way to be sure this requirement is obeyed might >be for the server to order request controls in ascending order by Octet >String Ordering Match, or something, before parsing them. Which seems >a bit excessive to me. If there are any two controls that in any way affect each other, and if neither of the control specifications provide instructions on how they are to interact with each other (and whether order matters when doing so), then I think a server should fail the request as it has no idea how to properly execute the operation. >I'm thinking partly of controls that are executed one at a time rather >than setting a variable and acting on it later. Any given server implementation knows which controls it implements. It also should be aware of any ways in which two controls on a single operation might affect the operation's outcome (including whether ordering changes the outcome). If the combination of controls is underspecified, and ordering will affect the outcome, the server (if following the rule in the current draft) should not process the operation (at least that's my read of it). >However, also consider >what to do if the same control appears twice, but containing different >parameters, and the control is implemented by setting a variable for the >operation to that parameter. With the current text, the server is >required to always pick e.g. the parameter with lowest value, instead of >just using the parameter in the last control. Or it could detect the >situation and return unwillingToPerform, but then it will still need >extra state info in order to notice the situation. I think the text (though not explicitly) says the server should fail this scenario (unless the control specification states what to do). Jim --=__PartA1806C47.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> = 4/16/04 3:05:54 PM >>>
>>Jim Sermersheim writes:
>&= gt;>>> Hallvard B Furuseth h.b.furuseth@usit.uio.no > 3/9/04 7:20:19 AM >>>>>> 4.1.11. Controls
>>>> Additionally, = unless order-dependent semantics are given in a
>>>> = specification, the order of a combination of controls in the SEQUENCE
&g= t;>>> is ignored.
>>>
>>> This implies = that controls (A, B) MUST behave identically with controls
>>> = (B, A). I think it should be, "the effect of the ordering of a
>>&= gt; combination of controls in the SEQUENCE is unspecified"?
>> =
>> When the control specification doesn't describe these = ordering
>> semantics, interoperability problems arise where one = server may
>> arbitrarily assign semantics to the order of two = controls, and another
>> may not. Clients will come to expect = behavior that is not specified.
>>
>> Is there a reason = for allowing order semantics as unspecified which
>> outweighs = the interoperability problems that come with it?
>
>Only a = vague suspicion that it may put a burden on implementations. I
>wonde= r if the simplest way to be sure this requirement is obeyed might
>be= for the server to order request controls in ascending order by Octet
&g= t;String Ordering Match, or something, before parsing them. Which = seems
>a bit excessive to me.
If there are any two controls that in any way affect each other, and = if neither of the control specifications provide instructions on how they = are to interact with each other (and whether order matters when doing so), = then I think a server should fail the request as it has no idea how to = properly execute the operation.

>I'm thinking partly of controls that are executed one at a = time rather
>than setting a variable and acting on it later.
 
Any given server implementation knows which controls it implements. = It also should be aware of any ways in which two controls on a single = operation might affect the operation's outcome (including whether ordering = changes the outcome). If the combination of controls is underspecified, = and ordering will affect the outcome, the server (if following the rule in = the current draft) should not process the operation (at least that's my = read of it).
 
>However, also consider
>what to do if the same control = appears twice, but containing different
>parameters, and the control = is implemented by setting a variable for the
>operation to that = parameter. With the current text, the server is
>required to always = pick e.g. the parameter with lowest value, instead of
>just using = the parameter in the last control. Or it could detect the
>situation = and return unwillingToPerform, but then it will still need
>extra = state info in order to notice the situation.
I think the text (though not explicitly) says the server should f= ail this scenario (unless the control specification states what to = do).
 
Jim
--=__PartA1806C47.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 18:02:09 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10917 for ; Fri, 16 Apr 2004 17:16:47 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GLF4L6037962; Fri, 16 Apr 2004 21:15:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3GL9nGx037499; Fri, 16 Apr 2004 21:09:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 16 Apr 2004 21:09:49 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GL9kPn037461; Fri, 16 Apr 2004 21:09:46 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 2004 15:09:26 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 16 Apr 2004 15:08:35 -0600 From: "Jim Sermersheim" To: , Cc: Subject: Re: protocol-22 comments Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'll plan to update 4.1.10 to read: >The referral result code indicates that the contacted server cannot or will not perform the operation and that one or more other servers may be able to. Reasons for this include: > >- The target entry of the request is not held locally, but the server has knowledge of its possible existence elsewhere. >- The operation is restricted on this server -- perhaps due to a read-only copy of an entry to be modified. I'll also update 4.5.3 and 4.5.3.1 (search result references) to calrify that either referral or soSuchObject is returned depending on the servers knowledge of the target object. Finally, I'll remove the original referral instructions from Add since it was the only other operation to mention returning referrals. Jim >>> Hallvard B Furuseth 3/15/04 12:54:19 PM >>> Kurt D. Zeilenga writes: >At 03:40 AM 3/13/2004, Hallvard B Furuseth wrote: >> I just noticed an error in 4.1.10 (Referral): >> >>> The referral result code indicates that the contacted server does not >>> hold the target entry of the request. >> >> I suggest: >> >> A referral indicates that the contacted server cannot perform the >> operation, but one or more other servers can. > > Right, referrals are be returned when the server chooses to > refer the operation to another server. s/cannot/cannot or will not/ in my suggestion? Then server A can refer to B and C, and the client chooses B which refers to A and C, so the client detects a loop and gives up even though C might be willing to perform the operation. Whether we add "cannot or will not" or not, maybe the text should alert implementors to this possibility. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 18:02:49 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13032 for ; Fri, 16 Apr 2004 18:02:49 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GLu8kU040265; Fri, 16 Apr 2004 21:59:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3GLkC2x039931; Fri, 16 Apr 2004 21:46:12 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 16 Apr 2004 21:46:12 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GLkBPl039921 for ; Fri, 16 Apr 2004 21:46:11 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3GLk1Ms079076; Fri, 16 Apr 2004 21:46:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040416143728.049560b0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 16 Apr 2004 14:45:57 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: protocol-22 comments Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 02:05 PM 4/16/2004, Hallvard B Furuseth wrote: >Jim Sermersheim writes: >>>>> Hallvard B Furuseth h.b.furuseth@usit.uio.no> 3/9/04 7:20:19 AM >> >>>> 4.1.11. Controls >>>> Additionally, unless order-dependent semantics are given in a >>>> specification, the order of a combination of controls in the SEQUENCE >>>> is ignored. >>> >>> This implies that controls (A, B) MUST behave identically with controls >>> (B, A). I think it should be, "the effect of the ordering of a >>> combination of controls in the SEQUENCE is unspecified"? >> >> When the control specification doesn't describe these ordering >> semantics, interoperability problems arise where one server may >> arbitrarily assign semantics to the order of two controls, and another >> may not. Clients will come to expect behavior that is not specified. >> >> Is there a reason for allowing order semantics as unspecified which >> outweighs the interoperability problems that come with it? > >Only a vague suspicion that it may put a burden on implementations. I >wonder if the simplest way to be sure this requirement is obeyed might >be for the server to order request controls in ascending order by Octet >String Ordering Match, or something, before parsing them. Which seems >a bit excessive to me. And will fail... consider for instance the prior requirement to order options within an attribute description. >I'm thinking partly of controls that are executed one at a time rather >than setting a variable and acting on it later. I think that's a bad way to think of controls. Controls carrying extension information. All appropriate and recognized information (e.g., the control type is appropriate and recognized) is made use of in processing THE operation. >However, also consider >what to do if the same control appears twice, For most controls, that's a protocol error. Unless the control specification says the control can appear multiple times, it cannot. This should be made clear in [Protocol]. >but containing different >parameters, and the control is implemented by setting a variable for the >operation to that parameter. With the current text, the server is >required to always pick e.g. the parameter with lowest value, instead of >just using the parameter in the last control. Or it could detect the >situation and return unwillingToPerform, but then it will still need >extra state info in order to notice the situation. I am curious as what current implementations do when presented with multiple controls of the same type within a single PDU. OpenLDAP, IIRC, treats this as an error condition. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 18:34:29 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16715 for ; Fri, 16 Apr 2004 18:34:28 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GMX7qr042121; Fri, 16 Apr 2004 22:33:27 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3GMF99H041379; Fri, 16 Apr 2004 22:15:09 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 16 Apr 2004 22:15:09 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3GMF841041362 for ; Fri, 16 Apr 2004 22:15:08 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 2004 16:14:48 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 16 Apr 2004 16:13:52 -0600 From: "Jim Sermersheim" To: , Subject: Re: protocol-22 comments Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit >>>> Hallvard B Furuseth 3/9/04 7:20:19 AM >>> >> 4.2. Bind Operation > >> Authorization is the use of this authentication information when >> performing operations. > >No, authorization need not make use of the authentication information. >One could e.g. base it on IP addresses only (but only for read >operations, I would hope:-) > >Nitpick: The word "use" is wrong. Putting the currently active >authentication identity in LDAPResult.diagnosticMessage is "use" of auth >info, but not authorization. Not sure if this is worth bothering with, >though. > >> Authorization MAY be affected by factors >> outside of the LDAP Bind Request, such as those provided by lower >> layer security services. > >Here is a suggestion, though it's a bit long. Maybe the last sentence >should be dropped. > >Authorization is the decision of which access an operation has to >the directory. It may be affected by many factors, often including >the association's authorization identity, which again was derived >from or authorized via the authentication information. >Authorization may be affected by factors outside of the LDAP Bind >Request, such as those provided by lower layer security services. I like the change but it still seems too specific. How about: Authorization is the process of enforcing policy while performing operations. Among other things, the process of authorization takes as input authentication information obtained during the bind operation and/or other acts of authentication (such as lower layer security services). From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 20:06:21 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21597 for ; Fri, 16 Apr 2004 20:06:21 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H03i6L001488; Sat, 17 Apr 2004 00:05:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3H00RZu001405; Sat, 17 Apr 2004 00:00:27 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 17 Apr 2004 00:00:27 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H00Pmc001384 for ; Sat, 17 Apr 2004 00:00:25 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 2004 18:00:05 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 16 Apr 2004 17:59:03 -0600 From: "Jim Sermersheim" To: , Subject: Re: protocol-22 comments Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part8CAD4157.0__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: 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. --=__Part8CAD4157.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >>> Hallvard B Furuseth 3/9/04 7:20:19 AM >>> >> 5.2. Transfer Protocols >> >> This protocol is designed to run over connection-oriented, reliable >> transports, with all 8 bits in an octet being significant in the data >> stream. > >That all bits in an octet are significant need not be stated; that's >what anyone would assume unless the opposite was specified. One would think so but... We added this because some implementations are wrongly truncating attribute values as they come off the wire, and subsequent client complaints spurred many hours of discussion on the topic. --=__Part8CAD4157.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> = 3/9/04 7:20:19 AM >>>
>> 5.2. Transfer Protocols
>&= gt;
>> This protocol is designed to run over connection-oriented, = reliable
>> transports, with all 8 bits in an octet being = significant in the data
>> stream.
>
>That all bits = in an octet are significant need not be stated; that's
>what anyone = would assume unless the opposite was specified.
One would think so but...
 
We added this because some implementations are wrongly truncating = attribute values as they come off the wire, and subsequent client = complaints spurred many hours of discussion on the topic.
--=__Part8CAD4157.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 21:10:55 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24987 for ; Fri, 16 Apr 2004 21:10:54 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H138gW004891; Sat, 17 Apr 2004 01:09:39 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3H0xQvJ004454; Sat, 17 Apr 2004 00:59:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 17 Apr 2004 00:59:26 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H0xOqR004405; Sat, 17 Apr 2004 00:59:24 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 2004 18:59:04 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 16 Apr 2004 18:58:01 -0600 From: "Jim Sermersheim" To: , Cc: Subject: Re: "connections" (Was: protocol-22 comments) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Currently (from section 2): The terms "connection" and "LDAP connection" both refer to the underlying transport protocol connection between two protocol peers. The term "TLS connection" refers to a [TLS]-protected LDAP connection. The terms "association" and "LDAP association" both refer to the association of the LDAP connection and its current authentication and authorization state. I propose we: /s/LDAP connection/connection /s/TLS connection/TLS layer (yes I know layer is redundant) /s/association/LDAP association This, at least is how I see it. There is the physical connection (connection) and the LDAP association. Sometimes there is a TLS layer protecting the LDAP messages on the connection. Are these terms sufficient? Jim >>> "Kurt D. Zeilenga" 3/12/04 11:03:49 AM >>> I've been thinking a bit more about the different uses of "connections" in the document. It seems that "LDAP connection" is used both to refer to the underlying transport connection as well as the LDAP-level connection (e.g., the layer in which LDAP messages are exchanged), and that this is causing some confusion in the specification. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 21:52:28 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26653 for ; Fri, 16 Apr 2004 21:52:28 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H1pCqC007274; Sat, 17 Apr 2004 01:51:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3H1k5Nt007214; Sat, 17 Apr 2004 01:46:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 17 Apr 2004 01:46:05 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H1k4nb007140 for ; Sat, 17 Apr 2004 01:46:04 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 2004 19:45:44 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 16 Apr 2004 19:44:38 -0600 From: "Jim Sermersheim" To: Subject: Protocol: Compare contradiction Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The current protocol draft (in my editor) contradicts itself by stating that the result of a compare will be compareFalse when the asserted value doesn't match any attribute values or is Undefined (and refers to Section 4.5.1). Then it says if the attribute or subtype has no equality matching rule, innapropriateMatching is returned in the resultCode. Section 4.5.1 is clear that Undefined is the result of no equality match. So the question is: in the absence of an equality rule, is compare supposed to return compareFalse, or innapropriateMatching? X.501 is pretty lame on this one: "The purported argument identifies the attribute type and value to be compared with that in the entry. The comparison is TRUE if the entry holds the purported attribute type or one of its subtypes, or there is a collective attribute of the entry which is the purported attribute type or one of its subtypes (see 7.6), and if there is a value of that attribute which matches the purported value using the attribute's equality matching rule." It doesn't offer guidance when there is no equality matching rule. Later it says: "The matched result parameter, holds the result of the comparison. The parameter takes the value TRUE if the values were compared and matched, and FALSE if they did not." and again in the access control instructions: "If there exists a value within the attribute being compared that matches the purported argument and for which Compare permission is granted, the operation returns the value TRUE in the matched result parameter of the CompareResult. Otherwise, the operation returns the value FALSE." This can be read to say that if anything prevented the values to match while comparing, the answer is FALSE. But I doubt that was the intent. Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 22:34:41 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28837 for ; Fri, 16 Apr 2004 22:34:40 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H2XAs5009005; Sat, 17 Apr 2004 02:33:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3H2FfwZ008019; Sat, 17 Apr 2004 02:15:41 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 17 Apr 2004 02:15:41 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H2FeN5008009 for ; Sat, 17 Apr 2004 02:15:40 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3H2FcMs083440; Sat, 17 Apr 2004 02:15:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040416181238.04949f58@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 16 Apr 2004 19:15:34 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: "connections" (Was: protocol-22 comments) Cc: , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I prefer layer over connection for TLS, because starting and stopping TLS does not close either LDAP "connection" or transport (TCP) "connection". I also prefer to say that a TLS closure event causes the layer to be deinstalled as it reflects better that the LDAP and transport connections are still established. At 05:58 PM 4/16/2004, Jim Sermersheim wrote: >Currently (from section 2): >The terms "connection" and "LDAP connection" both refer to the >underlying transport protocol connection between two protocol peers. >The term "TLS connection" refers to a [TLS]-protected LDAP connection. >The terms "association" and "LDAP association" both refer to the >association of the LDAP connection and its current authentication and >authorization state. What I really disliked in the current document is defining TLS connection to mean a TLS-protected LDAP connection but then saying that StartTLS establish TLS on a LDAP connection. It would be okay to say StartTLS establishes TLS protection for a LDAP connection. >I propose we: >/s/LDAP connection/connection >/s/TLS connection/TLS layer (yes I know layer is redundant) >/s/association/LDAP association I suggest: "stream" to refer to the underlying transport layer. "connection" to the LDAP layer (where LDAP PDUs are exchanged) (and used without regard to whether protective-layers are or are not in place). "TLS layer" to refer to layer inserted between the stream and the connection that utilizes TLS to protect exchanged LDAP PDUs. "SASL layer" to refer to layer inserted between the stream and the connection that utilizes SASL to protect exchanged LDAP PDUs. "protective layer" to refer to either a TLS or SASL layer "protected connection" to refer to a connection protected by a protective layer "TLS-protected connection" to refer to a connection protected by a TLS-layer "SASL-protected connection" to refer to a connection protected by a SASL-layer "unprotected connection" to refer to a connection not protected by a protective layer (LDAP) association refers to the authentication and authorization state (generally of the client at the server) of a connection. I suggest also adding a picture. +------------+ | | connection | | +------------+ > LDAP PDU | +------------+ < data | | SASL layer | | +------------+ > SASL-protected data | +------------+ < data | | TLS layer | | +------------+ > TLS-protected data | Application +------------+ < data +------------ | stream | | Transport +------------+ Note that I don't include the association in this picture as that refers to a state. > The terms "association" and "LDAP association" both refer to the > association of the LDAP connection and its current authentication and > authorization state. >This, at least is how I see it. There is the physical connection >(connection) and the LDAP association. Sometimes there is a TLS layer >protecting the LDAP messages on the connection. > >Are these terms sufficient? > >Jim > >>>> "Kurt D. Zeilenga" 3/12/04 11:03:49 AM >>> >I've been thinking a bit more about the different uses of >"connections" >in the document. It seems that "LDAP connection" is used both to >refer to the underlying transport connection as well as the LDAP-level >connection (e.g., the layer in which LDAP messages are exchanged), >and that this is causing some confusion in the specification. > >Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 22:34:42 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28851 for ; Fri, 16 Apr 2004 22:34:41 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H2XAs7009005; Sat, 17 Apr 2004 02:33:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3H2V1jK008799; Sat, 17 Apr 2004 02:31:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 17 Apr 2004 02:31:01 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H2UsY6008743; Sat, 17 Apr 2004 02:30:58 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 2004 20:30:34 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 16 Apr 2004 20:29:23 -0600 From: "Jim Sermersheim" To: Cc: , Subject: Re: "connections" (Was: protocol-22 comments) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartAD8C6093.0__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: 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. --=__PartAD8C6093.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I like these terms thought I don't think I need them all. I'll try a pass at replacing current terminology and report back with what happens. >>> "Kurt D. Zeilenga" 4/16/04 8:15:34 PM >>> I prefer layer over connection for TLS, because starting and stopping TLS does not close either LDAP "connection" or transport (TCP) "connection". I also prefer to say that a TLS closure event causes the layer to be deinstalled as it reflects better that the LDAP and transport connections are still established. At 05:58 PM 4/16/2004, Jim Sermersheim wrote: >Currently (from section 2): >The terms "connection" and "LDAP connection" both refer to the >underlying transport protocol connection between two protocol peers. >The term "TLS connection" refers to a [TLS]-protected LDAP connection. >The terms "association" and "LDAP association" both refer to the >association of the LDAP connection and its current authentication and >authorization state. What I really disliked in the current document is defining TLS connection to mean a TLS-protected LDAP connection but then saying that StartTLS establish TLS on a LDAP connection. It would be okay to say StartTLS establishes TLS protection for a LDAP connection. >I propose we: >/s/LDAP connection/connection >/s/TLS connection/TLS layer (yes I know layer is redundant) >/s/association/LDAP association I suggest: "stream" to refer to the underlying transport layer. "connection" to the LDAP layer (where LDAP PDUs are exchanged) (and used without regard to whether protective-layers are or are not in place). "TLS layer" to refer to layer inserted between the stream and the connection that utilizes TLS to protect exchanged LDAP PDUs. "SASL layer" to refer to layer inserted between the stream and the connection that utilizes SASL to protect exchanged LDAP PDUs. "protective layer" to refer to either a TLS or SASL layer "protected connection" to refer to a connection protected by a protective layer "TLS-protected connection" to refer to a connection protected by a TLS-layer "SASL-protected connection" to refer to a connection protected by a SASL-layer "unprotected connection" to refer to a connection not protected by a protective layer (LDAP) association refers to the authentication and authorization state (generally of the client at the server) of a connection. I suggest also adding a picture. +------------+ | | connection | | +------------+ > LDAP PDU | +------------+ < data | | SASL layer | | +------------+ > SASL-protected data | +------------+ < data | | TLS layer | | +------------+ > TLS-protected data | Application +------------+ < data +------------ | stream | | Transport +------------+ Note that I don't include the association in this picture as that refers to a state. > The terms "association" and "LDAP association" both refer to the > association of the LDAP connection and its current authentication and > authorization state. >This, at least is how I see it. There is the physical connection >(connection) and the LDAP association. Sometimes there is a TLS layer >protecting the LDAP messages on the connection. > >Are these terms sufficient? > >Jim > >>>> "Kurt D. Zeilenga" < Kurt@OpenLDAP.org > 3/12/04 11:03:49 AM >>> >I've been thinking a bit more about the different uses of >"connections" >in the document. It seems that "LDAP connection" is used both to >refer to the underlying transport connection as well as the LDAP-level >connection (e.g., the layer in which LDAP messages are exchanged), >and that this is causing some confusion in the specification. > >Kurt --=__PartAD8C6093.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I = like these terms thought I don't think I need them all. I'll try a pass at = replacing current terminology and report back with what happens.

>= ;>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 4/16/04 8:15:34 PM = >>>
I prefer layer over connection for TLS, because startingand stopping TLS does not close either LDAP "connection"
or transport = (TCP) "connection". I also prefer to say
that a TLS closure event = causes the layer to be deinstalled
as it reflects better that the LDAP = and transport connections
are still established.


At 05:58 PM = 4/16/2004, Jim Sermersheim wrote:
>Currently (from section 2):
>= ;The terms "connection" and "LDAP connection" both refer to the
>unde= rlying transport protocol connection between two protocol peers.
>The= term "TLS connection" refers to a [TLS]-protected LDAP connection.
>= The terms "association" and "LDAP association" both refer to the
>ass= ociation of the LDAP connection and its current authentication and
>a= uthorization state.

What I really disliked in the current document = is
defining TLS connection to mean a TLS-protected LDAP
connection = but then saying that StartTLS establish
TLS on a LDAP connection. It = would be okay to say
StartTLS establishes TLS protection for a LDAP = connection.

>I propose we:
>/s/LDAP connection/connection>/s/TLS connection/TLS layer (yes I know layer is redundant)
>/s= /association/LDAP association

I suggest:
"stream" to refer to = the underlying transport layer.
"connection" to the LDAP layer (where = LDAP PDUs are exchanged)
(and used without regard to whether protective-= layers are
or are not in place).
"TLS layer" to refer to layer = inserted between the stream
and the connection that utilizes TLS to = protect
exchanged LDAP PDUs.
"SASL layer" to refer to layer inserted = between the stream
and the connection that utilizes SASL to protect
e= xchanged LDAP PDUs.
"protective layer" to refer to either a TLS or SASL = layer
"protected connection" to refer to a connection protected
by a = protective layer
"TLS-protected connection" to refer to a connection = protected
by a TLS-layer
"SASL-protected connection" to refer to a = connection protected
by a SASL-layer
"unprotected connection" to = refer to a connection not
protected by a protective layer

(LDAP) = association refers to the authentication and authorization
state = (generally of the client at the server) of a connection.

I suggest = also adding a picture.

+------------+ |
| connection | |
+----= --------+ > LDAP PDU |
+------------+ < data |
| SASL layer | = |
+------------+ > SASL-protected data |
+------------+ < = data |
| TLS layer | |
+------------+ > TLS-protected data | = Application
+------------+ < data +------------
| stream | | = Transport
+------------+

Note that I don't include the = association in this picture as
that refers to a state.

> The = terms "association" and "LDAP association" both refer to the
> = association of the LDAP connection and its current authentication = and
> authorization state.


>This, at least is how I = see it. There is the physical connection
>(connection) and the LDAP = association. Sometimes there is a TLS layer
>protecting the LDAP = messages on the connection.
>
>Are these terms sufficient?
&= gt;
>Jim
>
>>>> "Kurt D. Zeilenga" < Kurt@OpenLDAP.org > 3/12/04 = 11:03:49 AM >>>
>I've been thinking a bit more about the = different uses of
>"connections"
>in the document. It seems = that "LDAP connection" is used both to
>refer to the underlying = transport connection as well as the LDAP-level
>connection (e.g., = the layer in which LDAP messages are exchanged),
>and that this is = causing some confusion in the specification.
>
>Kurt

 --=__PartAD8C6093.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 23:11:34 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00330 for ; Fri, 16 Apr 2004 23:11:34 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H39Ux7010952; Sat, 17 Apr 2004 03:09:37 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3H37OoH010867; Sat, 17 Apr 2004 03:07:24 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 17 Apr 2004 03:07:24 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H37Of2010856 for ; Sat, 17 Apr 2004 03:07:24 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 2004 21:07:03 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 16 Apr 2004 21:05:59 -0600 From: "Jim Sermersheim" To: Subject: Protocol: Restricting operations while binding Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id i3H37Of2010858 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit It was recently mentioned that we should discuss whether a client is allowed to send requests while a bind response is outstanding. The problem that has arisen in the past has been with clients that send operations asynchronously along with a bind. For example: C S *---------------------- bind----------> workerThread(bind) search--------> workerThread(search) <--------------search resp <--------------bind resp This is due to the server spawning worker threads for each operation. Sometimes an operation is performed before operations sent prior. If the client is told to block until the bind response is returned before sending subsequent responses, it can be assured that those operations will be performed using the correct authN. I believe this goes beyond bind, to any operation that can change the authN or authZ of an association. I don't think we can get away with a mandate. But I think a recommendation would be good. Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 16 23:49:39 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02191 for ; Fri, 16 Apr 2004 23:49:39 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H3jKuc012753; Sat, 17 Apr 2004 03:48:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3H3dciw012586; Sat, 17 Apr 2004 03:39:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 17 Apr 2004 03:39:38 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H3darj012545; Sat, 17 Apr 2004 03:39:36 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 2004 21:39:16 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 16 Apr 2004 21:38:02 -0600 From: "Jim Sermersheim" To: , Cc: Subject: control combination was: Re: protocol-22 comments) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit >>> "Kurt D. Zeilenga" 4/16/04 3:45:57 PM >>> >>However, also consider >>what to do if the same control appears twice, > >For most controls, that's a protocol error. Unless the control >specification says the control can appear multiple times, it cannot. >This should be made clear in [Protocol]. Actually, this is clear (see combination of controls in 4.1.11), but the current language says behavior is undefined. >>but containing different >>parameters, and the control is implemented by setting a variable for the >>operation to that parameter. With the current text, the server is >>required to always pick e.g. the parameter with lowest value, instead of >>just using the parameter in the last control. Or it could detect the >>situation and return unwillingToPerform, but then it will still need >>extra state info in order to notice the situation. > >I am curious as what current implementations do when presented >with multiple controls of the same type within a single PDU. >OpenLDAP, IIRC, treats this as an error condition. I think treating as an error is the best policy. This is really no different than combining two different controls. If the spec doesn't say what should happen, then behavior is undefined. We currently recommend that clients not do this. I propose recommending that servers return an error, but allowing them to handle these cases in an undefined way. If we do recommend it, we need to recommend an error code. I prefer protocolError, but it's documented as having a very specific meaning followed by a growing list of exceptions (this would add to that). A second choice is unwillingToPerform. Jim From owner-ietf-ldapbis@OpenLDAP.org Sat Apr 17 02:29:11 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22890 for ; Sat, 17 Apr 2004 02:29:10 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H6RCuM020189; Sat, 17 Apr 2004 06:27:58 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3H6QWun020176; Sat, 17 Apr 2004 06:26:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 17 Apr 2004 06:26:32 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H6QVH5020166 for ; Sat, 17 Apr 2004 06:26:31 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3H6QTMs087947; Sat, 17 Apr 2004 06:26:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040416222705.0497bff0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 16 Apr 2004 23:26:24 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Protocol: Restricting operations while binding Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: There are a number of reasons why clients should be prohibited from sending requests while a bind operation is outstanding. The client cannot assume the requested protocol version is supported. The client cannot assume it will be requested to use a different method and/or to establish confidential protections. The client cannot assume it will not be referred to another server. The client cannot assume its credentials (or request for anonymous will be accepted. The client cannot assume its bind request will otherwise be rejected. A client which makes such assumptions, I think, fundamentally flawed. And, if its SASL bind that could result in security layers being installed (or new layers installed), then you have the problem where the request was sent under different protective services than its responses. I think we really do need to prohibit sending requests when a bind operation is outstanding. The question I am struggling with is how should the server behave if gets a request while processing a bind operation (such as injected by an attacker). While it might be nice to respond with operationsError, if new layers have been established prior to this response, the server shouldn't respond to the request. So, I think we either need to just say "don't process, don't respond" or "respond if you can do so before new layers, otherwise don't respond". I think I favor the former. At 08:05 PM 4/16/2004, Jim Sermersheim wrote: >It was recently mentioned that we should discuss whether a client is allowed to send requests while a bind response is outstanding. > >The problem that has arisen in the past has been with clients that send operations asynchronously along with a bind. For example: > >C S >*---------------------- >bind----------> > workerThread(bind) >search--------> > workerThread(search) ><--------------search resp ><--------------bind resp > >This is due to the server spawning worker threads for each operation. Sometimes an operation is performed before operations sent prior. > >If the client is told to block until the bind response is returned before sending subsequent responses, it can be assured that those operations will be performed using the correct authN. > >I believe this goes beyond bind, to any operation that can change the authN or authZ of an association. > >I don't think we can get away with a mandate. I don't think we can get way without a mandate. >But I think a recommendation would be good. I can only see using a SHOULD if there was a reasonable use case, with existing implementations of that use case, for allowing it. Kurt From owner-ietf-ldapbis@OpenLDAP.org Sat Apr 17 03:35:03 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25447 for ; Sat, 17 Apr 2004 03:35:02 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H7LOjw022298; Sat, 17 Apr 2004 07:33:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3H7Emn8021973; Sat, 17 Apr 2004 07:14:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 17 Apr 2004 07:14:48 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3H7EllP021963 for ; Sat, 17 Apr 2004 07:14:47 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3H7EjMs088460; Sat, 17 Apr 2004 07:14:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040416233611.04985bc8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 17 Apr 2004 00:14:41 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: control combination was: Re: protocol-22 comments) Cc: , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 08:38 PM 4/16/2004, Jim Sermersheim wrote: >Actually, this is clear (see combination of controls in 4.1.11), but >the current language says behavior is undefined. I think the semantics are undefined, but we should define how servers are to behave when faced with a combination of recognized and appropriate controls whose semantics haven't been defined. Maybe protocolError is the best approach here. However, how about a client which specifies two controls of similar function hoping the server supports one or the other (and, if both, selects the "better" one). Though I'm not necessarily convinced myself that this is appropriate, how about something like: Clients SHOULD NOT be combined controls (with other controls of same or different types) unless the semantics of the combination have been defined (and known to it). A server MUST NOT attempt to make use of a combination of controls whose semantics are not defined (or not known to it). The server MAY ignore any non-critical control in the presented combination to reduce the combination to a sequence (including the empty sequence) which does have defined semantics. However, the server MUST NOT ignore any critical control in the presented combination. If the combination cannot be reduced to a sequence which has a defined semantics, the server MUST return unavailableCriticalExtension. The semantics of control combinations, when defined, are generally found in the control specification most recently published. Comments? >>>but containing different >>>parameters, and the control is implemented by setting a variable for >the >>>operation to that parameter. With the current text, the server is >>>required to always pick e.g. the parameter with lowest value, instead >of >>>just using the parameter in the last control. Or it could detect the >>>situation and return unwillingToPerform, but then it will still need >>>extra state info in order to notice the situation. >> >>I am curious as what current implementations do when presented >>with multiple controls of the same type within a single PDU. >>OpenLDAP, IIRC, treats this as an error condition. > >I think treating as an error is the best policy. This is really no >different than combining two different controls. If the spec doesn't say >what should happen, then behavior is undefined. > >We currently recommend that clients not do this. I propose recommending >that servers return an error, but allowing them to handle these cases in >an undefined way. > >If we do recommend it, we need to recommend an error code. I prefer >protocolError, but it's documented as having a very specific meaning >followed by a growing list of exceptions (this would add to that). A >second choice is unwillingToPerform. > >Jim From owner-ietf-ldapbis@OpenLDAP.org Sat Apr 17 14:25:59 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21525 for ; Sat, 17 Apr 2004 14:25:59 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3HILOG7054757; Sat, 17 Apr 2004 18:24:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3HII3or054667; Sat, 17 Apr 2004 18:18:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 17 Apr 2004 18:18:03 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3HII1TZ054633 for ; Sat, 17 Apr 2004 18:18:02 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BEuO5-0005eA-Un; Sat, 17 Apr 2004 20:17:57 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BEuO4-0000fm-IQ; Sat, 17 Apr 2004 20:17:56 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BEuNz-0007Wf-00; Sat, 17 Apr 2004 20:17:51 +0200 From: Hallvard B Furuseth Message-Id: To: Jim Sermersheim Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Protocol: Compare contradiction In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sat, 17 Apr 2004 20:17:51 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Jim Sermersheim writes: > The current protocol draft (in my editor) contradicts itself by stating > that the result of a compare will be compareFalse when the asserted > value doesn't match any attribute values or is Undefined (and refers to > Section 4.5.1). > > Then it says if the attribute or subtype has no equality matching rule, > innapropriateMatching is returned in the resultCode. > > Section 4.5.1 is clear that Undefined is the result of no equality > match. > > So the question is: in the absence of an equality rule, is compare > supposed to return compareFalse, or innapropriateMatching? The Search operation (4.5.1) has a good reason to not return an error in this case: It supports complex filters and can return several entries. It's useful that a problem in one filter component, or in one entry, does not prevent the operation from returning the entries that do match the rest of the filter. If the attribute has no equality matching rule, that might be because the server does not support the equality rule which the attribute needs, but the server admin still wanted to support the attribute. E.g. labeledURI on a server without caseExactMatch. I don't see any similar reasons that hold for the Compare operation. So I think inappropriateMatching is the best result code to return. OTOH, I have no idea if that breaks some clients, or is incompatible with X.500. Maybe you should ask an X.500 forum what X.500 servers do. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sat Apr 17 14:52:04 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22331 for ; Sat, 17 Apr 2004 14:52:04 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3HIpHnw055762; Sat, 17 Apr 2004 18:51:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3HImKtS055588; Sat, 17 Apr 2004 18:48:20 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 17 Apr 2004 18:48:20 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3HImIgj055557; Sat, 17 Apr 2004 18:48:18 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1BEurO-0003I5-Vx; Sat, 17 Apr 2004 20:48:14 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.30) id 1BEurM-0004I7-OE; Sat, 17 Apr 2004 20:48:12 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BEurL-0007bT-00; Sat, 17 Apr 2004 20:48:11 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: Re: "connections" (Was: protocol-22 comments) In-Reply-To: <6.0.1.1.0.20040416181238.04949f58@127.0.0.1> References: <6.0.1.1.0.20040416181238.04949f58@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sat, 17 Apr 2004 20:48:11 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt D. Zeilenga writes: >> I propose we: >> /s/LDAP connection/connection >> /s/TLS connection/TLS layer (yes I know layer is redundant) >> /s/association/LDAP association > > I suggest: > "stream" to refer to the underlying transport layer. > "connection" to the LDAP layer (where LDAP PDUs are exchanged) > (and used without regard to whether protective-layers are > or are not in place). I thought "connection" usually meant something close to what you call "stream". E.g. to "close the connection" means that the communication is torn down completely. How about "connection" for your "stream", and "LDAP " for your "connection"? > "protective layer" to refer to either a TLS or SASL layer Or e.g. IPsec, I hope. Since you say: > "unprotected connection" to refer to a connection not > protected by a protective layer -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sat Apr 17 17:23:42 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27735 for ; Sat, 17 Apr 2004 17:23:41 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3HLLPww060815; Sat, 17 Apr 2004 21:21:35 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3HLHGJM060284; Sat, 17 Apr 2004 21:17:16 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 17 Apr 2004 21:17:16 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3HLHFlB060274 for ; Sat, 17 Apr 2004 21:17:15 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3HLHDMs000867; Sat, 17 Apr 2004 21:17:13 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040417140349.049c0d10@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 17 Apr 2004 14:17:07 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: "connections" (Was: protocol-22 comments) Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.1.1.0.20040416181238.04949f58@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 11:48 AM 4/17/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>> I propose we: >>> /s/LDAP connection/connection >>> /s/TLS connection/TLS layer (yes I know layer is redundant) >>> /s/association/LDAP association >> >> I suggest: >> "stream" to refer to the underlying transport layer. >> "connection" to the LDAP layer (where LDAP PDUs are exchanged) >> (and used without regard to whether protective-layers are >> or are not in place). > >I thought "connection" usually meant something close to what you call >"stream". E.g. to "close the connection" means that the communication >is torn down completely. >How about "connection" for your "stream", and "LDAP " >for your "connection"? I did consider that, but will "connection" could easily refer to either level of communication, the term "stream" seemed not to apply well at the LDAP level. >> "protective layer" to refer to either a TLS or SASL layer > >Or e.g. IPsec, I hope. No. While IPsec offers data security services, those servers are below the transport (and hence not factored into these terms). Here I am using "protective layer" to refer to those kinds of data security services which can be inserted, as a layer, between the LDAP exchange of messages and the underlying transport protocol. >Since you say: >> "unprotected connection" to refer to a connection not >> protected by a protective layer I define the term "unprotected connection" without consideration to whether the underlying transport is protected. That is, I exclude (in the terms, not in practice) protections that might be offered at any layer in or below the underlying transport protocol. Such, while could be useful, is not integral part of LDAP. Kurt From owner-ietf-ldapbis@OpenLDAP.org Sat Apr 17 17:52:38 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAB28424 for ; Sat, 17 Apr 2004 17:52:38 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3HLpIOi062158; Sat, 17 Apr 2004 21:51:23 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3HLojLw062148; Sat, 17 Apr 2004 21:50:45 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 17 Apr 2004 21:50:45 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3HLog8D062119; Sat, 17 Apr 2004 21:50:42 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1BExhu-0003EQ-T9; Sat, 17 Apr 2004 23:50:38 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.30) id 1BExht-0007WS-EZ; Sat, 17 Apr 2004 23:50:37 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BExhq-0000Ci-00; Sat, 17 Apr 2004 23:50:34 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: Re: "connections" (Was: protocol-22 comments) In-Reply-To: <6.0.1.1.0.20040417140349.049c0d10@127.0.0.1> References: <6.0.1.1.0.20040416181238.04949f58@127.0.0.1> <6.0.1.1.0.20040417140349.049c0d10@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sat, 17 Apr 2004 23:50:34 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt D. Zeilenga writes: >At 11:48 AM 4/17/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>> I suggest: >>> "stream" to refer to the underlying transport layer. >>> "connection" to the LDAP layer (where LDAP PDUs are exchanged) >>> (and used without regard to whether protective-layers are >>> or are not in place). >> >>I thought "connection" usually meant something close to what you call >>"stream". E.g. to "close the connection" means that the communication >>is torn down completely. > >>How about "connection" for your "stream", and "LDAP " >>for your "connection"? > > I did consider that, but will "connection" could easily > refer to either level of communication, the term "stream" > seemed not to apply well at the LDAP level. Heh. If you swapped "connection" and "stream" in that statement, I would agree completely:-) About the stream, maybe you think physical stream and I data stream. I must admit that I'm no expert at networking and networking terms, though. Anyway, "LDAP layer" seems to work anyway - fits nicely with the TLS and SASL layers. Also, we still need a term for "dropping/closing" the connection, and I think that should refer to your "stream" layer. >>> "protective layer" to refer to either a TLS or SASL layer >> >> Or e.g. IPsec, I hope. > > No. While IPsec offers data security services, those servers > are below the transport (and hence not factored into these > terms). Here I am using "protective layer" to refer to those > kinds of data security services which can be inserted, as a > layer, between the LDAP exchange of messages and the underlying > transport protocol. OK, but then that should be clarified explicitly in the definition. Though I kind of hope we won't need the term. Perhaps "protective LDAP layer" is better, as a reminder that the layer is part of the LDAP specification. (BTW, I'm not sure if it would be right to say SASL and TLS are part of the LDAP protocol or not?) How about layers invoked by LDAP extensions, similar to StartTLS? >>Since you say: >>> "unprotected connection" to refer to a connection not >>> protected by a protective layer > > I define the term "unprotected connection" without consideration > to whether the underlying transport is protected. That is, > I exclude (in the terms, not in practice) protections that > might be offered at any layer in or below the underlying > transport protocol. Such, while could be useful, is not > integral part of LDAP. Then it's misleading to call it "unprotected". Unless someone comes up with a better term, maybe it's best to spell out " with no protective (LDAP) layer". -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 18 02:36:23 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04210 for ; Sun, 18 Apr 2004 02:36:22 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3I6XnI4074514; Sun, 18 Apr 2004 06:34:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3I6W4dd074468; Sun, 18 Apr 2004 06:32:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 18 Apr 2004 06:32:04 +0000 Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3I6W2o5074458 for ; Sun, 18 Apr 2004 06:32:02 GMT (envelope-from marty.schleiff@boeing.com) Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id XAA11383; Sat, 17 Apr 2004 23:31:40 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i3I6VeV10366; Sat, 17 Apr 2004 23:31:40 -0700 (PDT) Received: from XCH-NW-08.nw.nos.boeing.com ([192.42.226.83]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Sat, 17 Apr 2004 23:31:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Active Directory question Date: Sat, 17 Apr 2004 23:31:39 -0700 Message-ID: Thread-Topic: Active Directory question Thread-Index: AcQlDsyNo/JjL8WvQWm4DILTzmm/Jg== From: "Schleiff, Marty" To: , Cc: "Phil Hunt" X-OriginalArrivalTime: 18 Apr 2004 06:31:39.0884 (UTC) FILETIME=[CE94BAC0:01C4250E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id i3I6W2o5074459 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Gentlemen, When using ldapsearch to lookup the membership in an Active Directory group, I got the following (abbreviated) response: CN=PC Backup Group 1,OU=Groups,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com member;range=0-999=CN=Peterson\, Randy R,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com member;range=0-999=CN=Tatham\, William C,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com member;range=0-999=CN=Pham\, Steve,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com I'd never before encountered "range=0-999" and wondered what it meant. A little searching turned up the following URLs: http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt and http://www.hut.fi/cc/docs/kerberos/nss_ldap.html From the second URL: "Active directory uses a method called "Incremental Retrieval of Multivalued Properties" which nss_ldap has no support for, at least not yet. Querying groups having more than 1000 members will return the first 1000 members, with the 'member' attribute changed to 'member;range=0-999'. This is not recognized by nss_ldap, so you will not see any members for that group. More information can be found in the (now expired) Internet Draft labeled Incremental Retrieval of Multivalued Attributes ." I was also referred to http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt ; however, I'm not sure that applies to my situation (it seems to describe how a client could request the server to return a partial set of values for a multi-valued attribute -- in my case I didn't request the range, Active Directory just gave it to me when I really wanted the complete set of values). I'd value the opinions of this list around the following questions: 1) What do you think of this practice? Being a stranger on this list, I've withheld my editorial opinion of this practice; however, I'd like to hear your opinions. 2) Even if I can get my ldap client apps to learn to deal with the ";range=0-999", I don't know how to teach them to obtain subsequent ranges. Also, as pointed out in section "5.3 Element Ordering", another client operating on the same entry as my client can add or remove values between my clients operations to retrieve multiple ranges so that my client's "requests may result in overlapping, duplicated, or skipped elements". 3) Does The Open Group assessment of "LDAP Ready" require a client to understand ranges? 4) Does The Open Group assessment of "LDAP Certified" require a server to return ranges? Or if a server does return ranges (which probably would confuse many clients), can that server be "LDAP Certified". 5) Will common tools like ldapsearch, PerLDAP, LDAP URLs on a browser location box, etc. ever be able to request ranges of multi-values attributes (or do they already have this capability and I'm just unaware)? Thx, Marty.Schleiff@boeing.com; CISSP Associate Technical Fellow - Cyber Identity Specialist IT Access & Security Services (425) 957-5667 From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 18 08:29:30 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17682 for ; Sun, 18 Apr 2004 08:29:29 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3ICRcK5084362; Sun, 18 Apr 2004 12:27:56 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3ICPJ5C084320; Sun, 18 Apr 2004 12:25:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 18 Apr 2004 12:25:19 +0000 Received: from nb2.stroeder.com (du-041-120.access.de.clara.net [213.221.64.120]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3ICPF9Q084290; Sun, 18 Apr 2004 12:25:16 GMT (envelope-from michael@stroeder.com) Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 62FA27F188; Sun, 18 Apr 2004 13:17:46 +0200 (CEST) Message-ID: <408263DA.7000005@stroeder.com> Date: Sun, 18 Apr 2004 13:17:46 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: Re: Protocol: Restricting operations while binding References: <6.0.1.1.0.20040416222705.0497bff0@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040416222705.0497bff0@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > > I think we really do need to prohibit sending requests > when a bind operation is outstanding. +1 > So, I think we either need to > just say "don't process, don't respond" or "respond if > you can do so before new layers, otherwise don't respond". > I think I favor the former. +1 for "don't process, don't respond" Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 18 11:29:05 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26539 for ; Sun, 18 Apr 2004 11:29:05 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3IFS4vu091158; Sun, 18 Apr 2004 15:28:04 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3IFKXsL090821; Sun, 18 Apr 2004 15:20:33 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 18 Apr 2004 15:20:33 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3IFKWbS090811 for ; Sun, 18 Apr 2004 15:20:32 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3IFJeMs015980; Sun, 18 Apr 2004 15:19:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040418072835.049ef898@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 18 Apr 2004 08:19:34 -0700 To: "Schleiff, Marty" From: "Kurt D. Zeilenga" Subject: Re: Active Directory question Cc: , , "Phil Hunt" , ldapext@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 11:31 PM 4/17/2004, Schleiff, Marty wrote: >I'd value the opinions of this list around the following questions: >1) What do you think of this practice? Being a stranger on this list, I've withheld my editorial opinion of this practice; however, I'd like to hear your opinions. It is inappropriate for a server to respond in a manner which requires a client to handle and recognize unsolicited extension information. To the client, the searchResultEntry PDU provided by the server is malformed (see RFC 2251, Section 3.1). Likely, most clients (which do not support this extension) will simply treat the response as indicating the 'member' attribute has no (visible) values and simply treat the values as belonging to an unrecognized attribute type (or, possibly, an unrecognized subtype of the member attribute type). Anyways, as I previously noted, extensions to LDAP are suppose to be truly optional. This extension is actually truly non-optional (which is worse than being "not truly optional"). LDAPBIS should, in revising the LDAP technical specification, make this more clear. >2) Even if I can get my ldap client apps to learn to deal with the ";range=0-999", I don't know how to teach them to obtain subsequent ranges. Also, as pointed out in section "5.3 Element Ordering", another client operating on the same entry as my client can add or remove values between my clients operations to retrieve multiple ranges so that my client's "requests may result in overlapping, duplicated, or skipped elements". I have no idea of how the extension authors expect to consistency to be maintained. And I have no idea how the extension authors expect clients to address obvious security considerations caused by such inconsistencies. >3) Does The Open Group... >4) Does The Open Group... These are questions for the Open Group to answer. >5) Will common tools ... ? That's a question for individual developers to answer. From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 18 13:04:44 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00676 for ; Sun, 18 Apr 2004 13:04:44 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3IH3dxh096383; Sun, 18 Apr 2004 17:03:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3IGwuJs096268; Sun, 18 Apr 2004 16:58:56 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 18 Apr 2004 16:58:56 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3IGwt9U096257 for ; Sun, 18 Apr 2004 16:58:55 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3IGwrMs017800; Sun, 18 Apr 2004 16:58:54 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040418093715.049da2b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 18 Apr 2004 09:58:21 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: "connections" (Was: protocol-22 comments) Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.1.1.0.20040416181238.04949f58@127.0.0.1> <6.0.1.1.0.20040417140349.049c0d10@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 02:50 PM 4/17/2004, Hallvard B Furuseth wrote: >(BTW, I'm not sure if it would be >right to say SASL and TLS are part of the LDAP protocol or not?) LDAP TS not only defines exchange of LDAP messages, but how those messages are mapped onto the transport layer protocol, and this may include processing of those messages through SASL and/or TLS layers. These layers may be independently specified, but they are an integral part of LDAP's mapping onto the transport protocol. I note that used "stream" in this manner: From The Free On-line Dictionary of Computing (27 SEP 03) [foldoc]: stream 1. An {abstraction} referring to any flow of data from a source (or sender, producer) to a single sink (or receiver, consumer). A stream usually flows through a channel of some kind, as opposed to {packet}s which may be addressed and routed independently, possibly to multiple recipients. Streams usually require some mechanism for establishing a channel or a "{connection}" between the sender and receiver. While I agree that "stream" could apply at the LDAP message level as well, I think it better fits the transport protocol. TCP is often called a "stream-oriented protocol". (Note that "channel" might be used in some fashion here, but it might be better to steer clear of it.) I dislike the over use of layer and hence only used it when referring to optional layers in the abbreviated stack. Kurt From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 18 13:38:18 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02451 for ; Sun, 18 Apr 2004 13:38:17 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3IHXOEU097981; Sun, 18 Apr 2004 17:37:13 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3IHW3VL097819; Sun, 18 Apr 2004 17:32:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 18 Apr 2004 17:32:03 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3IHW2pC097809 for ; Sun, 18 Apr 2004 17:32:02 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3IHW2Ms018341 for ; Sun, 18 Apr 2004 17:32:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040418101616.049d5350@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 18 Apr 2004 10:31:55 -0700 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Re: "connections" (Was: protocol-22 comments) In-Reply-To: <6.0.1.1.0.20040418093715.049da2b8@127.0.0.1> References: <6.0.1.1.0.20040416181238.04949f58@127.0.0.1> <6.0.1.1.0.20040417140349.049c0d10@127.0.0.1> <6.0.1.1.0.20040418093715.049da2b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 09:58 AM 4/18/2004, Kurt D. Zeilenga wrote: > stream > 1. An {abstraction} referring to any flow of > data from a source (or sender, producer) to a single sink (or > receiver, consumer). A stream usually flows through a channel > of some kind, as opposed to {packet}s which may be addressed > and routed independently, possibly to multiple recipients. > Streams usually require some mechanism for establishing a > channel or a "{connection}" between the sender and receiver. Another comment: one reason not to use "stream" to refer to the exchange of LDAP messages is that LDAP messages are addressed independently (by message id) and routed independently to the directory operation executed at an higher level. That is, messages from multiple operations (each a source) are multiplexed in the exchange. I note that my primary interest is not which particular terms are used where. I am primarily interested in ensuring that our terms are well-defined and used in an unambiguous manner. I wouldn't object to using "LDAP connection" and "transport connection" as long as we never use the term "connection" without qualification. Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Apr 19 02:49:34 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20792 for ; Mon, 19 Apr 2004 02:49:33 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3J6jSQI036333; Mon, 19 Apr 2004 06:48:39 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3J6cWbS035791; Mon, 19 Apr 2004 06:38:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 19 Apr 2004 06:38:32 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3J6cTqm035742; Mon, 19 Apr 2004 06:38:30 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 19 Apr 2004 00:38:09 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 19 Apr 2004 00:37:34 -0600 From: "Jim Sermersheim" To: , Subject: Re: "connections" (Was: protocol-22 comments) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree. Once the usage is properly broken up in the document, it'll be easy to swap terms like 'stream' for 'transport' or whatever seems most agreeable. Jim >>> "Kurt D. Zeilenga" 4/18/04 11:31:55 AM >>> At 09:58 AM 4/18/2004, Kurt D. Zeilenga wrote: > stream > 1. An {abstraction} referring to any flow of > data from a source (or sender, producer) to a single sink (or > receiver, consumer). A stream usually flows through a channel > of some kind, as opposed to {packet}s which may be addressed > and routed independently, possibly to multiple recipients. > Streams usually require some mechanism for establishing a > channel or a "{connection}" between the sender and receiver. Another comment: one reason not to use "stream" to refer to the exchange of LDAP messages is that LDAP messages are addressed independently (by message id) and routed independently to the directory operation executed at an higher level. That is, messages from multiple operations (each a source) are multiplexed in the exchange. I note that my primary interest is not which particular terms are used where. I am primarily interested in ensuring that our terms are well-defined and used in an unambiguous manner. I wouldn't object to using "LDAP connection" and "transport connection" as long as we never use the term "connection" without qualification. Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Apr 19 03:37:23 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20793 for ; Mon, 19 Apr 2004 02:49:33 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3J6jSQK036333; Mon, 19 Apr 2004 06:48:39 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3J6hgVL036240; Mon, 19 Apr 2004 06:43:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 19 Apr 2004 06:43:42 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3J6he4f036118; Mon, 19 Apr 2004 06:43:40 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 19 Apr 2004 00:43:20 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 19 Apr 2004 00:42:40 -0600 From: "Jim Sermersheim" To: , Subject: Re: "connections" (Was: protocol-22 comments) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Also from RFC 793: Basic Data Transfer: The TCP is able to transfer a continuous stream of octets in each direction between its users by packaging some number of octets into segments for transmission through the internet system. >>> "Kurt D. Zeilenga" 4/18/04 11:31:55 AM >>> At 09:58 AM 4/18/2004, Kurt D. Zeilenga wrote: > stream > 1. An {abstraction} referring to any flow of > data from a source (or sender, producer) to a single sink (or > receiver, consumer). A stream usually flows through a channel > of some kind, as opposed to {packet}s which may be addressed > and routed independently, possibly to multiple recipients. > Streams usually require some mechanism for establishing a > channel or a "{connection}" between the sender and receiver. Another comment: one reason not to use "stream" to refer to the exchange of LDAP messages is that LDAP messages are addressed independently (by message id) and routed independently to the directory operation executed at an higher level. That is, messages from multiple operations (each a source) are multiplexed in the exchange. I note that my primary interest is not which particular terms are used where. I am primarily interested in ensuring that our terms are well-defined and used in an unambiguous manner. I wouldn't object to using "LDAP connection" and "transport connection" as long as we never use the term "connection" without qualification. Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Apr 19 03:37:24 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20794 for ; Mon, 19 Apr 2004 02:49:33 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3J6jSQM036333; Mon, 19 Apr 2004 06:48:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3J6gMpg036036; Mon, 19 Apr 2004 06:42:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 19 Apr 2004 06:42:22 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3J6gJDP035973; Mon, 19 Apr 2004 06:42:19 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 19 Apr 2004 00:41:59 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 19 Apr 2004 00:41:20 -0600 From: "Jim Sermersheim" To: , Subject: Re: "connections" (Was: protocol-22 comments) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit From RFC 793: Connections: The reliability and flow control mechanisms described above require that TCPs initialize and maintain certain status information for each data stream. The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection. Each connection is uniquely specified by a pair of sockets identifying its two sides. When two processes wish to communicate, their TCP's must first establish a connection (initialize the status information on each side). When their communication is complete, the connection is terminated or closed to free the resources for other uses. Since connections must be established between unreliable hosts and over the unreliable internet communication system, a handshake mechanism with clock-based sequence numbers is used to avoid erroneous initialization of connections. >>> "Kurt D. Zeilenga" 4/18/04 11:31:55 AM >>> At 09:58 AM 4/18/2004, Kurt D. Zeilenga wrote: > stream > 1. An {abstraction} referring to any flow of > data from a source (or sender, producer) to a single sink (or > receiver, consumer). A stream usually flows through a channel > of some kind, as opposed to {packet}s which may be addressed > and routed independently, possibly to multiple recipients. > Streams usually require some mechanism for establishing a > channel or a "{connection}" between the sender and receiver. Another comment: one reason not to use "stream" to refer to the exchange of LDAP messages is that LDAP messages are addressed independently (by message id) and routed independently to the directory operation executed at an higher level. That is, messages from multiple operations (each a source) are multiplexed in the exchange. I note that my primary interest is not which particular terms are used where. I am primarily interested in ensuring that our terms are well-defined and used in an unambiguous manner. I wouldn't object to using "LDAP connection" and "transport connection" as long as we never use the term "connection" without qualification. Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Apr 19 16:53:41 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09460 for ; Mon, 19 Apr 2004 16:53:40 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3JKph4n094178; Mon, 19 Apr 2004 20:51:58 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3JKoEfH094102; Mon, 19 Apr 2004 20:50:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 19 Apr 2004 20:50:14 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3JKoBhr094091 for ; Mon, 19 Apr 2004 20:50:11 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3JKo2Ms045019; Mon, 19 Apr 2004 20:50:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040419134556.049feb28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 19 Apr 2004 13:49:53 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Protocol: Compare contradiction Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 06:44 PM 4/16/2004, Jim Sermersheim wrote: >The current protocol draft (in my editor) contradicts itself by stating >that the result of a compare will be compareFalse when the asserted >value doesn't match any attribute values or is Undefined (and refers to >Section 4.5.1). > >Then it says if the attribute or subtype has no equality matching rule, >innapropriateMatching is returned in the resultCode. > >Section 4.5.1 is clear that Undefined is the result of no equality >match. > >So the question is: in the absence of an equality rule, is compare >supposed to return compareFalse, or innapropriateMatching? inappropriateMatcing. A key difference between the compare AVA and search AVA (in filters) processing is that compare returns an indication of why the AVA is Undefined. In terms of the 3-value logic, the result of the AVA is Undefined. In terms of the LDAP resultCode, an Undefined AVA results in an error code which indicates why the AVA is Undefined. >X.501 is pretty lame on this one: > >"The purported argument identifies the attribute type and value to be >compared with that in the entry. The comparison is TRUE if the entry >holds the purported attribute type or one of its subtypes, or there is a >collective attribute of the entry which is the purported attribute type >or one of its subtypes (see 7.6), and if there is a value of that >attribute which matches the purported value using the attribute's >equality matching rule." > >It doesn't offer guidance when there is no equality matching rule. >Later it says: > >"The matched result parameter, holds the result of the comparison. The >parameter takes the value TRUE if the values were compared and matched, >and FALSE if they did not." > >and again in the access control instructions: > >"If there exists a value within the attribute being compared that >matches the purported argument and for which Compare permission is >granted, the operation returns the value TRUE in the matched result >parameter of the CompareResult. Otherwise, the operation returns the >value FALSE." > >This can be read to say that if anything prevented the values to match >while comparing, the answer is FALSE. But I doubt that was the intent. > >Jim From owner-ietf-ldapbis@OpenLDAP.org Mon Apr 19 18:17:08 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15807 for ; Mon, 19 Apr 2004 18:17:07 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3JMFdp9097390; Mon, 19 Apr 2004 22:15:44 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3JMEQKd097367; Mon, 19 Apr 2004 22:14:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 19 Apr 2004 22:14:26 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3JMEMsN097337; Mon, 19 Apr 2004 22:14:22 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 19 Apr 2004 16:14:02 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 19 Apr 2004 16:13:28 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: Protocol: Compare contradiction Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartFBDA3218.0__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: 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. --=__PartFBDA3218.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit That's certainly not the way the current draft is worded. Currently Undefined == compareFalse. If the Working Group believes it's correct to specify error behavior for all Undefined cases, I need to refactor that part of the doc. I assume the following attribute and value-related conditions can cause this state: - The asserted attribute or subtype is not present in the named entry - The asserted attribute is unknown - There is no equality matching rule for the attribute or subtype - There is a constraint violation with the asserted value - There is a syntax violation with the asserted value I'm thinking it might be best to state that if the compare cannot resolve to a true or false state an appropriate result code is returned. Jim >>> "Kurt D. Zeilenga" 4/19/04 2:49:53 PM >>> At 06:44 PM 4/16/2004, Jim Sermersheim wrote: >The current protocol draft (in my editor) contradicts itself by stating >that the result of a compare will be compareFalse when the asserted >value doesn't match any attribute values or is Undefined (and refers to >Section 4.5.1). > >Then it says if the attribute or subtype has no equality matching rule, >innapropriateMatching is returned in the resultCode. > >Section 4.5.1 is clear that Undefined is the result of no equality >match. > >So the question is: in the absence of an equality rule, is compare >supposed to return compareFalse, or innapropriateMatching? inappropriateMatcing. A key difference between the compare AVA and search AVA (in filters) processing is that compare returns an indication of why the AVA is Undefined. In terms of the 3-value logic, the result of the AVA is Undefined. In terms of the LDAP resultCode, an Undefined AVA results in an error code which indicates why the AVA is Undefined. >X.501 is pretty lame on this one: > >"The purported argument identifies the attribute type and value to be >compared with that in the entry. The comparison is TRUE if the entry >holds the purported attribute type or one of its subtypes, or there is a >collective attribute of the entry which is the purported attribute type >or one of its subtypes (see 7.6), and if there is a value of that >attribute which matches the purported value using the attribute's >equality matching rule." > >It doesn't offer guidance when there is no equality matching rule. >Later it says: > >"The matched result parameter, holds the result of the comparison. The >parameter takes the value TRUE if the values were compared and matched, >and FALSE if they did not." > >and again in the access control instructions: > >"If there exists a value within the attribute being compared that >matches the purported argument and for which Compare permission is >granted, the operation returns the value TRUE in the matched result >parameter of the CompareResult. Otherwise, the operation returns the >value FALSE." > >This can be read to say that if anything prevented the values to match >while comparing, the answer is FALSE. But I doubt that was the intent. > >Jim --=__PartFBDA3218.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That's certainly not the way the current draft is worded. Currently = Undefined =3D=3D compareFalse. If the Working Group believes it's correct = to specify error behavior for all Undefined cases, I need to refactor that = part of the doc. I assume the following attribute and value-related = conditions can cause this state:
 
- The asserted attribute or subtype is not present in the named = entry
- The asserted attribute is unknown
- There is no equality matching rule for the attribute or subtype
- There is a constraint violation with the asserted value
- There is a syntax violation with the asserted value
 
I'm thinking it might be best to state that if the compare cannot = ;resolve to a true or false state an appropriate result code is = returned.
 
Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> = 4/19/04 2:49:53 PM >>>
At 06:44 PM 4/16/2004, Jim Sermersheim = wrote:
>The current protocol draft (in my editor) contradicts itself = by stating
>that the result of a compare will be compareFalse when = the asserted
>value doesn't match any attribute values or is = Undefined (and refers to
>Section 4.5.1).
>
>Then it = says if the attribute or subtype has no equality matching rule,
>inna= propriateMatching is returned in the resultCode.
>
>Section = 4.5.1 is clear that Undefined is the result of no equality
>match.>
>So the question is: in the absence of an equality rule, is = compare
>supposed to return compareFalse, or innapropriateMatching?
inappropriateMatcing. A key difference between the compare
AVA = and search AVA (in filters) processing is that compare
returns an = indication of why the AVA is Undefined.

In terms of the 3-value = logic, the result of the AVA is
Undefined. In terms of the LDAP = resultCode, an Undefined
AVA results in an error code which indicates = why the AVA
is Undefined.

>X.501 is pretty lame on this = one:
>
>"The purported argument identifies the attribute type = and value to be
>compared with that in the entry. The comparison is = TRUE if the entry
>holds the purported attribute type or one of its = subtypes, or there is a
>collective attribute of the entry which is = the purported attribute type
>or one of its subtypes (see 7.6), and = if there is a value of that
>attribute which matches the purported = value using the attribute's
>equality matching rule."
>
>= It doesn't offer guidance when there is no equality matching rule.
>L= ater it says:
>
>"The matched result parameter, holds the = result of the comparison. The
>parameter takes the value TRUE if the = values were compared and matched,
>and FALSE if they did not."
>= ;
>and again in the access control instructions:
>
>"If = there exists a value within the attribute being compared that
>matche= s the purported argument and for which Compare permission is
>granted= , the operation returns the value TRUE in the matched result
>paramet= er of the CompareResult. Otherwise, the operation returns the
>value = FALSE."
>
>This can be read to say that if anything prevented = the values to match
>while comparing, the answer is FALSE. But I = doubt that was the intent.
>
>Jim

--=__PartFBDA3218.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Mon Apr 19 18:47:03 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18079 for ; Mon, 19 Apr 2004 18:47:03 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3JMjlOm098765; Mon, 19 Apr 2004 22:45:55 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3JMf7v2098599; Mon, 19 Apr 2004 22:41:07 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 19 Apr 2004 22:41:07 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3JMf5rY098587 for ; Mon, 19 Apr 2004 22:41:05 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3JMf0Ms047215; Mon, 19 Apr 2004 22:41:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040419152127.049f16a8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 19 Apr 2004 15:40:50 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Protocol: Compare contradiction Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 03:13 PM 4/19/2004, Jim Sermersheim wrote: >I'm thinking it might be best to state that if the compare cannot resolve to a true or false state an appropriate result code is returned. I suggest saying something like: The compareTrue resultCode indicates the AVA is True. The compareFalse resultCode indicates that the AVA is False. All other resultCodes indicate the AVA is Undefined (see A.2 for a description of these other result codes). and then avoid reinterating information about these other resultCodes in this section. - Kurt > >Jim > >>>> "Kurt D. Zeilenga" 4/19/04 2:49:53 PM >>> >At 06:44 PM 4/16/2004, Jim Sermersheim wrote: >>The current protocol draft (in my editor) contradicts itself by stating >>that the result of a compare will be compareFalse when the asserted >>value doesn't match any attribute values or is Undefined (and refers to >>Section 4.5.1). >> >>Then it says if the attribute or subtype has no equality matching rule, >>innapropriateMatching is returned in the resultCode. >> >>Section 4.5.1 is clear that Undefined is the result of no equality >>match. >> >>So the question is: in the absence of an equality rule, is compare >>supposed to return compareFalse, or innapropriateMatching? > >inappropriateMatcing. A key difference between the compare >AVA and search AVA (in filters) processing is that compare >returns an indication of why the AVA is Undefined. > >In terms of the 3-value logic, the result of the AVA is >Undefined. In terms of the LDAP resultCode, an Undefined >AVA results in an error code which indicates why the AVA >is Undefined. > >>X.501 is pretty lame on this one: >> >>"The purported argument identifies the attribute type and value to be >>compared with that in the entry. The comparison is TRUE if the entry >>holds the purported attribute type or one of its subtypes, or there is a >>collective attribute of the entry which is the purported attribute type >>or one of its subtypes (see 7.6), and if there is a value of that >>attribute which matches the purported value using the attribute's >>equality matching rule." >> >>It doesn't offer guidance when there is no equality matching rule. >>Later it says: >> >>"The matched result parameter, holds the result of the comparison. The >>parameter takes the value TRUE if the values were compared and matched, >>and FALSE if they did not." >> >>and again in the access control instructions: >> >>"If there exists a value within the attribute being compared that >>matches the purported argument and for which Compare permission is >>granted, the operation returns the value TRUE in the matched result >>parameter of the CompareResult. Otherwise, the operation returns the >>value FALSE." >> >>This can be read to say that if anything prevented the values to match >>while comparing, the answer is FALSE. But I doubt that was the intent. >> >>Jim From owner-ietf-ldapbis@OpenLDAP.org Mon Apr 19 19:04:51 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19483 for ; Mon, 19 Apr 2004 19:04:50 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3JN3Z5R099266; Mon, 19 Apr 2004 23:03:36 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3JN2BWb099252; Mon, 19 Apr 2004 23:02:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 19 Apr 2004 23:02:11 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3JN29Mt099231 for ; Mon, 19 Apr 2004 23:02:09 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 19 Apr 2004 17:01:49 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 19 Apr 2004 17:01:10 -0600 From: "Jim Sermersheim" To: , , Cc: Subject: Re: Active Directory question Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartD0F11926.3__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: 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. --=__PartD0F11926.3__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Regarding #1, My opinion is that servers should not return extension = information like this unless it is solicited. Unfortunately, we have = already set a precedent with language tags and the binary option which = both return unsolicited attribute options. The danger is exaclty the = problem you've run into * clients are given data that they don't understand= and can't properly work with. =20 Since we're talking about this on the LDAPBis list, I'll suggest that we = add a recommendation to this effect: =20 Servers SHOULD NOT return attributes with options unless solicited to do = so. =20 Jim >>> "Schleiff, Marty" 4/18/04 12:31:39 AM >>> Gentlemen, When using ldapsearch to lookup the membership in an Active Directory = group, I got the following (abbreviated) response: CN=3DPC Backup Group 1,OU=3DGroups,OU=3DAccounts,DC=3Dsw,DC=3Dnos,DC=3Dboei= ng,DC=3Dcom member;range=3D0-999=3DCN=3DPeterson\, Randy R,OU=3DEnd Users,OU=3DAccounts= ,DC=3Dsw,DC=3Dnos,DC=3Dboeing,DC=3Dcom member;range=3D0-999=3DCN=3DTatham\, William C,OU=3DEnd Users,OU=3DAccounts= ,DC=3Dsw,DC=3Dnos,DC=3Dboeing,DC=3Dcom member;range=3D0-999=3DCN=3DPham\, Steve,OU=3DEnd Users,OU=3DAccounts,DC=3D= sw,DC=3Dnos,DC=3Dboeing,DC=3Dcom I'd never before encountered "range=3D0-999" and wondered what it meant. A = little searching turned up the following URLs: http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt and = http://www.hut.fi/cc/docs/kerberos/nss_ldap.html=20 From the second URL: "Active directory uses a method called "Incremental = Retrieval of Multivalued Properties" which nss_ldap has no support for, at = least not yet. Querying groups having more than 1000 members will return = the first 1000 members, with the 'member' attribute changed to 'member;rang= e=3D0-999'. This is not recognized by nss_ldap, so you will not see any = members for that group. More information can be found in the (now expired) = Internet Draft labeled Incremental Retrieval of Multivalued Attributes = ." I was also referred to http://www.dfn-pca.de/bibliothek/standards/ietf/none= /internet-drafts/draft-haripriya-partial-entry-00.txt ; however, I'm not = sure that applies to my situation (it seems to describe how a client could = request the server to return a partial set of values for a multi-valued = attribute -- in my case I didn't request the range, Active Directory just = gave it to me when I really wanted the complete set of values). I'd value the opinions of this list around the following questions: 1) What do you think of this practice? Being a stranger on this list, I've = withheld my editorial opinion of this practice; however, I'd like to hear = your opinions. 2) Even if I can get my ldap client apps to learn to deal with the = ";range=3D0-999", I don't know how to teach them to obtain subsequent = ranges. Also, as pointed out in section "5.3 Element Ordering", another = client operating on the same entry as my client can add or remove values = between my clients operations to retrieve multiple ranges so that my = client's "requests may result in overlapping, duplicated, or skipped = elements".=20 3) Does The Open Group assessment of "LDAP Ready" require a client to = understand ranges? 4) Does The Open Group assessment of "LDAP Certified" require a server to = return ranges? Or if a server does return ranges (which probably would = confuse many clients), can that server be "LDAP Certified". 5) Will common tools like ldapsearch, PerLDAP, LDAP URLs on a browser = location box, etc. ever be able to request ranges of multi-values = attributes (or do they already have this capability and I'm just unaware)? Thx, Marty.Schleiff@boeing.com ; CISSP Associate Technical Fellow - Cyber Identity Specialist IT Access & Security Services (425) 957-5667 --=__PartD0F11926.3__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Regarding #1, My opinion is that servers should not return extension = information like this unless it is solicited. Unfortunately, we have = already set a precedent with language tags and the binary option which = both return unsolicited attribute options. The danger is exaclty the = problem you've run into =97 clients are given data that they don't = understand and can't properly work with.
 
Since we're talking about this on the LDAPBis list, I'll suggest that = we add a recommendation to this effect:
 
Servers SHOULD NOT return attributes with options unless solicited to = do so.
 
Jim

>>> "Schleiff, Marty" <marty.schleiff@boeing.co= m> 4/18/04 12:31:39 AM >>>
Gentlemen,

When using = ldapsearch to lookup the membership in an Active Directory group, I got = the following (abbreviated) response:

CN=3DPC Backup Group = 1,OU=3DGroups,OU=3DAccounts,DC=3Dsw,DC=3Dnos,DC=3Dboeing,DC=3Dcom
member= ;range=3D0-999=3DCN=3DPeterson\, Randy R,OU=3DEnd Users,OU=3DAccounts,DC=3D= sw,DC=3Dnos,DC=3Dboeing,DC=3Dcom
member;range=3D0-999=3DCN=3DTatham\, = William C,OU=3DEnd Users,OU=3DAccounts,DC=3Dsw,DC=3Dnos,DC=3Dboeing,DC=3Dco= m
member;range=3D0-999=3DCN=3DPham\, Steve,OU=3DEnd Users,OU=3DAccounts,= DC=3Dsw,DC=3Dnos,DC=3Dboeing,DC=3Dcom

I'd never before encountered = "range=3D0-999" and wondered what it meant. A little searching turned up = the following URLs:
http://www.hut.fi/cc/docs/kerberos/draft-kashi= -incremental-00.txt and http://www.hut.fi/cc/docs/kerberos/nss_ldap.html

From the second URL: "Active directory uses a method called = "Incremental Retrieval of Multivalued Properties" which nss_ldap has no = support for, at least not yet. Querying groups having more than 1000 = members will return the first 1000 members, with the 'member' attribute = changed to 'member;range=3D0-999'. This is not recognized by nss_ldap, so = you will not see any members for that group. More information can be found = in the (now expired) Internet Draft labeled Incremental Retrieval of = Multivalued Attributes <draft-kashi-incremental-00.txt> ."

I = was also referred to http://w= ww.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriy= a-partial-entry-00.txt ; however, I'm not sure that applies to my = situation (it seems to describe how a client could request the server to = return a partial set of values for a multi-valued attribute -- in my case = I didn't request the range, Active Directory just gave it to me when I = really wanted the complete set of values).
I'd value the opinions of = this list around the following questions:
1) What do you think of this = practice? Being a stranger on this list, I've withheld my editorial = opinion of this practice; however, I'd like to hear your opinions.
2) = Even if I can get my ldap client apps to learn to deal with the ";range=3D0= -999", I don't know how to teach them to obtain subsequent ranges. Also, = as pointed out in section "5.3 Element Ordering", another client operating = on the same entry as my client can add or remove values between my clients = operations to retrieve multiple ranges so that my client's "requests may = result in overlapping, duplicated, or skipped elements".
3) Does The = Open Group assessment of "LDAP Ready" require a client to understand = ranges?
4) Does The Open Group assessment of "LDAP Certified" require a = server to return ranges? Or if a server does return ranges (which probably = would confuse many clients), can that server be "LDAP Certified".
5) = Will common tools like ldapsearch, PerLDAP, LDAP URLs on a browser = location box, etc. ever be able to request ranges of multi-values = attributes (or do they already have this capability and I'm just unaware)?<= BR>Thx,

Marty.Schlei= ff@boeing.com ; CISSP
Associate Technical Fellow - Cyber = Identity Specialist
IT Access & Security Services
(425) = 957-5667


--=__PartD0F11926.3__=-- From owner-ietf-ldapbis@OpenLDAP.org Mon Apr 19 20:59:45 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25346 for ; Mon, 19 Apr 2004 20:59:44 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3K0vvfc003104; Tue, 20 Apr 2004 00:58:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3K0sgd6003048; Tue, 20 Apr 2004 00:54:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 00:54:42 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3K0sdMD003038 for ; Tue, 20 Apr 2004 00:54:39 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3K0sMMs049456; Tue, 20 Apr 2004 00:54:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040419164220.04901d18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 19 Apr 2004 17:54:14 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Active Directory question Cc: , , , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id i3K0seMD003039 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit At 04:01 PM 4/19/2004, Jim Sermersheim wrote: >Regarding #1, My opinion is that servers should not return extension information like this unless it is solicited. You and I like differ in what we consider 'like this'. The problem with the range extension is that it using options not to create subtypes. It using options (which don't conform to the protocol specification) to alter the basic semantics of the search operation in a fashion which is incompatible with peers which don't support the extension. Assuming the client doesn't puke, the client certainly won't treat these values as being of the right type (it might consider them to be of some oddly named subtype, but that's not quite the same thing). >Unfortunately, we have already set a precedent with language tags and the binary option which both return unsolicited attribute options. But there are some significant differences. First, language tag options and the binary option conform to RFC 2251, 4.1.5. These range options don't. Second, with language tags, the presumption is that values of the subtypes (the tagged descriptions) are being returned in addition to those of the untagged description, just like values of 'cn' when asking for 'name'. With these range options, the values of the ranged descriptions are sent INSTEAD of unranged descriptions. This means, even clients which don't choke on the protocol violation, still won't recognize the values as being of the same description. Third, with the binary option (as used in practice), only applies to attribute types (e.g., userCertificate) which do not have native string encodings and isn't a problem (the information presented with ;binary is not available otherwise). While it could technically be used with other attribute types (e.g., cn), it is recognized that returning such without solicitation would be problematic (because the client might treat it as a subtype) (and was intended only be used where the server couldn't make the information available without ;binary, e.g., server didn't support the native string encoding (or syntax didn't have one)). I think Steven's ;binary revision proposal adequately addresses this problem (e.g., don't return cn;binary unless cn;binary was requested). >The danger is exaclty the problem you've run into — clients are given data that they don't understand and can't properly work with. I disagree that this is the case with language tags and ;binary. I believe LDAP was designed specifically with language tags and ;binary in mind. With range option is quite different. Not only are the options invalid, the client not supporting this extension will interpret the response as not containing values of the requested type (but might interpret the response as containing values of a subtype)... or interpret the response as a protocol error (and disconnect). This is why I say the range extension is truly non-optional, which is far worse than being not truly optional. I think language tags and ;binary, when properly implemented (or as generally implemented in practice), are truly optional. >Since we're talking about this on the LDAPBis list, I'll suggest that we add a recommendation to this effect: > >Servers SHOULD NOT return attributes with options unless solicited to do so. Since '*' does solicit all user attributes and 'cn;lang-x-foo' is a user attribute, it should be returned. Since a requesting 'name' is a request for the attribute 'name' AND its subtypes, 'name;lang-x-foo' (as well as 'cn') is solicited. So, your suggestion seems meaningless as worded. But, if I take your suggestion as I think you intended it, I would argue strongly against it. Attribute options mechanism and subtypes created through this mechanism IS a standard feature of LDAP. RFC 2596 defines a set of option-based subtypes just as some schema document might define a set of SUP-based subtypes. As long as these subtypes are used consistently with core specification, the are no significant interoperability issues. Now, I note, the language tag specification needs to be more clear that tagged values are provided IN ADDITION TO non-tagged values. And ;binary specification needs to be address issues previously raised on this list. But, I think, the [Protocol] and [Models] are fine with regards to attribute options. However, [Roadmap] likely should say something in general about extensions. LDAP is an extensible protocol. Extensions are expected to be truly optional. There is little we can say beyond this to deter creation of extensions which are not truly optional or extensions, such as range options, which are truly non-optional. Kurt > >Jim > >>>> "Schleiff, Marty" 4/18/04 12:31:39 AM >>> >Gentlemen, > >When using ldapsearch to lookup the membership in an Active Directory group, I got the following (abbreviated) response: > >CN=PC Backup Group 1,OU=Groups,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com >member;range=0-999=CN=Peterson\, Randy R,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com >member;range=0-999=CN=Tatham\, William C,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com >member;range=0-999=CN=Pham\, Steve,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com > >I'd never before encountered "range=0-999" and wondered what it meant. A little searching turned up the following URLs: >http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt and http://www.hut.fi/cc/docs/kerberos/nss_ldap.html > > From the second URL: "Active directory uses a method called "Incremental Retrieval of Multivalued Properties" which nss_ldap has no support for, at least not yet. Querying groups having more than 1000 members will return the first 1000 members, with the 'member' attribute changed to 'member;range=0-999'. This is not recognized by nss_ldap, so you will not see any members for that group. More information can be found in the (now expired) Internet Draft labeled Incremental Retrieval of Multivalued Attributes ." > >I was also referred to http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt ; however, I'm not sure that applies to my situation (it seems to describe how a client could request the server to return a partial set of values for a multi-valued attribute -- in my case I didn't request the range, Active Directory just gave it to me when I really wanted the complete set of values). >I'd value the opinions of this list around the following questions: >1) What do you think of this practice? Being a stranger on this list, I've withheld my editorial opinion of this practice; however, I'd like to hear your opinions. >2) Even if I can get my ldap client apps to learn to deal with the ";range=0-999", I don't know how to teach them to obtain subsequent ranges. Also, as pointed out in section "5.3 Element Ordering", another client operating on the same entry as my client can add or remove values between my clients operations to retrieve multiple ranges so that my client's "requests may result in overlapping, duplicated, or skipped elements". >3) Does The Open Group assessment of "LDAP Ready" require a client to understand ranges? >4) Does The Open Group assessment of "LDAP Certified" require a server to return ranges? Or if a server does return ranges (which probably would confuse many clients), can that server be "LDAP Certified". >5) Will common tools like ldapsearch, PerLDAP, LDAP URLs on a browser location box, etc. ever be able to request ranges of multi-values attributes (or do they already have this capability and I'm just unaware)? >Thx, > >Marty.Schleiff@boeing.com ; CISSP >Associate Technical Fellow - Cyber Identity Specialist >IT Access & Security Services >(425) 957-5667 > From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 03:00:43 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27260 for ; Tue, 20 Apr 2004 03:00:42 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3K6wXmu015802; Tue, 20 Apr 2004 06:59:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3K6u44J015702; Tue, 20 Apr 2004 06:56:04 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 06:56:04 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3K6tsrm015648; Tue, 20 Apr 2004 06:55:54 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 20 Apr 2004 00:55:34 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 20 Apr 2004 00:55:04 -0600 From: "Jim Sermersheim" To: Cc: , , , Subject: Re: Active Directory question Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id i3K6tsrm015659 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I'm not sure exactly what the meanings of 'truly optional' 'truly non-optional' are, or whether there is the notion of 'optional * but not truly'. I agree with adding something like you suggest as long as the terminology is defined. But to take the issue a bit further, regarding your first point; The fact that language tags and the binary options conform to RFC 2251 doesn't make me feel that they are any less flawed. The attribute options feature (in my mind) is clearly an extension mechanism. Without means for discovery or solicitation, I believe this extension mechanism is fundamentally flawed. Second, I suspect that the introduction of any new option (especially those that are not 'tagging' options) is going to cause a number of applications to encounter problems unless there is a client solicitation mechanism for it. Currently, a client can only recognize those attribute options that are known to it and fail over to treating attributes with unknown options as either unrecognized attributes, or (worse in some cases, better in others) treat them like tagging options. Who knows what other types of options will be concocted in the future? As long as it's possible to invent an option which (like the range and binary options) can cause mandatory attributes to be treated as unrecognized by a client, I see problems. Third, when you say things like: "While could technically be used with other attribute types (e.g., cn), it is recognized that returning such without solicitation would be problematic" I disagree. Obviously people who don't recognize this class of problems are writing extension documents and implementing them. Furthermore, I don't remember any discussion where anyone warned the authors of this draft against the problems they were creating. It's fine to say that LDAP was designed with attribute options in mind, and that there are no problems with language tags, but I suspect it's more the case not stumbling on one's first steps. It would have been just as easy for an early LDAP author to specify an unsolicited benign response control that carried diagnostics information. It could be that I'm trying to smack the problem with too big of a hammer (though an extension mechanism with no means of solicitation still seems ugly and dangerous). If we're unwilling to recommend against the use of unsolicited options, then I don't believe there is sufficient guidance regarding how one is to define new ones in order to avoid interoperability problems. Maybe your suggestions below, along with something a little more obvious in [Models] (though what that would be escapes me right now) will have to be good enough. I note that the authors of the range option could technically follow the current instructions in [Models] and still claim (with a not very straight face) that they did due diligence in creating the new option. It might look something like: - This option is not a tagging option. - This option can be associated with any multi-valued attribute. - This option does not affect the transfer of attribute values. - This option is to be treated as if it were the attribute description without this option * it is not to be treated as a subtype of the attribute description minus this option. Lame? Yes. But it does follow the instructions in [Models]. Jim >>> "Kurt D. Zeilenga" 4/19/04 6:54:14 PM >>> At 04:01 PM 4/19/2004, Jim Sermersheim wrote: >Regarding #1, My opinion is that servers should not return extension information like this unless it is solicited. You and I like differ in what we consider 'like this'. The problem with the range extension is that it using options not to create subtypes. It using options (which don't conform to the protocol specification) to alter the basic semantics of the search operation in a fashion which is incompatible with peers which don't support the extension. Assuming the client doesn't puke, the client certainly won't treat these values as being of the right type (it might consider them to be of some oddly named subtype, but that's not quite the same thing). >Unfortunately, we have already set a precedent with language tags and the binary option which both return unsolicited attribute options. But there are some significant differences. First, language tag options and the binary option conform to RFC 2251, 4.1.5. These range options don't. Second, with language tags, the presumption is that values of the subtypes (the tagged descriptions) are being returned in addition to those of the untagged description, just like values of 'cn' when asking for 'name'. With these range options, the values of the ranged descriptions are sent INSTEAD of unranged descriptions. This means, even clients which don't choke on the protocol violation, still won't recognize the values as being of the same description. Third, with the binary option (as used in practice), only applies to attribute types (e.g., userCertificate) which do not have native string encodings and isn't a problem (the information presented with ;binary is not available otherwise). While it could technically be used with other attribute types (e.g., cn), it is recognized that returning such without solicitation would be problematic (because the client might treat it as a subtype) (and was intended only be used where the server couldn't make the information available without ;binary, e.g., server didn't support the native string encoding (or syntax didn't have one)). I think Steven's ;binary revision proposal adequately addresses this problem (e.g., don't return cn;binary unless cn;binary was requested). >The danger is exaclty the problem you've run into clients are given data that they don't understand and can't properly work with. I disagree that this is the case with language tags and ;binary. I believe LDAP was designed specifically with language tags and ;binary in mind. With range option is quite different. Not only are the options invalid, the client not supporting this extension will interpret the response as not containing values of the requested type (but might interpret the response as containing values of a subtype)... or interpret the response as a protocol error (and disconnect). This is why I say the range extension is truly non-optional, which is far worse than being not truly optional. I think language tags and ;binary, when properly implemented (or as generally implemented in practice), are truly optional. >Since we're talking about this on the LDAPBis list, I'll suggest that we add a recommendation to this effect: > >Servers SHOULD NOT return attributes with options unless solicited to do so. Since '*' does solicit all user attributes and 'cn;lang-x-foo' is a user attribute, it should be returned. Since a requesting 'name' is a request for the attribute 'name' AND its subtypes, 'name;lang-x-foo' (as well as 'cn') is solicited. So, your suggestion seems meaningless as worded. But, if I take your suggestion as I think you intended it, I would argue strongly against it. Attribute options mechanism and subtypes created through this mechanism IS a standard feature of LDAP. RFC 2596 defines a set of option-based subtypes just as some schema document might define a set of SUP-based subtypes. As long as these subtypes are used consistently with core specification, the are no significant interoperability issues. Now, I note, the language tag specification needs to be more clear that tagged values are provided IN ADDITION TO non-tagged values. And ;binary specification needs to be address issues previously raised on this list. But, I think, the [Protocol] and [Models] are fine with regards to attribute options. However, [Roadmap] likely should say something in general about extensions. LDAP is an extensible protocol. Extensions are expected to be truly optional. There is little we can say beyond this to deter creation of extensions which are not truly optional or extensions, such as range options, which are truly non-optional. Kurt > >Jim > >>>> "Schleiff, Marty" < marty.schleiff@boeing.com > 4/18/04 12:31:39 AM >>> >Gentlemen, > >When using ldapsearch to lookup the membership in an Active Directory group, I got the following (abbreviated) response: > >CN=PC Backup Group 1,OU=Groups,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com >member;range=0-999=CN=Peterson\, Randy R,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com >member;range=0-999=CN=Tatham\, William C,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com >member;range=0-999=CN=Pham\, Steve,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com > >I'd never before encountered "range=0-999" and wondered what it meant. A little searching turned up the following URLs: >< http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt > http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt and < http://www.hut.fi/cc/docs/kerberos/nss_ldap.html > http://www.hut.fi/cc/docs/kerberos/nss_ldap.html > > From the second URL: "Active directory uses a method called "Incremental Retrieval of Multivalued Properties" which nss_ldap has no support for, at least not yet. Querying groups having more than 1000 members will return the first 1000 members, with the 'member' attribute changed to 'member;range=0-999'. This is not recognized by nss_ldap, so you will not see any members for that group. More information can be found in the (now expired) Internet Draft labeled Incremental Retrieval of Multivalued Attributes ." > >I was also referred to < http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt > http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt ; however, I'm not sure that applies to my situation (it seems to describe how a client could request the server to return a partial set of values for a multi-valued attribute -- in my case I didn't request the range, Active Directory just gave it to me when I really wanted the complete set of values). >I'd value the opinions of this list around the following questions: >1) What do you think of this practice? Being a stranger on this list, I've withheld my editorial opinion of this practice; however, I'd like to hear your opinions. >2) Even if I can get my ldap client apps to learn to deal with the ";range=0-999", I don't know how to teach them to obtain subsequent ranges. Also, as pointed out in section "5.3 Element Ordering", another client operating on the same entry as my client can add or remove values between my clients operations to retrieve multiple ranges so that my client's "requests may result in overlapping, duplicated, or skipped elements". >3) Does The Open Group assessment of "LDAP Ready" require a client to understand ranges? >4) Does The Open Group assessment of "LDAP Certified" require a server to return ranges? Or if a server does return ranges (which probably would confuse many clients), can that server be "LDAP Certified". >5) Will common tools like ldapsearch, PerLDAP, LDAP URLs on a browser location box, etc. ever be able to request ranges of multi-values attributes (or do they already have this capability and I'm just unaware)? >Thx, > >< mailto:Marty.Schleiff@boeing.com > Marty.Schleiff@boeing.com ; CISSP >Associate Technical Fellow - Cyber Identity Specialist >IT Access & Security Services >(425) 957-5667 > From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 03:49:29 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29471 for ; Tue, 20 Apr 2004 03:49:29 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3K7jbUE019536; Tue, 20 Apr 2004 07:48:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3K7j4ZM019472; Tue, 20 Apr 2004 07:45:04 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 07:45:04 +0000 Received: from ausyms50.ca.com (mail17.ca.com [155.35.248.106]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3K7j1XE019434 for ; Tue, 20 Apr 2004 07:45:02 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 17:44:35 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6547.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Active Directory question Date: Tue, 20 Apr 2004 17:44:35 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B63810144F5B4@ausyms21.ca.com> Thread-Topic: Active Directory question Thread-Index: AcQmpQQ208oSdVuPS/ez8Fvtcu8RNQABKh/w From: "Ramsay, Ron" To: "Jim Sermersheim" Cc: X-OriginalArrivalTime: 20 Apr 2004 07:44:35.0520 (UTC) FILETIME=[537D4C00:01C426AB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id i3K7j2XE019461 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Jim, You seem to be completely bypassing the issue of whether this *option* can be parsed. With all the options I have seen, it is possible to find the value because none of them allow '=' in the tag. Having an '=' in the range tag means that you must be expecting it, for you cannot find the value otherwise. Compare cn;lang-en=myname with cn;range=001=myname Normal options are terminated by ';' or '=' and can therefore be ignored. This option must actually be recognised to be ignored. So, apart from your metaphysical argument below, there is a real, practical issue. Ron -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Jim Sermersheim Sent: Tuesday, 20 April 2004 16:55 To: Kurt@OpenLDAP.org Cc: marty.schleiff@boeing.com; phil.hunt@octetstring.com; c.harding@opengroup.org; ietf-ldapbis@OpenLDAP.org Subject: Re: Active Directory question I'm not sure exactly what the meanings of 'truly optional' 'truly non-optional' are, or whether there is the notion of 'optional * but not truly'. I agree with adding something like you suggest as long as the terminology is defined. But to take the issue a bit further, regarding your first point; The fact that language tags and the binary options conform to RFC 2251 doesn't make me feel that they are any less flawed. The attribute options feature (in my mind) is clearly an extension mechanism. Without means for discovery or solicitation, I believe this extension mechanism is fundamentally flawed. Second, I suspect that the introduction of any new option (especially those that are not 'tagging' options) is going to cause a number of applications to encounter problems unless there is a client solicitation mechanism for it. Currently, a client can only recognize those attribute options that are known to it and fail over to treating attributes with unknown options as either unrecognized attributes, or (worse in some cases, better in others) treat them like tagging options. Who knows what other types of options will be concocted in the future? As long as it's possible to invent an option which (like the range and binary options) can cause mandatory attributes to be treated as unrecognized by a client, I see problems. Third, when you say things like: "While could technically be used with other attribute types (e.g., cn), it is recognized that returning such without solicitation would be problematic" I disagree. Obviously people who don't recognize this class of problems are writing extension documents and implementing them. Furthermore, I don't remember any discussion where anyone warned the authors of this draft against the problems they were creating. It's fine to say that LDAP was designed with attribute options in mind, and that there are no problems with language tags, but I suspect it's more the case not stumbling on one's first steps. It would have been just as easy for an early LDAP author to specify an unsolicited benign response control that carried diagnostics information. It could be that I'm trying to smack the problem with too big of a hammer (though an extension mechanism with no means of solicitation still seems ugly and dangerous). If we're unwilling to recommend against the use of unsolicited options, then I don't believe there is sufficient guidance regarding how one is to define new ones in order to avoid interoperability problems. Maybe your suggestions below, along with something a little more obvious in [Models] (though what that would be escapes me right now) will have to be good enough. I note that the authors of the range option could technically follow the current instructions in [Models] and still claim (with a not very straight face) that they did due diligence in creating the new option. It might look something like: - This option is not a tagging option. - This option can be associated with any multi-valued attribute. - This option does not affect the transfer of attribute values. - This option is to be treated as if it were the attribute description without this option * it is not to be treated as a subtype of the attribute description minus this option. Lame? Yes. But it does follow the instructions in [Models]. Jim >>> "Kurt D. Zeilenga" 4/19/04 6:54:14 PM >>> At 04:01 PM 4/19/2004, Jim Sermersheim wrote: >Regarding #1, My opinion is that servers should not return extension information like this unless it is solicited. You and I like differ in what we consider 'like this'. The problem with the range extension is that it using options not to create subtypes. It using options (which don't conform to the protocol specification) to alter the basic semantics of the search operation in a fashion which is incompatible with peers which don't support the extension. Assuming the client doesn't puke, the client certainly won't treat these values as being of the right type (it might consider them to be of some oddly named subtype, but that's not quite the same thing). >Unfortunately, we have already set a precedent with language tags and the binary option which both return unsolicited attribute options. But there are some significant differences. First, language tag options and the binary option conform to RFC 2251, 4.1.5. These range options don't. Second, with language tags, the presumption is that values of the subtypes (the tagged descriptions) are being returned in addition to those of the untagged description, just like values of 'cn' when asking for 'name'. With these range options, the values of the ranged descriptions are sent INSTEAD of unranged descriptions. This means, even clients which don't choke on the protocol violation, still won't recognize the values as being of the same description. Third, with the binary option (as used in practice), only applies to attribute types (e.g., userCertificate) which do not have native string encodings and isn't a problem (the information presented with ;binary is not available otherwise). While it could technically be used with other attribute types (e.g., cn), it is recognized that returning such without solicitation would be problematic (because the client might treat it as a subtype) (and was intended only be used where the server couldn't make the information available without ;binary, e.g., server didn't support the native string encoding (or syntax didn't have one)). I think Steven's ;binary revision proposal adequately addresses this problem (e.g., don't return cn;binary unless cn;binary was requested). >The danger is exaclty the problem you've run into clients are given data that they don't understand and can't properly work with. I disagree that this is the case with language tags and ;binary. I believe LDAP was designed specifically with language tags and ;binary in mind. With range option is quite different. Not only are the options invalid, the client not supporting this extension will interpret the response as not containing values of the requested type (but might interpret the response as containing values of a subtype)... or interpret the response as a protocol error (and disconnect). This is why I say the range extension is truly non-optional, which is far worse than being not truly optional. I think language tags and ;binary, when properly implemented (or as generally implemented in practice), are truly optional. >Since we're talking about this on the LDAPBis list, I'll suggest that we add a recommendation to this effect: > >Servers SHOULD NOT return attributes with options unless solicited to do so. Since '*' does solicit all user attributes and 'cn;lang-x-foo' is a user attribute, it should be returned. Since a requesting 'name' is a request for the attribute 'name' AND its subtypes, 'name;lang-x-foo' (as well as 'cn') is solicited. So, your suggestion seems meaningless as worded. But, if I take your suggestion as I think you intended it, I would argue strongly against it. Attribute options mechanism and subtypes created through this mechanism IS a standard feature of LDAP. RFC 2596 defines a set of option-based subtypes just as some schema document might define a set of SUP-based subtypes. As long as these subtypes are used consistently with core specification, the are no significant interoperability issues. Now, I note, the language tag specification needs to be more clear that tagged values are provided IN ADDITION TO non-tagged values. And ;binary specification needs to be address issues previously raised on this list. But, I think, the [Protocol] and [Models] are fine with regards to attribute options. However, [Roadmap] likely should say something in general about extensions. LDAP is an extensible protocol. Extensions are expected to be truly optional. There is little we can say beyond this to deter creation of extensions which are not truly optional or extensions, such as range options, which are truly non-optional. Kurt > >Jim > >>>> "Schleiff, Marty" < marty.schleiff@boeing.com > 4/18/04 12:31:39 AM >>> >Gentlemen, > >When using ldapsearch to lookup the membership in an Active Directory group, I got the following (abbreviated) response: > >CN=PC Backup Group 1,OU=Groups,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com >member;range=0-999=CN=Peterson\, Randy R,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com >member;range=0-999=CN=Tatham\, William C,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com >member;range=0-999=CN=Pham\, Steve,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com > >I'd never before encountered "range=0-999" and wondered what it meant. A little searching turned up the following URLs: >< http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt > http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt and < http://www.hut.fi/cc/docs/kerberos/nss_ldap.html > http://www.hut.fi/cc/docs/kerberos/nss_ldap.html > > From the second URL: "Active directory uses a method called "Incremental Retrieval of Multivalued Properties" which nss_ldap has no support for, at least not yet. Querying groups having more than 1000 members will return the first 1000 members, with the 'member' attribute changed to 'member;range=0-999'. This is not recognized by nss_ldap, so you will not see any members for that group. More information can be found in the (now expired) Internet Draft labeled Incremental Retrieval of Multivalued Attributes ." > >I was also referred to < http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt > http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt ; however, I'm not sure that applies to my situation (it seems to describe how a client could request the server to return a partial set of values for a multi-valued attribute -- in my case I didn't request the range, Active Directory just gave it to me when I really wanted the complete set of values). >I'd value the opinions of this list around the following questions: >1) What do you think of this practice? Being a stranger on this list, I've withheld my editorial opinion of this practice; however, I'd like to hear your opinions. >2) Even if I can get my ldap client apps to learn to deal with the ";range=0-999", I don't know how to teach them to obtain subsequent ranges. Also, as pointed out in section "5.3 Element Ordering", another client operating on the same entry as my client can add or remove values between my clients operations to retrieve multiple ranges so that my client's "requests may result in overlapping, duplicated, or skipped elements". >3) Does The Open Group assessment of "LDAP Ready" require a client to understand ranges? >4) Does The Open Group assessment of "LDAP Certified" require a server to return ranges? Or if a server does return ranges (which probably would confuse many clients), can that server be "LDAP Certified". >5) Will common tools like ldapsearch, PerLDAP, LDAP URLs on a browser location box, etc. ever be able to request ranges of multi-values attributes (or do they already have this capability and I'm just unaware)? >Thx, > >< mailto:Marty.Schleiff@boeing.com > Marty.Schleiff@boeing.com ; CISSP >Associate Technical Fellow - Cyber Identity Specialist >IT Access & Security Services >(425) 957-5667 > From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 05:17:35 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04013 for ; Tue, 20 Apr 2004 05:17:35 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3K9Fhn3024234; Tue, 20 Apr 2004 09:15:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3K9DZGj024154; Tue, 20 Apr 2004 09:13:35 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 09:13:35 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3K9DVx8024123; Tue, 20 Apr 2004 09:13:32 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BFrJn-0004RL-Tv; Tue, 20 Apr 2004 11:13:27 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BFrJf-0006wp-EK; Tue, 20 Apr 2004 11:13:19 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BFrJd-0000zj-00; Tue, 20 Apr 2004 11:13:17 +0200 From: Hallvard B Furuseth Message-Id: To: Jim Sermersheim Cc: Kurt@OpenLDAP.org, marty.schleiff@boeing.com, phil.hunt@octetstring.com, c.harding@opengroup.org, ietf-ldapbis@OpenLDAP.org Subject: Re: Active Directory question In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 20 Apr 2004 11:13:17 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Jim Sermersheim writes: > But to take the issue a bit further, regarding your first point; The > fact that language tags and the binary options conform to RFC 2251 > doesn't make me feel that they are any less flawed. The attribute > options feature (in my mind) is clearly an extension mechanism. I disagree. Tagging options are just simple subtyping, and a useful variant of it. ";binary" is a mess, but it was thought to be a necessary one, so it seems strange to call that an extension. Other options are extensions, yes. > Without means for discovery or solicitation, I believe this extension > mechanism is fundamentally flawed. If you exclude tagging options. > Second, I suspect that the introduction of any new option (especially > those that are not 'tagging' options) is going to cause a number of > applications to encounter problems unless there is a client solicitation > mechanism for it. Currently, a client can only recognize those attribute > options that are known to it and fail over to treating attributes with > unknown options as either unrecognized attributes, or (worse in some > cases, better in others) treat them like tagging options. Who knows what > other types of options will be concocted in the future? True. Actually, I believe we already have that problem with ";binary": A pre-LDAPbis server may send a value with an unsolicited ";binary" option (and with non-textual syntax). A post-LDAPbis client need not recognize ";binary", so it MAY treat it as a tagging option - and thus parse the binary attribute value according to the attribute's string-based syntax. > As long as it's possible to invent an option which (like the range and > binary options) can cause mandatory attributes to be treated as > unrecognized by a client, I see problems. Access controls can hide mandatory attributes too. > It could be that I'm trying to smack the problem with too big of a > hammer (though an extension mechanism with no means of solicitation > still seems ugly and dangerous). If we're unwilling to recommend against > the use of unsolicited options, then I don't believe there is sufficient > guidance regarding how one is to define new ones in order to avoid > interoperability problems. _Can_ we recommend against unsolicited options? An attribute type with an option is a subtype of that attribute type without the option. A search requesting an attribute also requests subtypes. To change either of these sounds like an LDAPv4 change to me, though for non-tagging options it does begin to sound like a good change. > Maybe your suggestions below, along with something a little more obvious > in [Models] (though what that would be escapes me right now) will have > to be good enough. Something like this? - When a non-tagging (sorry, Jim:-) option is defined, it SHOULD be defined in such a manner that it will not be returned unless the client solicits it in some manner, - If the above is not done - and preferably if it is done as well - the option SHOULD be designed so that it will be harmless for the client to treat it as a tagging option, and harmless to treat the attribute description as unrecognized. ("Harmless" could be expanded with a list of possible ways to be harmful.) - Since an attribute with an option is a description subtype of that attribute without the option, and a search for an attribute also returns that attribute's subtypes, non-tagging attribute options that are stored in the directory can often be the wrong solution to a design problem, as the above advice may then be impossible to follow. It may be better to another extension mechanism (such as controls), or to define the option to specify some information which is stored _about_ the attribute but not in the attribute description where it originated. A read operation may then re-insert the attribute option if that operation requests this information. > I note that the authors of the range option could > technically follow the current instructions in [Models] and still claim > (with a not very straight face) that they did due diligence in creating > the new option. It might look something like: (...) If they had called it ";range-0-999" instead of the protocol violation ";range=0-999" BTW, [Models] section 2.5 says "Clients MAY treat an unrecognized attribute option as a tagging option", but is it stated anywhere that clients MAY treat it as anything _else_ than a tagging option? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 07:17:31 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09595 for ; Tue, 20 Apr 2004 07:17:30 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KBFqAc030385; Tue, 20 Apr 2004 11:16:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KBCs0u030288; Tue, 20 Apr 2004 11:12:54 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 11:12:54 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KBCpYl030254; Tue, 20 Apr 2004 11:12:51 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1BFtBE-0005G4-Me; Tue, 20 Apr 2004 13:12:44 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.30) id 1BFtB7-00088A-OA; Tue, 20 Apr 2004 13:12:37 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BFtB4-0001Gn-00; Tue, 20 Apr 2004 13:12:34 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: "connections" (Was: protocol-22 comments) In-Reply-To: <6.0.1.1.0.20040418101616.049d5350@127.0.0.1> References: <6.0.1.1.0.20040416181238.04949f58@127.0.0.1> <6.0.1.1.0.20040417140349.049c0d10@127.0.0.1> <6.0.1.1.0.20040418093715.049da2b8@127.0.0.1> <6.0.1.1.0.20040418101616.049d5350@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 20 Apr 2004 13:12:34 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt D. Zeilenga writes: > Another comment: one reason not to use "stream" to refer to > the exchange of LDAP messages is that LDAP messages are > addressed independently (by message id) and routed > independently to the directory operation executed at an > higher level. That is, messages from multiple operations > (each a source) are multiplexed in the exchange. What of it? The messages still arrive one after another, and the order of their arrival is significant. That might just as well be an argument in favor of calling it a stream, as a reminder of that ordering. > I note that my primary interest is not which particular > terms are used where. I am primarily interested in ensuring > that our terms are well-defined and used in an unambiguous > manner. Fine, but hopefully we can find terms which nobody considers misleading. > I wouldn't object to using "LDAP connection" and > "transport connection" as long as we never use the term > "connection" without qualification. "transport connection" is fine. "LDAP connection" for the LDAP protocol layer/stream/whatever still sounds dubious to me, but then we have votes against all suggestions so far (*connection, LDAP layer, (LDAP) stream). -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 09:36:59 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17246 for ; Tue, 20 Apr 2004 09:36:58 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KDXiTb039150; Tue, 20 Apr 2004 13:35:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KDUSAY038984; Tue, 20 Apr 2004 13:30:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 13:30:28 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KDUMAm038897 for ; Tue, 20 Apr 2004 13:30:22 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 20 Apr 2004 07:29:58 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 20 Apr 2004 07:29:18 -0600 From: "Jim Sermersheim" To: Cc: Subject: RE: Active Directory question Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part3617FEBE.1__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: 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. --=__Part3617FEBE.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Yes there are other problems with the range tags that I'm not even talking about. >>> "Ramsay, Ron" 4/20/04 1:44:35 AM >>> Hi Jim, You seem to be completely bypassing the issue of whether this *option* can be parsed. With all the options I have seen, it is possible to find the value because none of them allow '=' in the tag. Having an '=' in the range tag means that you must be expecting it, for you cannot find the value otherwise. Compare cn;lang-en=myname with cn;range=001=myname Normal options are terminated by ';' or '=' and can therefore be ignored. This option must actually be recognised to be ignored. So, apart from your metaphysical argument below, there is a real, practical issue. Ron -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Jim Sermersheim Sent: Tuesday, 20 April 2004 16:55 To: Kurt@OpenLDAP.org Cc: marty.schleiff@boeing.com ; phil.hunt@octetstring.com ; c.harding@opengroup.org ; ietf-ldapbis@OpenLDAP.org Subject: Re: Active Directory question I'm not sure exactly what the meanings of 'truly optional' 'truly non-optional' are, or whether there is the notion of 'optional * but not truly'. I agree with adding something like you suggest as long as the terminology is defined. But to take the issue a bit further, regarding your first point; The fact that language tags and the binary options conform to RFC 2251 doesn't make me feel that they are any less flawed. The attribute options feature (in my mind) is clearly an extension mechanism. Without means for discovery or solicitation, I believe this extension mechanism is fundamentally flawed. Second, I suspect that the introduction of any new option (especially those that are not 'tagging' options) is going to cause a number of applications to encounter problems unless there is a client solicitation mechanism for it. Currently, a client can only recognize those attribute options that are known to it and fail over to treating attributes with unknown options as either unrecognized attributes, or (worse in some cases, better in others) treat them like tagging options. Who knows what other types of options will be concocted in the future? As long as it's possible to invent an option which (like the range and binary options) can cause mandatory attributes to be treated as unrecognized by a client, I see problems. Third, when you say things like: "While could technically be used with other attribute types (e.g., cn), it is recognized that returning such without solicitation would be problematic" I disagree. Obviously people who don't recognize this class of problems are writing extension documents and implementing them. Furthermore, I don't remember any discussion where anyone warned the authors of this draft against the problems they were creating. It's fine to say that LDAP was designed with attribute options in mind, and that there are no problems with language tags, but I suspect it's more the case not stumbling on one's first steps. It would have been just as easy for an early LDAP author to specify an unsolicited benign response control that carried diagnostics information. It could be that I'm trying to smack the problem with too big of a hammer (though an extension mechanism with no means of solicitation still seems ugly and dangerous). If we're unwilling to recommend against the use of unsolicited options, then I don't believe there is sufficient guidance regarding how one is to define new ones in order to avoid interoperability problems. Maybe your suggestions below, along with something a little more obvious in [Models] (though what that would be escapes me right now) will have to be good enough. I note that the authors of the range option could technically follow the current instructions in [Models] and still claim (with a not very straight face) that they did due diligence in creating the new option. It might look something like: - This option is not a tagging option. - This option can be associated with any multi-valued attribute. - This option does not affect the transfer of attribute values. - This option is to be treated as if it were the attribute description without this option * it is not to be treated as a subtype of the attribute description minus this option. Lame? Yes. But it does follow the instructions in [Models]. Jim >>> "Kurt D. Zeilenga" < Kurt@OpenLDAP.org > 4/19/04 6:54:14 PM >>> At 04:01 PM 4/19/2004, Jim Sermersheim wrote: >Regarding #1, My opinion is that servers should not return extension information like this unless it is solicited. You and I like differ in what we consider 'like this'. The problem with the range extension is that it using options not to create subtypes. It using options (which don't conform to the protocol specification) to alter the basic semantics of the search operation in a fashion which is incompatible with peers which don't support the extension. Assuming the client doesn't puke, the client certainly won't treat these values as being of the right type (it might consider them to be of some oddly named subtype, but that's not quite the same thing). >Unfortunately, we have already set a precedent with language tags and the binary option which both return unsolicited attribute options. But there are some significant differences. First, language tag options and the binary option conform to RFC 2251, 4.1.5. These range options don't. Second, with language tags, the presumption is that values of the subtypes (the tagged descriptions) are being returned in addition to those of the untagged description, just like values of 'cn' when asking for 'name'. With these range options, the values of the ranged descriptions are sent INSTEAD of unranged descriptions. This means, even clients which don't choke on the protocol violation, still won't recognize the values as being of the same description. Third, with the binary option (as used in practice), only applies to attribute types (e.g., userCertificate) which do not have native string encodings and isn't a problem (the information presented with ;binary is not available otherwise). While it could technically be used with other attribute types (e.g., cn), it is recognized that returning such without solicitation would be problematic (because the client might treat it as a subtype) (and was intended only be used where the server couldn't make the information available without ;binary, e.g., server didn't support the native string encoding (or syntax didn't have one)). I think Steven's ;binary revision proposal adequately addresses this problem (e.g., don't return cn;binary unless cn;binary was requested). >The danger is exaclty the problem you've run into clients are given data that they don't understand and can't properly work with. I disagree that this is the case with language tags and ;binary. I believe LDAP was designed specifically with language tags and ;binary in mind. With range option is quite different. Not only are the options invalid, the client not supporting this extension will interpret the response as not containing values of the requested type (but might interpret the response as containing values of a subtype)... or interpret the response as a protocol error (and disconnect). This is why I say the range extension is truly non-optional, which is far worse than being not truly optional. I think language tags and ;binary, when properly implemented (or as generally implemented in practice), are truly optional. >Since we're talking about this on the LDAPBis list, I'll suggest that we add a recommendation to this effect: > >Servers SHOULD NOT return attributes with options unless solicited to do so. Since '*' does solicit all user attributes and 'cn;lang-x-foo' is a user attribute, it should be returned. Since a requesting 'name' is a request for the attribute 'name' AND its subtypes, 'name;lang-x-foo' (as well as 'cn') is solicited. So, your suggestion seems meaningless as worded. But, if I take your suggestion as I think you intended it, I would argue strongly against it. Attribute options mechanism and subtypes created through this mechanism IS a standard feature of LDAP. RFC 2596 defines a set of option-based subtypes just as some schema document might define a set of SUP-based subtypes. As long as these subtypes are used consistently with core specification, the are no significant interoperability issues. Now, I note, the language tag specification needs to be more clear that tagged values are provided IN ADDITION TO non-tagged values. And ;binary specification needs to be address issues previously raised on this list. But, I think, the [Protocol] and [Models] are fine with regards to attribute options. However, [Roadmap] likely should say something in general about extensions. LDAP is an extensible protocol. Extensions are expected to be truly optional. There is little we can say beyond this to deter creation of extensions which are not truly optional or extensions, such as range options, which are truly non-optional. Kurt > >Jim > >>>> "Schleiff, Marty" < marty.schleiff@boeing.com > 4/18/04 12:31:39 AM >>> >Gentlemen, > >When using ldapsearch to lookup the membership in an Active Directory group, I got the following (abbreviated) response: > >CN=PC Backup Group 1,OU=Groups,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com >member;range=0-999=CN=Peterson\, Randy R,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com >member;range=0-999=CN=Tatham\, William C,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com >member;range=0-999=CN=Pham\, Steve,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com > >I'd never before encountered "range=0-999" and wondered what it meant. A little searching turned up the following URLs: >< http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt > http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt and < http://www.hut.fi/cc/docs/kerberos/nss_ldap.html > http://www.hut.fi/cc/docs/kerberos/nss_ldap.html > > From the second URL: "Active directory uses a method called "Incremental Retrieval of Multivalued Properties" which nss_ldap has no support for, at least not yet. Querying groups having more than 1000 members will return the first 1000 members, with the 'member' attribute changed to 'member;range=0-999'. This is not recognized by nss_ldap, so you will not see any members for that group. More information can be found in the (now expired) Internet Draft labeled Incremental Retrieval of Multivalued Attributes ." > >I was also referred to < http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt > http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt ; however, I'm not sure that applies to my situation (it seems to describe how a client could request the server to return a partial set of values for a multi-valued attribute -- in my case I didn't request the range, Active Directory just gave it to me when I really wanted the complete set of values). >I'd value the opinions of this list around the following questions: >1) What do you think of this practice? Being a stranger on this list, I've withheld my editorial opinion of this practice; however, I'd like to hear your opinions. >2) Even if I can get my ldap client apps to learn to deal with the ";range=0-999", I don't know how to teach them to obtain subsequent ranges. Also, as pointed out in section "5.3 Element Ordering", another client operating on the same entry as my client can add or remove values between my clients operations to retrieve multiple ranges so that my client's "requests may result in overlapping, duplicated, or skipped elements". >3) Does The Open Group assessment of "LDAP Ready" require a client to understand ranges? >4) Does The Open Group assessment of "LDAP Certified" require a server to return ranges? Or if a server does return ranges (which probably would confuse many clients), can that server be "LDAP Certified". >5) Will common tools like ldapsearch, PerLDAP, LDAP URLs on a browser location box, etc. ever be able to request ranges of multi-values attributes (or do they already have this capability and I'm just unaware)? >Thx, > >< mailto:Marty.Schleiff@boeing.com > Marty.Schleiff@boeing.com ; CISSP >Associate Technical Fellow - Cyber Identity Specialist >IT Access & Security Services >(425) 957-5667 > --=__Part3617FEBE.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes = there are other problems with the range tags that I'm not even talking = about.

>>> "Ramsay, Ron" <Ron.Ramsay@ca.com> 4/20/04 = 1:44:35 AM >>>
Hi Jim,

You seem to be completely = bypassing the issue of whether this *option* can be parsed. With all the = options I have seen, it is possible to find the value because none of them = allow '=3D' in the tag. Having an '=3D' in the range tag means that you = must be expecting it, for you cannot find the value otherwise.

Compa= re

cn;lang-en=3Dmyname

with

cn;range=3D001=3Dmyname
Normal options are terminated by ';' or '=3D' and can therefore be = ignored. This option must actually be recognised to be ignored.

So, = apart from your metaphysical argument below, there is a real, practical = issue.

Ron

-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP= .org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Jim = Sermersheim
Sent: Tuesday, 20 April 2004 16:55
To: Kurt@OpenLDAP.org
Cc: marty.schleiff@boeing.com ; phil.hunt@octetstring.com= ;
c.harding@opengroup.org= ; ietf-ldapbis@Ope= nLDAP.org
Subject: Re: Active Directory question


I'm= not sure exactly what the meanings of 'truly optional' 'truly non-optional= ' are, or whether there is the notion of 'optional * but not truly'. I = agree with adding something like you suggest as long as the terminology is = defined.

But to take the issue a bit further, regarding your first = point; The fact that language tags and the binary options conform to RFC = 2251 doesn't make me feel that they are any less flawed. The attribute = options feature (in my mind) is clearly an extension mechanism. Without = means for discovery or solicitation, I believe this extension mechanism is = fundamentally flawed.

Second, I suspect that the introduction of = any new option (especially those that are not 'tagging' options) is going = to cause a number of applications to encounter problems unless there is a = client solicitation mechanism for it. Currently, a client can only = recognize those attribute options that are known to it and fail over to = treating attributes with unknown options as either unrecognized attributes,= or (worse in some cases, better in others) treat them like tagging = options. Who knows what other types of options will be concocted in the = future? As long as it's possible to invent an option which (like the range = and binary options) can cause mandatory attributes to be treated as = unrecognized by a client, I see problems.

Third, when you say = things like: "While <the binary option> could technically be used = with other attribute types (e.g., cn), it is recognized that returning = such without solicitation would be problematic" I disagree. Obviously = people who don't recognize this class of problems are writing extension = documents and implementing them. Furthermore, I don't remember any = discussion where anyone warned the authors of this draft against the = problems they were creating.

It's fine to say that LDAP was = designed with attribute options in mind, and that there are no problems = with language tags, but I suspect it's more the case not stumbling on = one's first steps. It would have been just as easy for an early LDAP = author to specify an unsolicited benign response control that carried = diagnostics information.

It could be that I'm trying to smack the = problem with too big of a hammer (though an extension mechanism with no = means of solicitation still seems ugly and dangerous). If we're unwilling = to recommend against the use of unsolicited options, then I don't believe = there is sufficient guidance regarding how one is to define new ones in = order to avoid interoperability problems.
Maybe your suggestions = below, along with something a little more obvious in [Models] (though what = that would be escapes me right now) will have to be good enough. I note = that the authors of the range option could technically follow the current = instructions in [Models] and still claim (with a not very straight face) = that they did due diligence in creating the new option. It might look = something like:
- This option is not a tagging option.
- This option = can be associated with any multi-valued attribute.
- This option does = not affect the transfer of attribute values.
- This option is to be = treated as if it were the attribute description without this option * it = is not to be treated as a subtype of the attribute description minus this = option.

Lame? Yes. But it does follow the instructions in [Models].<= BR>
Jim

>>> "Kurt D. Zeilenga" < Kurt@OpenLDAP.org > 4/19/04 6:54:14 PM = >>>
At 04:01 PM 4/19/2004, Jim Sermersheim wrote:
>Regard= ing #1, My opinion is that servers should not return extension information = like this unless it is solicited.

You and I like differ in what we = consider 'like this'.

The problem with the range extension is that = it using options
not to create subtypes. It using options (which don't = conform
to the protocol specification) to alter the basic semantics
o= f the search operation in a fashion which is incompatible
with peers = which don't support the extension. Assuming the
client doesn't puke, = the client certainly won't treat these
values as being of the right = type (it might consider them
to be of some oddly named subtype, but = that's not quite the
same thing).

>Unfortunately, we have = already set a precedent with language tags and the binary option which = both return unsolicited attribute options.

But there are some = significant differences. First, language
tag options and the binary = option conform to RFC 2251, 4.1.5.
These range options don't.

Sec= ond, with language tags, the presumption is that values of
the subtypes = (the tagged descriptions) are being returned in
addition to those of = the untagged description, just like
values of 'cn' when asking for = 'name'. With these range options,
the values of the ranged descriptions = are sent INSTEAD of
unranged descriptions. This means, even clients = which don't
choke on the protocol violation, still won't recognize = the
values as being of the same description.

Third, with the = binary option (as used in practice), only applies
to attribute types = (e.g., userCertificate) which do not have
native string encodings and = isn't a problem (the information
presented with ;binary is not = available otherwise). While it
could technically be used with other = attribute types (e.g., cn),
it is recognized that returning such = without solicitation
would be problematic (because the client might = treat it as
a subtype) (and was intended only be used where the = server
couldn't make the information available without ;binary, = e.g.,
server didn't support the native string encoding (or syntax
did= n't have one)). I think Steven's ;binary revision proposal
adequately = addresses this problem (e.g., don't return cn;binary
unless cn;binary = was requested).

>The danger is exaclty the problem you've run = into clients are given data that they don't understand and can't properly = work with.

I disagree that this is the case with language tags and = ;binary.
I believe LDAP was designed specifically with language = tags
and ;binary in mind.

With range option is quite different. = Not only are the options
invalid, the client not supporting this = extension will interpret
the response as not containing values of the = requested type
(but might interpret the response as containing values = of a
subtype)... or interpret the response as a protocol error
(and = disconnect).

This is why I say the range extension is truly = non-optional,
which is far worse than being not truly optional. I = think
language tags and ;binary, when properly implemented (or
as = generally implemented in practice), are truly optional.

>Since = we're talking about this on the LDAPBis list, I'll suggest that we add a = recommendation to this effect:
>
>Servers SHOULD NOT return = attributes with options unless solicited to do so.

Since '*' does = solicit all user attributes and 'cn;lang-x-foo'
is a user attribute, it = should be returned. Since a requesting
'name' is a request for the = attribute 'name' AND its subtypes,
'name;lang-x-foo' (as well as 'cn') = is solicited. So, your
suggestion seems meaningless as worded.

Bu= t, if I take your suggestion as I think you intended it,
I would argue = strongly against it.

Attribute options mechanism and subtypes = created through this
mechanism IS a standard feature of LDAP. RFC 2596 = defines
a set of option-based subtypes just as some schema document
m= ight define a set of SUP-based subtypes. As long as these
subtypes are = used consistently with core specification, the
are no significant = interoperability issues.

Now, I note, the language tag specification= needs to be more
clear that tagged values are provided IN ADDITION TO = non-tagged
values. And ;binary specification needs to be address = issues
previously raised on this list.

But, I think, the = [Protocol] and [Models] are fine with
regards to attribute options.
<= BR>However, [Roadmap] likely should say something in general
about = extensions.
LDAP is an extensible protocol. Extensions are
expected = to be truly optional.

There is little we can say beyond this to = deter creation
of extensions which are not truly optional or extensions,=
such as range options, which are truly non-optional.

Kurt

>
>Jim
>
>>>> "Schleiff, Marty" < = marty.schleiff@boeing.com > 4/18/04 12:31:39 AM >>>
>Gentlemen,
>
&= gt;When using ldapsearch to lookup the membership in an Active Directory = group, I got the following (abbreviated) response:
>
>CN=3DPC = Backup Group 1,OU=3DGroups,OU=3DAccounts,DC=3Dsw,DC=3Dnos,DC=3Dboeing,DC=3D= com
>member;range=3D0-999=3DCN=3DPeterson\, Randy R,OU=3DEnd = Users,OU=3DAccounts,DC=3Dsw,DC=3Dnos,DC=3Dboeing,DC=3Dcom
>member;ran= ge=3D0-999=3DCN=3DTatham\, William C,OU=3DEnd Users,OU=3DAccounts,DC=3Dsw,D= C=3Dnos,DC=3Dboeing,DC=3Dcom
>member;range=3D0-999=3DCN=3DPham\, = Steve,OU=3DEnd Users,OU=3DAccounts,DC=3Dsw,DC=3Dnos,DC=3Dboeing,DC=3Dcom>
>I'd never before encountered "range=3D0-999" and wondered = what it meant. A little searching turned up the following URLs:
><= http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt > http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental= -00.txt and < http://www.hut.fi/cc/docs/kerberos/nss_ldap.html = > http:/= /www.hut.fi/cc/docs/kerberos/nss_ldap.html
>
> From = the second URL: "Active directory uses a method called "Incremental = Retrieval of Multivalued Properties" which nss_ldap has no support for, at = least not yet. Querying groups having more than 1000 members will return = the first 1000 members, with the 'member' attribute changed to 'member;rang= e=3D0-999'. This is not recognized by nss_ldap, so you will not see any = members for that group. More information can be found in the (now expired) = Internet Draft labeled Incremental Retrieval of Multivalued Attributes = <draft-kashi-incremental-00.txt> ."
>
>I was also = referred to < http://www.d= fn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-pa= rtial-entry-00.txt > http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/dra= ft-haripriya-partial-entry-00.txt ; however, I'm not sure that = applies to my situation (it seems to describe how a client could request = the server to return a partial set of values for a multi-valued attribute = -- in my case I didn't request the range, Active Directory just gave it to = me when I really wanted the complete set of values).
>I'd value the = opinions of this list around the following questions:
>1) What do = you think of this practice? Being a stranger on this list, I've withheld = my editorial opinion of this practice; however, I'd like to hear your = opinions.
>2) Even if I can get my ldap client apps to learn to deal = with the ";range=3D0-999", I don't know how to teach them to obtain = subsequent ranges. Also, as pointed out in section "5.3 Element Ordering", = another client operating on the same entry as my client can add or remove = values between my clients operations to retrieve multiple ranges so that = my client's "requests may result in overlapping, duplicated, or skipped = elements".
>3) Does The Open Group assessment of "LDAP Ready" = require a client to understand ranges?
>4) Does The Open Group = assessment of "LDAP Certified" require a server to return ranges? Or if a = server does return ranges (which probably would confuse many clients), can = that server be "LDAP Certified".
>5) Will common tools like = ldapsearch, PerLDAP, LDAP URLs on a browser location box, etc. ever be = able to request ranges of multi-values attributes (or do they already have = this capability and I'm just unaware)?
>Thx,
>
>< = mailto:Marty.Schleiff@boein= g.com > Marty.Sc= hleiff@boeing.com ; CISSP
>Associate Technical Fellow - = Cyber Identity Specialist
>IT Access & Security Services
>(= 425) 957-5667
>





--=__Part3617FEBE.1__=-- From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 10:47:50 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22823 for ; Tue, 20 Apr 2004 10:47:49 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KEjpjJ044994; Tue, 20 Apr 2004 14:46:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KEfNfZ044630; Tue, 20 Apr 2004 14:41:23 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 14:41:23 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KEeXnj044531; Tue, 20 Apr 2004 14:40:34 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1BFwQI-0003JG-JZ; Tue, 20 Apr 2004 16:40:30 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.30) id 1BFwQC-000843-1m; Tue, 20 Apr 2004 16:40:24 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BFwQB-0001l0-00; Tue, 20 Apr 2004 16:40:23 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: Re: Protocol: Compare contradiction In-Reply-To: <6.0.1.1.0.20040419152127.049f16a8@127.0.0.1> References: <6.0.1.1.0.20040419152127.049f16a8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 20 Apr 2004 16:40:23 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt D. Zeilenga writes: >At 03:13 PM 4/19/2004, Jim Sermersheim wrote: >> I'm thinking it might be best to state that if the compare cannot >> resolve to a true or false state an appropriate result code is >> returned. > > I suggest saying something like: > The compareTrue resultCode indicates the AVA is True. s/the AVA/at least one AVA/. (BTW, is it correct to say that the AVA "is" True? Or should it be "evaluated to" True?) > The compareFalse resultCode indicates that the AVA is False. s/the AVA is False/there is one or more AVA, and they are all False/. Except... > All other resultCodes indicate the AVA is Undefined > (see A.2 for a description of these other result codes). What if there is no error (or at least none covered by the available result codes), but the matching rule simply evaluated to Undefined? I don't see what else than compareFalse can be returned. > and then avoid reinterating information about these other > resultCodes in this section. Good, unless pulling Undefined into compareFalse makes it less clear what is an error... -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 10:58:39 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23470 for ; Tue, 20 Apr 2004 10:58:39 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KEve6Y045815; Tue, 20 Apr 2004 14:57:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KEuvsw045779; Tue, 20 Apr 2004 14:56:57 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 14:56:57 +0000 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KEukW8045739 for ; Tue, 20 Apr 2004 14:56:46 GMT (envelope-from rbunch@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23358; Tue, 20 Apr 2004 10:56:44 -0400 (EDT) Message-Id: <200404201456.KAA23358@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ldapbis@OpenLDAP.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapbis-protocol-23.txt Date: Tue, 20 Apr 2004 10:56:43 -0400 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP (v3) Revision Working Group of the IETF. Title : LDAP: The Protocol Author(s) : J. Sermersheim Filename : draft-ietf-ldapbis-protocol-23.txt Pages : 61 Date : 2004-4-19 This document describes the protocol elements, along with their semantics and encodings, for the Lightweight Directory Access Protocol (LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-23.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ldapbis-protocol-23.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-ldapbis-protocol-23.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: <2004-4-20111746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapbis-protocol-23.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapbis-protocol-23.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20111746.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 11:47:03 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27378 for ; Tue, 20 Apr 2004 11:47:03 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KFjfXS049579; Tue, 20 Apr 2004 15:45:41 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KFbUFB048698; Tue, 20 Apr 2004 15:37:30 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 15:37:30 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KFab4E048552; Tue, 20 Apr 2004 15:36:38 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 20 Apr 2004 09:36:17 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 20 Apr 2004 09:35:39 -0600 From: "Jim Sermersheim" To: Cc: , , , , Subject: Re: Active Directory question Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartB5947D5B.3__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: 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. --=__PartB5947D5B.3__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >> Hallvard B Furuseth 4/20/04 3:13:17 AM >>> >Jim Sermersheim writes: >> But to take the issue a bit further, regarding your first point; The >> fact that language tags and the binary options conform to RFC 2251 >> doesn't make me feel that they are any less flawed. The attribute >> options feature (in my mind) is clearly an extension mechanism. > >I disagree. Tagging options are just simple subtyping, and a useful >variant of it. ";binary" is a mess, but it was thought to be a >necessary one, so it seems strange to call that an extension. >Other options are extensions, yes. Yes, tagging options are just simple subtyping (although non-discoverable like normal attribute subtyping is). I'm talking about attribute options in general. If only tagging options were allowed, then I wouldn't be going on and on about it. >> Without means for discovery or solicitation, I believe this extension >> mechanism is fundamentally flawed. > >If you exclude tagging options. Fine, while not an interoperability problem, I still argue that a discovery mechanism is needed for completeness. I can discover normal attribute subtyping via the schema. Attribute subtyping due to tagging options just sort of happens. >_Can_ we recommend against unsolicited options? An attribute type with >an option is a subtype of that attribute type without the option. A >search requesting an attribute also requests subtypes. That's only true of tagging options (so far) >To change either >of these sounds like an LDAPv4 change to me, though for non-tagging >options it does begin to sound like a good change. >- When a non-tagging (sorry, Jim:-) option is defined, it SHOULD be >defined in such a manner that it will not be returned unless >the client solicits it in some manner, > >- If the above is not done - and preferably if it is done as well - the >option SHOULD be designed so that it will be harmless for the client >to treat it as a tagging option, and harmless to treat the attribute >description as unrecognized. ("Harmless" could be expanded with a >list of possible ways to be harmful.) Yes, this helps. >- Since an attribute with an option is a description subtype of that >attribute without the option, and a search for an attribute also >returns that attribute's subtypes, non-tagging attribute options that >are stored in the directory can often be the wrong solution to a >design problem, as the above advice may then be impossible to follow. >It may be better to another extension mechanism (such as controls), or >to define the option to specify some information which is stored >_about_ the attribute but not in the attribute description where it >originated. A read operation may then re-insert the attribute option >if that operation requests this information. Only tagging options (so far) exhibit the subtyping semantics described here. >BTW, [Models] section 2.5 says "Clients MAY treat an unrecognized >attribute option as a tagging option", but is it stated anywhere >that clients MAY treat it as anything _else_ than a tagging option? I thought there was language that also allowed a client to treat them as unrecognized attributes, but I guess not. Jim --=__PartB5947D5B.3__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 4/20/04 = 3:13:17 AM >>>
>Jim Sermersheim writes:
>> But to = take the issue a bit further, regarding your first point; The
>> = fact that language tags and the binary options conform to RFC 2251
>&= gt; doesn't make me feel that they are any less flawed. The attribute
&g= t;> options feature (in my mind) is clearly an extension mechanism.
&= gt;
>I disagree. Tagging options are just simple subtyping, and a = useful
>variant of it. ";binary" is a mess, but it was thought to be = a
>necessary one, so it seems strange to call that an extension.
&= gt;Other options are extensions, yes.
Yes, tagging options are just simple subtyping (although non-discovera= ble like normal attribute subtyping is). I'm talking about attribute = options in general. If only tagging options were allowed, then I wouldn't = be going on and on about it.

>> Without means for discovery or solicitation, I believe = this extension
>> mechanism is fundamentally flawed.
>
&g= t;If you exclude tagging options.
Fine, while not an interoperability problem, I still argue that = a discovery mechanism is needed for completeness. I can discover normal = attribute subtyping via the schema. Attribute subtyping due to tagging = options just sort of happens.

<snip>

>_Can_ we recommend against unsolicited options? An attribute = type with
>an option is a subtype of that attribute type without the = option. A
>search requesting an attribute also requests subtypes. =
 
That's only true of tagging options (so far)
 
>To change either
>of these sounds like an LDAPv4 change to = me, though for non-tagging
>options it does begin to sound like a = good change.

>- When a non-tagging (sorry, Jim:-) option is = defined, it SHOULD be
>defined in such a manner that it will not be = returned unless
>the client solicits it in some manner,
>
&g= t;- If the above is not done - and preferably if it is done as well - = the
>option SHOULD be designed so that it will be harmless for the = client
>to treat it as a tagging option, and harmless to treat the = attribute
>description as unrecognized. ("Harmless" could be = expanded with a
>list of possible ways to be harmful.)
Yes, this helps.

>- Since an attribute with an option is a description subtype = of that
>attribute without the option, and a search for an attribute = also
>returns that attribute's subtypes, non-tagging attribute = options that
>are stored in the directory can often be the wrong = solution to a
>design problem, as the above advice may then be = impossible to follow.
>It may be better to another extension = mechanism (such as controls), or
>to define the option to specify = some information which is stored
>_about_ the attribute but not in = the attribute description where it
>originated. A read operation may = then re-insert the attribute option
>if that operation requests this = information.
Only tagging options (so far) exhibit the subtyping semantics = described here.

<snip>

>BTW, [Models] section 2.5 says "Clients MAY treat an = unrecognized
>attribute option as a tagging option", but is it = stated anywhere
>that clients MAY treat it as anything _else_ than a = tagging option?
I thought there was language that also allowed a client to treat them = as unrecognized attributes, but I guess not.
 
Jim
--=__PartB5947D5B.3__=-- From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 11:55:59 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28622 for ; Tue, 20 Apr 2004 11:55:58 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KFpikj050192; Tue, 20 Apr 2004 15:54:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KFkjnU049679; Tue, 20 Apr 2004 15:46:45 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 15:46:45 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KFkcYL049660 for ; Tue, 20 Apr 2004 15:46:38 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3KFk0Ms064289; Tue, 20 Apr 2004 15:46:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040420075137.04914380@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 20 Apr 2004 08:45:50 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Protocol: Compare contradiction Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.1.1.0.20040419152127.049f16a8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 07:40 AM 4/20/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 03:13 PM 4/19/2004, Jim Sermersheim wrote: >>> I'm thinking it might be best to state that if the compare cannot >>> resolve to a true or false state an appropriate result code is >>> returned. >> >> I suggest saying something like: >> The compareTrue resultCode indicates the AVA is True. > >s/the AVA/at least one AVA/. The Compare operation only requests one AVA be evaluated. Performance of that assertion might involve evaluation of a rule for multiple attributes, and multiple values of that attribute, but that's all part of a single AVA. >(BTW, is it correct to say that the AVA "is" True? Or should >it be "evaluated to" True?) I think it is at least proper to say "is" True. Obviously, for an assertion to be true, that assertion must have been "evaluated". I use "indicates" as, for codes indicating the AVA is Undefined, could be because the AVA itself was not actually evaluated (for instance, because the client was not authorized to use the compare operation on the target entry). Note that I purposely turned the text around so that it didn't prescribe server behavior (which code should return when), but described the semantics of the information exchanged (this code means this). >> The compareFalse resultCode indicates that the AVA is False. > >s/the AVA is False/there is one or more AVA, and they are all False/. >Except... See above. >> All other resultCodes indicate the AVA is Undefined >> (see A.2 for a description of these other result codes). > >What if there is no error (or at least none covered by the available >result codes), but the matching rule simply evaluated to Undefined? Don't know what you mean by "simply evaluates to Undefined". An AVA evaluates to Undefined on three conditions: attribute type was unrecognized attribute type was has no equality rule assertion value is Undefined. Otherwise, the rule evaluates to True or False. However, the rule may not be evaluated for a number of other reasons, and in these cases, the AVA is also said to be Undefined as it has not been evaluated. Now, maybe the last sentence should be: The undefinedAttributeType result code indicates the AVA is Undefined due to the asserted attribute description being unrecognized. The inappropriateMatching result code indicates the AVA is Undefined due to attribute type of the asserted attribute description not having an equality matching rule. The invalidSyntax result code indicates the AVA is Undefined as the asserted value does not valid per the syntax of the assertion value. All other result codes indicate an exception condition and generally imply that the assertion was not evaluated (or that the result of the evaluation is undisclosed). >I don't see what else than compareFalse can be returned. Can you come up with an equality rule (see X.501 for requirements of equality rules) for which Undefined is not an exceptional condition. (Note: a rule which always evaluates to Undefined does so not on exception, but such a rule cannot be an equality rule). >> and then avoid reinterating information about these other >> resultCodes in this section. > >Good, unless pulling Undefined into compareFalse makes it less >clear what is an error... No. An Undefined (in the X.501 sense) AVA is not to be reported as compareFalse. From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 12:51:37 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03443 for ; Tue, 20 Apr 2004 12:51:36 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KGdfR1053043; Tue, 20 Apr 2004 16:50:30 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KGdDPM052991; Tue, 20 Apr 2004 16:39:13 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 16:39:13 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KGd5K8052975 for ; Tue, 20 Apr 2004 16:39:05 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3KGbVMs065035; Tue, 20 Apr 2004 16:37:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040420093012.04a60c10@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 20 Apr 2004 09:37:22 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Active Directory question Cc: , , , , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 08:35 AM 4/20/2004, Jim Sermersheim wrote: >If only tagging options were allowed, then I wouldn't be going on and on about it. To ensure interoperability between implementations which support different options, we've adopted two basic rules: Servers are to treat attribute descriptions with unrecognized options as unrecognized. Clients may treat attribute descriptions with unrecognized options either as unrecognized or subtypes of the attribute type in the description. This means that server can return subtypes indicated by tagging options just as they would for other subtypes (e.g., without requiring explicit naming of the subtype in the solicitation). However, servers cannot return options (like a range option) which have semantics incompatible/non-interoperable with either of the allowed client treatments. To do so would not be truly optional. Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 13:04:31 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04343 for ; Tue, 20 Apr 2004 13:04:30 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KGpfpn054024; Tue, 20 Apr 2004 17:03:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KGpBEA054002; Tue, 20 Apr 2004 16:51:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 16:51:11 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KGoiFe053957; Tue, 20 Apr 2004 16:50:44 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1BFyRe-0006kG-Il; Tue, 20 Apr 2004 18:50:02 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.30) id 1BFyRb-0005eH-Ak; Tue, 20 Apr 2004 18:49:59 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BFyRa-00023J-00; Tue, 20 Apr 2004 18:49:58 +0200 From: Hallvard B Furuseth Message-Id: To: Jim Sermersheim Cc: marty.schleiff@boeing.com, phil.hunt@octetstring.com, c.harding@opengroup.org, ietf-ldapbis@OpenLDAP.org, Kurt@OpenLDAP.org Subject: Re: Active Directory question In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 20 Apr 2004 18:49:58 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Jim Sermersheim writes: >Hallvard B Furuseth >>Jim Sermersheim writes: >>> >>> Without means for discovery or solicitation, I believe this extension >>> mechanism is fundamentally flawed. >> >> If you exclude tagging options. > > Fine, while not an interoperability problem, I still argue that a > discovery mechanism is needed for completeness. I can discover normal > attribute subtyping via the schema. Attribute subtyping due to tagging > options just sort of happens. You could write up an RFC for a supportedTaggingOptions attribute, or something. Seems fairly simple and non-intrusive, compared to the other problems with attribute options in this thread. I'm uncertain about one thing in that regard: Option definitions are not part of the (standardized) schema. So may an option name, like an attribute name, have different meanings in different parts of the DIT - in the same server? That is not the impression I had, but it must be possible if shadowing of entries in general is to be possible. Maybe [Models] should clarify how that works. >> _Can_ we recommend against unsolicited options? An attribute type with >> an option is a subtype of that attribute type without the option. A >> search requesting an attribute also requests subtypes. > > That's only true of tagging options (so far) Oh, good. Seems to have been fixed since rfc2251 section 4.1.5: An AttributeDescription with one or more options is treated as a subtype of the attribute type without any options. This should be listed in [Models] Appendix A.1: Changes to RFC 2251. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 13:11:28 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04964 for ; Tue, 20 Apr 2004 13:11:27 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KHAeOP055657; Tue, 20 Apr 2004 17:10:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KGwPmX054825; Tue, 20 Apr 2004 16:58:25 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 16:58:25 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KGwBUG054772; Tue, 20 Apr 2004 16:58:13 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 20 Apr 2004 10:57:51 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 20 Apr 2004 10:57:10 -0600 From: "Jim Sermersheim" To: Cc: , , , , Subject: Re: Active Directory question Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part8DAC4576.3__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: 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. --=__Part8DAC4576.3__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Ok, then something to the effect of your last statement will be added? >>> "Kurt D. Zeilenga" 4/20/04 10:37:22 AM >>> At 08:35 AM 4/20/2004, Jim Sermersheim wrote: >If only tagging options were allowed, then I wouldn't be going on and on about it. To ensure interoperability between implementations which support different options, we've adopted two basic rules: Servers are to treat attribute descriptions with unrecognized options as unrecognized. Clients may treat attribute descriptions with unrecognized options either as unrecognized or subtypes of the attribute type in the description. This means that server can return subtypes indicated by tagging options just as they would for other subtypes (e.g., without requiring explicit naming of the subtype in the solicitation). However, servers cannot return options (like a range option) which have semantics incompatible/non-interoperable with either of the allowed client treatments. To do so would not be truly optional. Kurt --=__Part8DAC4576.3__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ok, then something to the effect of your last statement will be = added?

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> = 4/20/04 10:37:22 AM >>>
At 08:35 AM 4/20/2004, Jim Sermersheim = wrote:
>If only tagging options were allowed, then I wouldn't be = going on and on about it.

To ensure interoperability between = implementations which
support different options, we've adopted two = basic rules:

Servers are to treat attribute descriptions with
unr= ecognized options as unrecognized.

Clients may treat attribute = descriptions with
unrecognized options either as unrecognized or
subt= ypes of the attribute type in the description.

This means that = server can return subtypes indicated by
tagging options just as they = would for other subtypes
(e.g., without requiring explicit naming of = the subtype
in the solicitation).

However, servers cannot return = options (like a range
option) which have semantics incompatible/non-inte= roperable
with either of the allowed client treatments. To do so
woul= d not be truly optional.

Kurt

--=__Part8DAC4576.3__=-- From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 13:21:33 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05811 for ; Tue, 20 Apr 2004 13:21:32 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KHKe49056454; Tue, 20 Apr 2004 17:20:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KH7iCU055485; Tue, 20 Apr 2004 17:07:44 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 17:07:44 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KH7UMI055459 for ; Tue, 20 Apr 2004 17:07:30 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3KH6gMs065597; Tue, 20 Apr 2004 17:06:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040420100201.04918138@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 20 Apr 2004 10:06:32 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Active Directory question Cc: , , , , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 09:57 AM 4/20/2004, Jim Sermersheim wrote: >Ok, then something to the effect of your last statement will be added? If properly qualified (e.g., without solicitation), I think I could live with something to that effect. Of course, devil is in the details (e.g., the particular wording). >>>> "Kurt D. Zeilenga" 4/20/04 10:37:22 AM >>> >At 08:35 AM 4/20/2004, Jim Sermersheim wrote: >>If only tagging options were allowed, then I wouldn't be going on and on about it. > >To ensure interoperability between implementations which >support different options, we've adopted two basic rules: > >Servers are to treat attribute descriptions with >unrecognized options as unrecognized. > >Clients may treat attribute descriptions with >unrecognized options either as unrecognized or >subtypes of the attribute type in the description. > >This means that server can return subtypes indicated by >tagging options just as they would for other subtypes >(e.g., without requiring explicit naming of the subtype >in the solicitation). > >However, servers cannot return options (like a range >option) which have semantics incompatible/non-interoperable >with either of the allowed client treatments. To do so >would not be truly optional. > >Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 13:52:44 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04342 for ; Tue, 20 Apr 2004 13:04:30 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KGpfpp054024; Tue, 20 Apr 2004 17:03:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KGmE0C053787; Tue, 20 Apr 2004 16:48:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 16:48:14 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KGm89k053769 for ; Tue, 20 Apr 2004 16:48:08 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3KGm7Ms065240 for ; Tue, 20 Apr 2004 16:48:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040420094057.0491d948@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 20 Apr 2004 09:47:58 -0700 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldapbis-protocol-23.txt In-Reply-To: <200404201456.KAA23358@ietf.org> References: <200404201456.KAA23358@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Please review soon. Technical comments to the list. Editorial comments to the Editor. And, if you do reviewed the work and have no comment, please let me know. Otherwise, I will assume you have not reviewed the I-D. Thanks, Kurt At 07:56 AM 4/20/2004, 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 LDAP (v3) Revision Working Group of the IETF. > > Title : LDAP: The Protocol > Author(s) : J. Sermersheim > Filename : draft-ietf-ldapbis-protocol-23.txt > Pages : 61 > Date : 2004-4-19 > >This document describes the protocol elements, along with their >semantics and encodings, for the Lightweight Directory Access >Protocol (LDAP). LDAP provides access to distributed directory >services that act in accordance with X.500 data and service models. >These protocol elements are based on those described in the X.500 >Directory Access Protocol (DAP). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-23.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >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-ldapbis-protocol-23.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-ldapbis-protocol-23.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: <2004-4-20111746.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-ldapbis-protocol-23.txt > > From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 13:53:12 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08141 for ; Tue, 20 Apr 2004 13:53:12 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KHpstI058273; Tue, 20 Apr 2004 17:51:54 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KHe45H057870; Tue, 20 Apr 2004 17:40:04 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 17:40:04 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KHdWog057822; Tue, 20 Apr 2004 17:39:32 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1BFzDU-0001H8-7S; Tue, 20 Apr 2004 19:39:28 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.30) id 1BFzDQ-00010f-77; Tue, 20 Apr 2004 19:39:24 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BFzDP-00029Z-00; Tue, 20 Apr 2004 19:39:23 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: Re: Protocol: Compare contradiction In-Reply-To: <6.0.1.1.0.20040420075137.04914380@127.0.0.1> References: <6.0.1.1.0.20040419152127.049f16a8@127.0.0.1> <6.0.1.1.0.20040420075137.04914380@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 20 Apr 2004 19:39:23 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt D. Zeilenga writes: >At 07:40 AM 4/20/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>>At 03:13 PM 4/19/2004, Jim Sermersheim wrote: >>>> I'm thinking it might be best to state that if the compare cannot >>>> resolve to a true or false state an appropriate result code is >>>> returned. >>> >>> I suggest saying something like: >>> The compareTrue resultCode indicates the AVA is True. >> >> s/the AVA/at least one AVA/. > > The Compare operation only requests one AVA be evaluated. > Performance of that assertion might involve evaluation of a > rule for multiple attributes, and multiple values of that > attribute, but that's all part of a single AVA. OK, but then it must still be specified somewhere that the AVA is True if at least one of the matches of one of the values evaluate to True, or however that should be worded. And the equivalent appropriate language for False. I no longer know if that belongs in [Models] or [Protocol], though. >> (BTW, is it correct to say that the AVA "is" True? Or should >> it be "evaluated to" True?) > > I think it is at least proper to say "is" True. Obviously, for > an assertion to be true, that assertion must have been "evaluated". I suppose so. I do wonder if it will just introduce confusion, by having "AVA" mean different "actions" and not just different reasons to specify an combination. > I use "indicates" as, for codes indicating the AVA is Undefined, > could be because the AVA itself was not actually evaluated (for > instance, because the client was not authorized to use the > compare operation on the target entry). I don't understand. If the client was not authorized, the server should return some other code than compare, it should not lie about knowing the result. > Note that I purposely turned the text around so that it > didn't prescribe server behavior (which code should return > when), but described the semantics of the information > exchanged (this code means this). Sounds good. I hope it survives the things - e.g. that I turn out to be wrong about that:-) >>> All other resultCodes indicate the AVA is Undefined >>> (see A.2 for a description of these other result codes). >> >> What if there is no error (or at least none covered by the available >> result codes), but the matching rule simply evaluated to Undefined? > > Don't know what you mean by "simply evaluates to Undefined". [Syntaxes] 4.1 (General Considerations): A matching rule evaluates to TRUE, and in some cases Undefined, as specified in the description of the matching rule, otherwise it evaluates to FALSE. Though the same paragraph also says The conditions under which an AttributeValueAssertion or MatchingRuleAssertion evaluates to Undefined are specified in [PROT]. so I suppose [Prot] is free to define that if the matching rule evaluates to Undefined, the AVA evaluates to False, or something. Is that what is happening? I'm suddenly very confused, I thought these were the same values. I'll have to study your X.500 references when I get time. Or perhaps you can clarify with a practical example: Which result code should the Compare operation return - and why? - for comparing AVA "cn=foo" with a "cn" attribute containing one valid UTF-8 string which fails the Prohibit step of Strprep? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 13:53:14 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08167 for ; Tue, 20 Apr 2004 13:53:13 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KHpstG058273; Tue, 20 Apr 2004 17:51:54 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KHjO2q058057; Tue, 20 Apr 2004 17:45:24 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 17:45:24 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KHjJJw058047 for ; Tue, 20 Apr 2004 17:45:19 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3KHisMs066283; Tue, 20 Apr 2004 17:44:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040420102949.04a38248@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 20 Apr 2004 10:44:45 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Active Directory question Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org In-Reply-To: <6.0.1.1.0.20040420101716.04932358@127.0.0.1> References: <6.0.1.1.0.20040420101716.04932358@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 10:27 AM 4/20/2004, Kurt D. Zeilenga wrote: >[trimmed CC list >At 09:49 AM 4/20/2004, Hallvard B Furuseth wrote: >>Jim Sermersheim writes: >>>Hallvard B Furuseth >>>>Jim Sermersheim writes: >>>>> >>>>> Without means for discovery or solicitation, I believe this extension >>>>> mechanism is fundamentally flawed. >>>> >>>> If you exclude tagging options. >>> >>> Fine, while not an interoperability problem, I still argue that a >>> discovery mechanism is needed for completeness. I can discover normal >>> attribute subtyping via the schema. Attribute subtyping due to tagging >>> options just sort of happens. >> >>You could write up an RFC for a supportedTaggingOptions attribute, >>or something. > >supportedFeatures [RFC3673]. Used, for instance, to provide >discovery for language-tag/language-range options >[draft-zeilenga-ldap-rfc2596]. > >>I'm uncertain about one thing in that regard: Option definitions are >>not part of the (standardized) schema. > >options are defined in documents (like schema), but support >for options has traditionally not been discoverable (except >by use). While supportedFeatures may be used in some cases, >it is not necessarily the best approach for all options >(given that options can have a wide range of semantics). > >>So may an option name, like an >>attribute name, have different meanings in different parts of the DIT - >>in the same server? > >If we're talking about unregistered option names, yes, it is >possible that different folks could define options whose >meaning was different in different parts of the DIT (on >same or different servers). > >>That is not the impression I had, but it must be >>possible if shadowing of entries in general is to be possible. Maybe >>[Models] should clarify how that works. > >I don't think we need to go into horrors of using >unregistered attribute option names. > >>>> _Can_ we recommend against unsolicited options? An attribute type with >>>> an option is a subtype of that attribute type without the option. A >>>> search requesting an attribute also requests subtypes. >>> >>> That's only true of tagging options (so far) >> >>Oh, good. Seems to have been fixed since rfc2251 section 4.1.5: >> >> An AttributeDescription with one or more options is treated as a >> subtype of the attribute type without any options. >> >>This should be listed in [Models] Appendix A.1: Changes to RFC 2251. I really don't see [Models] as changing the substance of what RFC 2251 said in regards to options and subtypes. [Models] just clarifies the sentence you quote as applying generally, but in all cases. RFC 2251 included the same substance, it just wasn't as clear (because some folks sometimes took "is treated as" as "is"). Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 20 15:40:31 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16998 for ; Tue, 20 Apr 2004 15:40:30 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KJXjv3063132; Tue, 20 Apr 2004 19:39:17 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3KJOneq062730; Tue, 20 Apr 2004 19:24:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 20 Apr 2004 19:24:49 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3KJOlFg062719 for ; Tue, 20 Apr 2004 19:24:47 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3KJOFMs068027; Tue, 20 Apr 2004 19:24:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040420112719.04941310@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 20 Apr 2004 12:24:06 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Protocol: Compare contradiction Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.1.1.0.20040419152127.049f16a8@127.0.0.1> <6.0.1.1.0.20040420075137.04914380@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 10:39 AM 4/20/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 07:40 AM 4/20/2004, Hallvard B Furuseth wrote: >>>Kurt D. Zeilenga writes: >>>>At 03:13 PM 4/19/2004, Jim Sermersheim wrote: >>>>> I'm thinking it might be best to state that if the compare cannot >>>>> resolve to a true or false state an appropriate result code is >>>>> returned. >>>> >>>> I suggest saying something like: >>>> The compareTrue resultCode indicates the AVA is True. >>> >>> s/the AVA/at least one AVA/. >> >> The Compare operation only requests one AVA be evaluated. >> Performance of that assertion might involve evaluation of a >> rule for multiple attributes, and multiple values of that >> attribute, but that's all part of a single AVA. > >OK, but then it must still be specified somewhere that the AVA is True >if at least one of the matches of one of the values evaluate to True, or >however that should be worded. Yes. The current language in [Protocol-23] is misleading: > ava: holds the attribute description and assertion value with > which an attribute in the entry is to be compared. This should simply be: ava: holds the attribute value assertion to be evaluated. And then briefly describe that the AVA is TRUE if the entry contains (per the equality matching rule of the attribute type in the assertion), the assertion value in the attribute, or its subtype, named in the description. >And the equivalent appropriate language for False. Yes. I'll offer some replacement text in a bit. I want to digest the rest of [Protocol-22] first. >I no longer know if that belongs in [Models] or [Protocol], >though. I think it's mostly a [Protocol] issue. >>> (BTW, is it correct to say that the AVA "is" True? Or should >>> it be "evaluated to" True?) >> >> I think it is at least proper to say "is" True. Obviously, for >> an assertion to be true, that assertion must have been "evaluated". > >I suppose so. I do wonder if it will just introduce confusion, by >having "AVA" mean different "actions" and not just different reasons to >specify an combination. My point is that the request is providing a single AttributeValueAssertion and the response a single result code. Now, depending on context, an AttributeValueAssertion doesn't necessarily represent an Attribute Value Assertion [Models]. [Protocol] needs to be clear as to semantics in each context. >> I use "indicates" as, for codes indicating the AVA is Undefined, >> could be because the AVA itself was not actually evaluated (for >> instance, because the client was not authorized to use the >> compare operation on the target entry). > >I don't understand. If the client was not authorized, the server should >return some other code than compare, it should not lie about >knowing the result. I don't think I implied that the server should lie, though I certainly do think servers may refuse to disclose what the AVA evaluated to (for instance, if it only determined the value as nondisclosurable after evaluating the AVA). My point here is that, to the client, the AVA is Undefined if any result code other than compareTrue or compareFalse is returned, whether because the AVA wasn't evaluated, evaluated to Undefined, or was evaluated but whoses outcome was not disclosed. >> Note that I purposely turned the text around so that it >> didn't prescribe server behavior (which code should return >> when), but described the semantics of the information >> exchanged (this code means this). > >Sounds good. I hope it survives the things - >e.g. that I turn out to be wrong about that:-) I think we need to be careful. We're not always referring to same Undefined things. >>>> All other resultCodes indicate the AVA is Undefined >>>> (see A.2 for a description of these other result codes). >>> >>> What if there is no error (or at least none covered by the available >>> result codes), but the matching rule simply evaluated to Undefined? >> >> Don't know what you mean by "simply evaluates to Undefined". > >[Syntaxes] 4.1 (General Considerations): > > A matching rule > evaluates to TRUE, and in some cases Undefined, as specified in the > description of the matching rule, otherwise it evaluates to FALSE. While AVA evaluation involves matching rule evaluation(s), an Undefined matching rule evaluation doesn't necessarily imply an Undefined AVA evaluation. >Though the same paragraph also says > > The conditions under which an AttributeValueAssertion or > MatchingRuleAssertion evaluates to Undefined are specified in [PROT]. > >so I suppose [Prot] is free to define that if the matching rule >evaluates to Undefined, the AVA evaluates to False, or something. Is >that what is happening? I think your (and possible the documents) are confusing evaluation of an AVA as a whole and evaluation(s) of the associated rule. >I'm suddenly very confused, I thought these >were the same values. I'll have to study your X.500 references when I >get time. > >Or perhaps you can clarify with a practical example: > >Which result code should the Compare operation return - and why? - for >comparing AVA "cn=foo" with a "cn" attribute containing one valid UTF-8 >string which fails the Prohibit step of Strprep? Well, certainly the caseIgnoreMatch(foo, bogus) will be Undefined. Per X.501 though, the AVA (cn=foo) is FALSE. But, I note, the AVA (cn=bogus) would be Undefined (where bogus is some value which fails stringprep). Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 23 13:00:30 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19948 for ; Fri, 23 Apr 2004 13:00:29 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3NGwVvA032255; Fri, 23 Apr 2004 16:59:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3NGsGX2032025; Fri, 23 Apr 2004 16:54:16 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 23 Apr 2004 16:54:16 +0000 Received: from linux8.ikohn.com (linux8.ikohn.com [66.98.242.91]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3NGsFkd032014 for ; Fri, 23 Apr 2004 16:54:16 GMT (envelope-from brian@holmespun.biz) Received: from holmespun.biz (adsl-157-45-154.rdu.bellsouth.net [68.157.45.154]) (authenticated bits=0) by linux8.ikohn.com (8.12.10/8.12.10) with ESMTP id i3NFtFfW031697 for ; Fri, 23 Apr 2004 10:55:15 -0500 Message-ID: <40894ACA.40409@holmespun.biz> Date: Fri, 23 Apr 2004 12:56:42 -0400 From: "Brian G. Holmes" Organization: Holmespun Solutions, LLC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ldapbis@OpenLDAP.org Subject: LDAP/BER To LDAP/XML Conversion? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit LDAP Revision List members... I do not know LDAP, I have never worked with LDAP, and I beg your pardon if this message is erroneous in any way. I understand from a quick review of draft-legg-ldap-transfer-02.txt that there is an interest in representing LDAP in XML. I have developed some software that is capable of performing protocol-specific BER (or DER) to XML data conversions. The software powers a free service; see http://www.holmespun.biz/berasno/. The service currently supports GSM MAP, ITU TCAP, and IETF SNMP. The software is also capable of handling X.509 certificates, CMS, PKIX TAP, and UMTS MAP. It appears that the software might be able to support LPADv3 as well; I used rfc2251, but now see draft-ietf-ldapbis-protocol-23.txt. To know for sure, I need some LDAPMessage hexadecimal data. Do you know where I can find some? I would also like to determine the level of interest in this sort of functionality. Please share any opinions you would like to express. If you think I should take up this question with another group on another list, or in some other forum, then please feel free to provide me with guidance. Thank you. ...Brian -- Holmespun Solutions, LLC http://www.holmespun.biz 919-844-7713 From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 28 04:55:34 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01271 for ; Wed, 28 Apr 2004 04:55:33 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3S8rBX9056249; Wed, 28 Apr 2004 08:53:34 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3S8ma6N056024; Wed, 28 Apr 2004 08:48:36 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 28 Apr 2004 08:48:36 +0000 Received: from nb2.stroeder.com (du-005-066.access.de.clara.net [212.82.228.66]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3S8mW4U055993; Wed, 28 Apr 2004 08:48:32 GMT (envelope-from michael@stroeder.com) Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 05D0E56AE3; Wed, 28 Apr 2004 09:31:14 +0200 (CEST) Message-ID: <408F5DC1.3000501@stroeder.com> Date: Wed, 28 Apr 2004 09:31:13 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org Subject: Re: [ldapext] Authentication information in LDAP URLs References: <019d01c42910$00172970$1801a8c0@CELLO> <40892F18.7060308@stroeder.com> <20040427112026.GE28861@sverresborg.uninett.no> <6.0.1.1.0.20040427144615.04a50128@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040427144615.04a50128@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >> > In note that LDAPBIS had concerns with bindname not be > recognized (let alone supported) by all implementations > and axed it from the revised technical specification. Uuuh? (Cc:-ed ietf-ldapbis@OpenLDAP.org) bindname extension should be left in LDAP URL specification since there are existing applications deploying it. web2ldap and various of my custom software are using it based on the ldapurl.LDAPUrl class in python-ldap. Off course there are security considerations with credentials in LDAP URLs. I generally do not recommend putting credentials in LDAP URLs. Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 28 05:18:22 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02036 for ; Wed, 28 Apr 2004 05:18:21 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3S9Avc4057428; Wed, 28 Apr 2004 09:17:31 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3S96GJU057247; Wed, 28 Apr 2004 09:06:16 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 28 Apr 2004 09:06:16 +0000 Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3S96DOE057214; Wed, 28 Apr 2004 09:06:14 GMT (envelope-from Stig.Venaas@uninett.no) Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i3S95do8026892; Wed, 28 Apr 2004 11:05:40 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i3S95ROt031143; Wed, 28 Apr 2004 11:05:27 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 28 Apr 2004 11:05:27 +0200 From: Stig Venaas To: Michael =?iso-8859-1?Q?Str=F6der?= Cc: "Kurt D. Zeilenga" , ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org Subject: Re: [ldapext] Authentication information in LDAP URLs Message-ID: <20040428090527.GA31120@sverresborg.uninett.no> References: <019d01c42910$00172970$1801a8c0@CELLO> <40892F18.7060308@stroeder.com> <20040427112026.GE28861@sverresborg.uninett.no> <6.0.1.1.0.20040427144615.04a50128@127.0.0.1> <408F5DC1.3000501@stroeder.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <408F5DC1.3000501@stroeder.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Wed, Apr 28, 2004 at 09:31:13AM +0200, Michael Ströder wrote: > Kurt D. Zeilenga wrote: > >> > >In note that LDAPBIS had concerns with bindname not be > >recognized (let alone supported) by all implementations > >and axed it from the revised technical specification. > > Uuuh? (Cc:-ed ietf-ldapbis@OpenLDAP.org) > > bindname extension should be left in LDAP URL specification since there are > existing applications deploying it. web2ldap and various of my custom > software are using it based on the ldapurl.LDAPUrl class in python-ldap. > > Off course there are security considerations with credentials in LDAP URLs. > I generally do not recommend putting credentials in LDAP URLs. Agree with all of this, I'm using bindname too. That bindname is in the specification, doesn't require it to be implemented. At least as I understand it. And those depending on it, should mark it as critical when using it. So I don't understand why it should be axed just because many implementations don't use it. There are still many that do. Even though I see some good uses for credentials in URLs, I would not generally recommend it. And I must confess that it's a danger an URL used in one context might be used in another. There's some danger that credentials are used in a perfectly safe context, but that the URL leaks... Stig From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 28 15:53:05 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12664 for ; Wed, 28 Apr 2004 15:53:04 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3SJl60T001909; Wed, 28 Apr 2004 19:51:09 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3SJfC9b001620; Wed, 28 Apr 2004 19:41:12 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 28 Apr 2004 19:41:12 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3SJfAO7001610 for ; Wed, 28 Apr 2004 19:41:11 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3SJf3Ms048791; Wed, 28 Apr 2004 19:41:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040428115445.04ba9290@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 28 Apr 2004 12:41:04 -0700 To: Michael =?iso-8859-1?Q?Str=F6der?= From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Authentication information in LDAP URLs Cc: ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org In-Reply-To: <408F5DC1.3000501@stroeder.com> References: <019d01c42910$00172970$1801a8c0@CELLO> <40892F18.7060308@stroeder.com> <20040427112026.GE28861@sverresborg.uninett.no> <6.0.1.1.0.20040427144615.04a50128@127.0.0.1> <408F5DC1.3000501@stroeder.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id i3SJfBO7001611 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit At 12:31 AM 4/28/2004, Michael Ströder wrote: >Kurt D. Zeilenga wrote: >>In note that LDAPBIS had concerns with bindname not be >>recognized (let alone supported) by all implementations >>and axed it from the revised technical specification. > >Uuuh? (Cc:-ed ietf-ldapbis@OpenLDAP.org) My categorization of the LDAPBIS WG discussions may be poor simplification. Maybe a better simple categorization would to be to say that the WG recognized that there were a number of thorny technical issues with this feature and the WG choose not to tackle them. Additionally, there were (and still are) implementation report issues with regard to this feature. As the feature uses an extension mechanism and should be Elective as well as truly optional, it is recognized that the specification for this feature, like many other extensions, can be separately documented and separately progressed from the LDAP 'core' technical specification. Given this, and the lateness of this concern, I will not entertain (at this time) the question of whether the specification of this feature should or should not be reincorporated into the 'core' specification. Instead, I encourage you, and others who may believe a new specification of this feature should be progressed, to engineer, on an individual basis, an Internet Draft containing such. Kurt, LDAPBIS co-chair From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 29 03:13:22 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09826 for ; Thu, 29 Apr 2004 03:13:21 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3T6xBnO031335; Thu, 29 Apr 2004 07:12:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3T6wMMl031283; Thu, 29 Apr 2004 06:58:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 29 Apr 2004 06:58:22 +0000 Received: from nb2.stroeder.com (du-006-198.access.de.clara.net [212.82.229.198]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3T6wGhH031248; Thu, 29 Apr 2004 06:58:18 GMT (envelope-from michael@stroeder.com) Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id F32608EB54; Thu, 29 Apr 2004 07:55:57 +0200 (CEST) Message-ID: <409098ED.7090500@stroeder.com> Date: Thu, 29 Apr 2004 07:55:57 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org Subject: Re: [ldapext] Authentication information in LDAP URLs References: <019d01c42910$00172970$1801a8c0@CELLO> <40892F18.7060308@stroeder.com> <20040427112026.GE28861@sverresborg.uninett.no> <6.0.1.1.0.20040427144615.04a50128@127.0.0.1> <408F5DC1.3000501@stroeder.com> <6.0.1.1.0.20040428115445.04ba9290@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040428115445.04ba9290@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id i3T6wKhH031252 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Kurt D. Zeilenga wrote: > At 12:31 AM 4/28/2004, Michael Ströder wrote: > >>Kurt D. Zeilenga wrote: >> >>>In note that LDAPBIS had concerns with bindname not be >>>recognized (let alone supported) by all implementations >>>and axed it from the revised technical specification. >> >>Uuuh? (Cc:-ed ietf-ldapbis@OpenLDAP.org) > > As the feature uses an extension mechanism and should be > Elective as well as truly optional, it is recognized > that the specification for this feature, like many other > extensions, can be separately documented and separately > progressed from the LDAP 'core' technical specification. But with removing bindname extension from draft-ietf-ldapbis-url LDAPBIS WG breaks existing LDAPv3 implementations. This is a strong contradiction to the goal of LDAPBIS WG (as you wrote on LDAPBIS mailing list many many times). > Given this, and the lateness of this concern, I will not > entertain (at this time) the question of whether the > specification of this feature should or should not be > reincorporated into the 'core' specification. I strongly disagree here! You're violating the goal of LDAPBIS not to break existing LDAPv3 implementations. Note that bindname extensions in RFC2255 was just LDAP URL syntax, no semantics were described there. Which is ok IMO. Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 29 09:58:02 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02342 for ; Thu, 29 Apr 2004 09:58:02 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3TDrLHo055398; Thu, 29 Apr 2004 13:56:45 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3TDmKCS055140; Thu, 29 Apr 2004 13:48:20 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 29 Apr 2004 13:48:20 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3TDmJ5R055130 for ; Thu, 29 Apr 2004 13:48:19 GMT (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3TDmBMs064201; Thu, 29 Apr 2004 13:48:17 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040429063551.0497acd8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 29 Apr 2004 06:48:11 -0700 To: Michael =?iso-8859-1?Q?Str=F6der?= From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Authentication information in LDAP URLs Cc: ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org In-Reply-To: <409098ED.7090500@stroeder.com> References: <019d01c42910$00172970$1801a8c0@CELLO> <40892F18.7060308@stroeder.com> <20040427112026.GE28861@sverresborg.uninett.no> <6.0.1.1.0.20040427144615.04a50128@127.0.0.1> <408F5DC1.3000501@stroeder.com> <6.0.1.1.0.20040428115445.04ba9290@127.0.0.1> <409098ED.7090500@stroeder.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id i3TDmJ5R055131 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit At 10:55 PM 4/28/2004, Michael Ströder wrote: >Kurt D. Zeilenga wrote: >>At 12:31 AM 4/28/2004, Michael Ströder wrote: >>>Kurt D. Zeilenga wrote: >>>>In note that LDAPBIS had concerns with bindname not be >>>>recognized (let alone supported) by all implementations >>>>and axed it from the revised technical specification. >>>Uuuh? (Cc:-ed ietf-ldapbis@OpenLDAP.org) >>As the feature uses an extension mechanism and should be >>Elective as well as truly optional, it is recognized >>that the specification for this feature, like many other >>extensions, can be separately documented and separately >>progressed from the LDAP 'core' technical specification. > >But with removing bindname extension from draft-ietf-ldapbis-url LDAPBIS WG breaks existing LDAPv3 implementations. No it doesn't. draft-ietf-ldapbis-url allows extensions such as bindname, it just doesn't specify them. bindname is still specified in RFC 2255. Publication of draft-ietf-ldapbis-url will mean that the current specification of bindname is Historic until a separate specification of bindname is progressed. Such reorganization doesn't 'break' any existing implementation, nor even cause any implementation to be non-conformant. It just means these implementation support a separately defined LDAP URL extension. >This is a strong contradiction to the goal of LDAPBIS WG (as you wrote on LDAPBIS mailing list many many times). I disagree. The goal of this WG, as detailed in the charter, is to engineer an LDAPv3 "core" technical specification suitable for progression to Draft Standard. This has and will involve reorganization of the technical specification, including pushing some features out of the 'core' specification. This has been discussed many times, including during our chartering process and as we undertook previous reorganizations which 'removed' specifications of certain features from the 'core'). >>Given this, and the lateness of this concern, I will not >>entertain (at this time) the question of whether the >>specification of this feature should or should not be >>reincorporated into the 'core' specification. > >I strongly disagree here! You're violating the goal of LDAPBIS not to break existing LDAPv3 implementations. See above. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 30 05:38:29 2004 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05916 for ; Fri, 30 Apr 2004 05:38:28 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.11/8.12.11) with ESMTP id i3U9Zb4e016837; Fri, 30 Apr 2004 09:36:43 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.11/8.12.11/Submit) with SMTP id i3U9XPMj016722; Fri, 30 Apr 2004 09:33:25 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 30 Apr 2004 09:33:24 +0000 Received: from gab54-1.com ([193.136.195.3]) by boole.openldap.org (8.12.11/8.12.11) with SMTP id i3U9XKR4016700 for ; Fri, 30 Apr 2004 09:33:21 GMT (envelope-from kurt@openLDAP.org) Date: Fri, 30 Apr 2004 10:38:15 +0000 To: "Ietf-ldapbis" From: "Kurt" Subject: Re: Hello Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jafollfrrycltcptqwxm" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: ----------jafollfrrycltcptqwxm Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------jafollfrrycltcptqwxm Content-Type: application/octet-stream; name="Nervous_illnesses.scr" Content-Disposition: attachment; filename="Nervous_illnesses.scr" Content-Transfer-Encoding: base64 TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAAHxePekRMelkpvRmJ Gxq1RoNBt0ANM3EXpFkUEEMPiw1UtAqbdKtegF5vOXOtAcB1EpwRh2NQMA8slWm6NKSCqcGz XkIvI8eNS6YBMnRdZZZfeEmiDhJ7H3NCrpgIBSaIADacWLZNRq49iRJygVU7BaAbPSerKFjH ZgmaBbAGtR6uV7BqxnU3UrEJW4oujJlZa2IeiSzAo6dauHWBEII9nBBaq1JITVaFRkZEIgBJ cHlebzdaB19VwAuuvcJ1hUafxS6qlxKmXAZPai9/HXkMAqppmqu7FVZpBKRskF5dRZKvMz2U TJ5oM1c5GaEBuDo+cmVeDXmzTG5GMnisHlaPTjUzS3OmxEKZiIYGsRU/JMW4nTuzrFlVUGsc eyB3Ba2Ou1doYTSRXw9YHmAgjls+bRcJbY8nfRKjKb+7mCgIFwigG6SwoI+LrxEXjLJ8UaVd x02gY0mMGlF3iQ18JQsopi89uD/Flr04x1KboXqSoxSdwQW6FKWtFY4MrgI3BSNnZoShJ3YJ SWxxFcIAY761IkUOGXRRCnASjRV2XnBATotAb6+aUooBXpplmnFTZx5+qbSLdBMkxSWOC4pH o3kTA0piOz8UV1FGpZIWeS4YZ8Y4WZeJsjULT3mQEIxdfI9fEgkCx6OdERpzcsB6O5x9KS0J CXQhE65ms15zPoi8qZPAX66NdhefaFiMLVm5PS0mjhNpeU0JxRISUQyjmnEIDKgLtsNSLaVt Q6AOr4t6vUM5lo0wmTBkiX6Fp7mCs5pYkW2wkaihAS1puFoehidoY0KWE4R1c1GPiDy3LRPD YqqhO75OCgx9jHqOLmQTw7SRF18= ----------jafollfrrycltcptqwxm--