From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 10:45:19 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 KAA07509 for ; Fri, 9 Jan 2004 10:45:18 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i090pBre033595; Fri, 9 Jan 2004 00:53:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i090kRkW033524; Fri, 9 Jan 2004 00:46: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); Fri, 9 Jan 2004 00:46:27 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i090k5rY033514 for ; Fri, 9 Jan 2004 00:46:06 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.9) with ESMTP id i090k5u0099234; Fri, 9 Jan 2004 00:46:05 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040108155344.042cafd8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 08 Jan 2004 16:45:45 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: authmeth-09 comments Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.0.22.0.20040106120149.043c5350@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:34 PM 1/8/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 07:35 AM 1/3/2004, Hallvard B Furuseth wrote: >>>authmeth-09 says: > >> We also should mention spoofing of a client to trick a server >> into something. > >I don't understand. Maybe just a terminology thing... >> (7) Spoofing of directory: Tricking a client into believing that >> information came from the directory when in fact it did not, >> either by modifying data in transit or misdirecting the client's >> connection. Also, tricking a client into sending privileged >> information to a hostile entity that appears to be the directory >> but is not. Replace each use of 'directory' above with 'client' and every use of 'client' with 'server', you get: >> (7) Spoofing of client: Tricking a server into believing that >> information came from the client when in fact it did not, >> either by modifying data in transit or misdirecting the server's >> connection. Also, tricking a server into sending privileged >> information to a hostile entity that appears to be the directory >> but is not. The only bit of that seems a little odd to me is "misdirecting the server's connection". But just ignore that. My point is that an attacker can, by modifying data in transit or other means, trick the server into disclosing information inappropriately. >Clients relate to specific identified servers, but the reverse is not true. Typically, maybe. But note that the protocol model nor the TCP mapping does not say that LDAP connections are always client initiated. It only says that clients are to support initiation and server should support a listener. There is nothing that prevents a server (presumedly under some agreement it has with the client) to initiate the connect to the client. I wouldn't be surprised to hear of implementation and real-world use of this (considering mobile servers and NAT/Firewalls issues). (But I wasn't thinking of any particular attack when I said this.) >Servers relate to authenticated users and access control factors >for the user and the connection. Clients relate to 'authenticated services". Both are "authenticated entities" which can be spoofed. >Those may include the DNS domain or IP address of the client, so we >should mention that as a threat to servers as well as clients. Is >that what you mean? > >Or if you mean client certificates - I'm not sure if a server may >refuse access to clients without known certificates, but stealing a >certificate seems in any case no different from stealing a password >to me. I wasn't thinking of any particular attack when I said this. >> LDAP offers the following security mechanisms: >> >>>> (1) Client authentication by means of the Secure Authentication and >>>> Security Layer (SASL) [SASL] mechanism set >>> >>>...or LDAP's simple password mechanism... >>> >>>(or maybe you should just delete the part about SASL and just say >>>'Client authentication'.) >> >> I think this can be worded: >> 1) Authentication by means of the Bind operation. The Bind >> operation provides a simple method which supports anonymous, >> unauthenticated, and authenticated with password mechanisms, >> and the Secure Authentication and Security Layer (SASL) method >> which supports a wide variety of authentication mechanisms. >> The Bind operation may be extended to support additional >> methods of authentication. > >I think that's too long and too detailed for this section, which is >just a summary. It's already a problem that the draft keeps >repeating itself. No need to add to that. Well, you could delete the last sentence or two. >Now that I think of it, I think this is enough: > > (1) Client authentication by various means, including a > simple password mechanism and the Secure Authentication > and Security Layer (SASL) [SASL] mechanism set, as well > as unauthenticated users, I rather drop the "as well as unauthenticated users" phrase (which actually is a problem in my suggestion as well) because we're talking about means for establishing the client identity, not means for establishing an anonymous association. >>>> 3. Bind Operation >>> >>>> The new LDAP association >>>> is established upon successful completion of the authentication >>>> exchange. >>> >>>Remove 'successful'. A failed bind establishes a new association >>>too. >> >> I think we need to careful here... >> >> Maybe something like: >> The Bind operation defined in section 4.2 of [Protocol] allows >> authentication information to be exchanged between the client and >> server to establish a new LDAP association. Upon receipt of >> a Bind request, the LDAP association moved to an anonymous >> state and only upon successful completion of the authentication >> exchange (and the Bind operation) is the association moved to >> an authenticated state. s/LDAP association moved/LDAP association is moved/ >Fine. (It's not entirely correct, since successful Bind can move >the association to an anonymous state too, but other parts of the >draft deal with that.) (Well, it's correct in the sense that the association is already in an anonymous state upon receipt and hence the subsequent move is moot.) >>>> 8. LDAP Association State Transition Tables >>> >>>The more I look at this section, the less I like it... How about >>>moving it to a non-normative appendix? I *really* hope this section >>>doesn't contain any information which must be read and can't be seen >>>elsewhere in the draft. >> >> I concur that these tables should be moved to an Informative >> appendix (or section). Implementators should not need to grok >> these tables to properly implement the protocol. The tables >> should be informative, provided to help the implementor to >> understand the prose. > >So far, I find the prose far easier to track than the table, so my >_real_ preference is for the table to be deleted. Roger didn't >dignify that suggestion with a reply when he replied to the message >suggesting that, though... OTOH, nobody spoke up and said 'yes, I >find the table useful':-) I believe some find the table useful. Personally, I worry that the table might not accurately reflect the prose. (As co-chair, I'm concerned by the lack of attention the tables are getting.) Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 10:45: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 KAA07511 for ; Fri, 9 Jan 2004 10:45:19 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08NF5ra030583; Thu, 8 Jan 2004 23:15:08 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i08NDtK9030556; Thu, 8 Jan 2004 23:13: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, 8 Jan 2004 23:13:55 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08NCrrY030525; Thu, 8 Jan 2004 23:12:53 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 08 Jan 2004 16:12:38 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Thu, 08 Jan 2004 16:11:52 -0700 From: "Jim Sermersheim" To: , Cc: Subject: Re: Protocol: control specifications. Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartE1BF2EA8.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. --=__PartE1BF2EA8.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Looks good to me. >>> "Kurt D. Zeilenga" 1/8/04 3:54:50 PM >>> Though I think you might have misunderstand some of my points, I likely some of yours, and that we're not exactly seeing eye to eye on the "why", I think we've converging on acceptable replacement text. Here is my latest offering: - guidance as to what value the sender should provide for the criticality field (note: the processing semantics of the criticality field, which are defined above, should not be altered in any way by the control's specification), Comments? Kurt --=__PartE1BF2EA8.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Looks good to me.

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 1/8/04 3:54:50 PM >>>
Though I think you might have misunderstand some of my points,
I likely some of yours, and that we're not exactly seeing eye to
eye on the "why", I think we've converging on acceptable
replacement text. Here is my latest offering:

- guidance as to what value the sender should provide for the
criticality field (note: the processing semantics of the
criticality field, which are defined above, should not be
altered in any way by the control's specification),

Comments? Kurt

--=__PartE1BF2EA8.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 10:45: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 KAA07528 for ; Fri, 9 Jan 2004 10:45:20 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08Mv7ra029726; Thu, 8 Jan 2004 23:00:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i08MtWSL029598; Thu, 8 Jan 2004 22:55: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); Thu, 8 Jan 2004 22:55:32 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08MtBrY029555 for ; Thu, 8 Jan 2004 22:55: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.9) with ESMTP id i08MtAu0098439; Thu, 8 Jan 2004 22:55:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040108134903.0423dd10@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 08 Jan 2004 14:54:50 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Protocol: control specifications. Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.0.22.0.20040106081000.043e87c8@127.0.0.1> <6.0.0.22.0.20040108082956.0271b498@127.0.0.1> <6.0.0.22.0.20040108112609.042259e8@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: Though I think you might have misunderstand some of my points, I likely some of yours, and that we're not exactly seeing eye to eye on the "why", I think we've converging on acceptable replacement text. Here is my latest offering: - guidance as to what value the sender should provide for the criticality field (note: the processing semantics of the criticality field, which are defined above, should not be altered in any way by the control's specification), Comments? Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 10:45: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 KAA07545 for ; Fri, 9 Jan 2004 10:45:20 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08M92ru025601; Thu, 8 Jan 2004 22:13:31 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i08M39S6025266; Thu, 8 Jan 2004 22:03: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); Thu, 8 Jan 2004 22:03:09 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08M2mrY025237 for ; Thu, 8 Jan 2004 22:02:48 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 1AeiEm-000425-Qg; Thu, 08 Jan 2004 23:02:44 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AeiEg-0000E6-GL; Thu, 08 Jan 2004 23:02:38 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AeiEf-0007E1-00; Thu, 8 Jan 2004 23:02:37 +0100 From: Hallvard B Furuseth Message-Id: To: Steven Legg Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: protocol: ASN.1 for Attribute In-Reply-To: <3FFB6C5E.2000805@adacel.com.au> References: <3FFB6C5E.2000805@adacel.com.au> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 8 Jan 2004 23:02:37 +0100 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=-4.9, required 12, BAYES_00 -4.90) 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: Steven Legg writes: >Hallvard B Furuseth wrote: >> I'd like to join my belated vote against the hairy >> >> Attribute ::= PartialAttribute(WITH COMPONENTS { >> ..., >> vals (SIZE(1..MAX))}) >> >> (...) > > The current notation allows ASN.1 compilers to recognize that Attribute > is related by derivation to PartialAttribute. (...) I see. That sounds good. I withdraw my objection. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 10:46: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 KAA07654 for ; Fri, 9 Jan 2004 10:46:22 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08M92rw025601; Thu, 8 Jan 2004 22:13:31 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i08LwrHL024992; Thu, 8 Jan 2004 21:58: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); Thu, 8 Jan 2004 21:58:53 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08LwVrY024968 for ; Thu, 8 Jan 2004 21:58: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 1AeiAe-0003df-KS for ietf-ldapbis@openldap.org; Thu, 08 Jan 2004 22:58:28 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AeiAc-0007qN-HB; Thu, 08 Jan 2004 22:58:26 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AeiAc-0007Dg-00; Thu, 8 Jan 2004 22:58:26 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Re: DIGIT in xstring (was: models-09 comments) In-Reply-To: <6.0.0.22.0.20040107093334.0410cd18@127.0.0.1> References: <6.0.0.22.0.20031224110949.041efa60@127.0.0.1> <6.0.0.22.0.20040107093334.0410cd18@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 8 Jan 2004 22:58:26 +0100 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=-4.9, required 12, BAYES_00 -4.90) 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 09:03 AM 1/7/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>>At 08:45 AM 12/21/2003, Hallvard B Furuseth wrote: >>>>draft-ietf-ldapbis-models-09.txt says: >> >>>>> xstring = X HYPHEN 1*( ALPHA / HYPHEN / USCORE ) >>> >>>>Should xstring allow DIGIT? > (...) > Such a change would make older implementations of LDAP > incompatible with newer implementations of LDAP. Oh, so it's an 'informal semi-standard'. Agreed, better to leave that alone. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 10:46: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 KAA07661 for ; Fri, 9 Jan 2004 10:46:23 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08Lp9ra024537; Thu, 8 Jan 2004 21:51:37 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i08LkYUY024345; Thu, 8 Jan 2004 21:46: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); Thu, 8 Jan 2004 21:46:34 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08LjUrY024305; Thu, 8 Jan 2004 21:45:31 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 1Aehy3-0002Or-QQ; Thu, 08 Jan 2004 22:45:27 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1Aehxw-0004ID-Lb; Thu, 08 Jan 2004 22:45:20 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1Aehxw-0007Bw-00; Thu, 8 Jan 2004 22:45:20 +0100 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: Re: Protocol: control specifications. In-Reply-To: <6.0.0.22.0.20040108112609.042259e8@127.0.0.1> References: <6.0.0.22.0.20040106081000.043e87c8@127.0.0.1> <6.0.0.22.0.20040108082956.0271b498@127.0.0.1> <6.0.0.22.0.20040108112609.042259e8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 8 Jan 2004 22:45:20 +0100 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=-4.9, required 12, BAYES_00 -4.90) 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:11 AM 1/8/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>> As I previously suggested: >>>> Consider the need to update a specification from "clients MUST provide >>>> criticality field of TRUE" to "clients SHOULD provide criticality field >>>> of TRUE". Such a change could not be made if we require servers to >>>> error where the criticality is not TRUE. >> >>Oops. I notice I forgot to answer that: >> >>In terms of the current definition of criticality, this gives the >>control different semantics. > > By current, do you mean RFC 2251 or [Protocol]. I mean RFC 2251. It says the definition of a control includes: - whether the control is always noncritical, always critical, or critical at the client's option, To my eyes, this means that setting the control wrong is a user error. Good quality servers SHOULD reject such user errors, except when that gets too hairy or cumbersome to implement. I can see that you can instead interpret that wording alone as 'the value of the criticality is as specified regardless of what is sent over the protocol', but a few paragraphs above the RFC describes how the server must act on the criticality _field_. The 'field' refers clearly to the criticality protocol element. BTW, I note Jim has updated the text I quoted from rfc2251 to match that. > [Protocol] is > certainly specifying different criticality semantics than RFC 2251. > I argue that the change is inappropriate and problematic. Well, we too argue for changes from RFC 2251, which the other of us considers problematic... > Anyways, when we say 'control semantics', there two portions: > that defined by the "core" protocol specification and that > defined by the extension specification (which are associated > with the the controlType and associated controlValue). We > call this extension specification the "control specification". > That might be part of the problem. > > The extension specification should not overload or otherwise > alter the criticality semantics specified by "core" protocol > specification. Yes, I said I agree. My original suggestion - which Jim adopted - was bad, and so was my compromise suggestion. So in the protocol-20 description of a control specification: - whether the criticality field should be always set to TRUE, always set to FALSE, or sender's choice, I agree completely that far (and want to go further), but the following should be deleted: and server behavior when constraints of this nature are violated, >>If there is a need to change this, then >>the semantics of the control as currently defined is flawed. One should >>define a new and correct control instead, just as one should usually do >>instead of changing the semantics of a control in any other major way. > > Any decisions regarding versioning should considered as part > of whatever process of which the technical specification is > being maintained under. Note our standards process certainly > allows changes, even major ones, to be made without versioning > changes (if that is deemed appropriate by the community). > I believe it is quite common practice to defer such decisions > to the community most effected by the change and to a time > in which the (extension) specification is being revised. Well, true. I should have said, one should _normally_ define a new control. A major change in semantics is usually a bad idea, and should be considered very carefully. > I can certainly thing of cases where such a change would be > quite appropriate, for example, where the change is due more > to applicability of the extension than to alter the semantics > of the controlType and associated controlValue. My point here is that a change in specified criticality _is_ a change of semantics, and quite a major one in my opinion. The choice of whether to change the control or create a new one should be seen in that light. >>> I offer the the following replacement text: >>> - guidance as to what value should be provided for the criticality >>> field, >> >>Which even removes existing servers' license from rfc2251 to treat >>wrong criticality as an error. Please, no. > > I don't believe the text I offerred says anything about how servers > are to treat the criticality value. However, given the history > of control designers and implementors in this area, clarification > (as I offerred) would be wise. Huh? The original rfc2251 text, quoted at the top of this message, says - or can be interpreted to say, take your pick - that supplying another criticality is a user error. Your replacement text above does not in any way say that, so I don't see how the server can be allowed to treat it as an error. OTOH, your following text does give a useful clarification: >>> (the processing semantics of the criticality field, defined above, >>> should not be altered in any way by the control specification) -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 10:46:25 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 KAA07678 for ; Fri, 9 Jan 2004 10:46:24 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08Kp4ra017907; Thu, 8 Jan 2004 20:53:17 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i08Klgnr017773; Thu, 8 Jan 2004 20:47: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); Thu, 8 Jan 2004 20:47:42 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08KkdrY017712; Thu, 8 Jan 2004 20:46:39 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 1Aeh35-0004L9-Ng; Thu, 08 Jan 2004 21:46:35 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1Aeh33-0005tp-NC; Thu, 08 Jan 2004 21:46:33 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1Aeh32-00073n-00; Thu, 8 Jan 2004 21:46:32 +0100 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: names of RFC references (was: models-09 comments) In-Reply-To: <6.0.0.22.0.20040107105127.041f4858@127.0.0.1> References: <6.0.0.22.0.20031224110949.041efa60@127.0.0.1> <6.0.0.22.0.20040107105127.041f4858@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 8 Jan 2004 21:46:32 +0100 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=-4.9, required 12, BAYES_00 -4.90) 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 09:39 AM 1/7/2004, Hallvard B Furuseth wrote: > >> It would be nice if the LDAPbis documents had more or less >> the same reference names for the same documents, at least >> for references to LDAPbis documents. > > Yes. I hope we can leave it to the Editors to determine > exactly what LDAPBIS style is. Yes, I'd have posted this to the ietf-ldapbis-editors mailinglist if it existed:-) >> I'll post a list of differences between reference names is >> anyone is interested. > > Pointing out differences in style (where it matters) is > useful. I don't know what of this matters, but: Reference name styles: [BCP64bis], [LDAPDN], [LDAPURL], [Models], [Roadmap], [Schema], [Strprep] use document numbers: [RFC2234], [X.690]. [Protocol] uses descriptive names: [ABNF], [BER]. [AuthMeth] prefers document numbers, but also has [ABNF] and [UTF-8]. [Filters] uses document numbers for RFCs, but also has [ASN.1]. [Syntaxes] uses descriptive names, except it also needs names like [BCP64], [RFC2256] for older documents. Nobody call [X.500], [T.50] & co anything interesting:-) [Syntaxes] and partly [Schema] use uppercased descriptive names for internet-drafts and RFCs. The other documents do not. Name conflict: [Filters] calls X.690 '[ASN.1]', while [Protocol] and [Syntaxes] call X.680 '[ASN.1]'. That is confusing. I suggest [Filters] calls X.690 [BER], as [Protocol] and [Syntaxes] do. URL styles: [LDAPDN] uses the approximate URL . [BCP64bis] only refers to the web site for the registry (outside a reference). URLs in other places, including IANA URLs, are complete. Other details: The [UTF-8] or [UTF8] reference is outdated in many drafts. It is now an RFC, not an internet-draft: Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63 and RFC 3629, November 2003. Reference descriptions in [LDAPURL], [Filters] and partly [AuthMeth] are not indented out from the reference names, which makes searching for a reference slower. Some reference names are also descriptive words in the text, which will be lost if the reference is renamed. E.g. the phrases '[UTF-8] encoded' in [AuthMeth] and '[TLS]-protected' in [Protocol]. I'll scan for more if you are interested. The reference name [BCP64bis] will have to be renamed, since the name implies an unfinished document. Hopefully it will be finished someday:-) -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 10:46:26 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 KAA07699 for ; Fri, 9 Jan 2004 10:46:25 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08KR6to014344; Thu, 8 Jan 2004 20:38:17 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i08KNlIG014034; Thu, 8 Jan 2004 20:23:47 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, 8 Jan 2004 20:23:47 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08KNPrY014006 for ; Thu, 8 Jan 2004 20:23: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.9) with ESMTP id i08KNMu0096569; Thu, 8 Jan 2004 20:23:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040108112609.042259e8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 08 Jan 2004 12:23:03 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Protocol: control specifications. Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.0.22.0.20040106081000.043e87c8@127.0.0.1> <6.0.0.22.0.20040108082956.0271b498@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:11 AM 1/8/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> As I previously suggested: >>> Consider the need to update a specification from "clients MUST provide >>> criticality field of TRUE" to "clients SHOULD provide criticality field >>> of TRUE". Such a change could not be made if we require servers to >>> error where the criticality is not TRUE. > >Oops. I notice I forgot to answer that: > >In terms of the current definition of criticality, this gives the >control different semantics. By current, do you mean RFC 2251 or [Protocol]. [Protocol] is certainly specifying different criticality semantics than RFC 2251. I argue that the change is inappropriate and problematic. Anyways, when we say 'control semantics', there two portions: that defined by the "core" protocol specification and that defined by the extension specification (which are associated with the the controlType and associated controlValue). We call this extension specification the "control specification". That might be part of the problem. The extension specification should not overload or otherwise alter the criticality semantics specified by "core" protocol specification. That causes all kinds of problems, such as increasing the complexity of implementation (allowing controlType specific processing requirements associated to criticality field may be hard to deal with in some implementations). >If there is a need to change this, then >the semantics of the control as currently defined is flawed. One should >define a new and correct control instead, just as one should usually do >instead of changing the semantics of a control in any other major way. Any decisions regarding versioning should considered as part of whatever process of which the technical specification is being maintained under. Note our standards process certainly allows changes, even major ones, to be made without versioning changes (if that is deemed appropriate by the community). I believe it is quite common practice to defer such decisions to the community most effected by the change and to a time in which the (extension) specification is being revised. I can certainly thing of cases where such a change would be quite appropriate, for example, where the change is due more to applicability of the extension than to alter the semantics of the controlType and associated controlValue. >>> Control specifications should detail under what circumstances the >>> control generator should mark the control critical or non-critical. >>> However, they should not detail any semantics upon the implementation >>> processing that control as those are defined in the general protocol >>> semantics. > >About the specifications doing so, I agree. About [Protocol] doing so, >I still disagree, as you can see. > >> I offer the the following replacement text: >> - guidance as to what value should be provided for the criticality >> field, > >Which even removes existing servers' license from rfc2251 to treat >wrong criticality as an error. Please, no. I don't believe the text I offerred says anything about how servers are to treat the criticality value. However, given the history of control designers and implementors in this area, clarification (as I offerred) would be wise. >> and, given the past problems with control specifications >> adding semantics to the criticality flag, I suggest the >> following note be added as well to this bullet item: >> (the processing semantics of the criticality field, defined above, >> should not be altered in any way by the control specification) > >Fine. > >-- >Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 10:56: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 KAA08607 for ; Fri, 9 Jan 2004 10:56:11 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08Jd6tA008227; Thu, 8 Jan 2004 19:50:24 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i08JadNs008112; Thu, 8 Jan 2004 19:36: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); Thu, 8 Jan 2004 19:36:39 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08JZarY008021; Thu, 8 Jan 2004 19:35: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 1AefwL-0004Ti-TB; Thu, 08 Jan 2004 20:35:33 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AefwJ-0001ie-2e; Thu, 08 Jan 2004 20:35:31 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AefwI-0006td-00; Thu, 8 Jan 2004 20:35:30 +0100 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Protocol: attribute selection In-Reply-To: <6.0.0.22.0.20040108105153.02725ca0@127.0.0.1> References: <6.0.0.22.0.20040108105153.02725ca0@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 8 Jan 2004 20:35:30 +0100 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=-4.9, required 12, BAYES_00 -4.90) 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: >> - attributes: A list of the attributes to be returned from each >> entry which matches the search filter. LDAPString values of this >> field are constrained to the following Augmented Backus-Naur Form >> ([ABNF]): >> >> attributeSelection = noattrs / >> *( attributedescription / specialattr ) > > This means a value of the SEQUENCE may be the concatenation of zero > or more (attributedescription / specialattr) Another problem is that an 'AttributeSelection' (the ASN.1 type) can contain several 'attributeSelection's (the ABNF token), which is confusing at best: AttributeSelection ::= SEQUENCE OF selection LDAPString -- constrained to below The ABNF token should be named 'requestedAttribute', 'searchAttr' or something. The same goes for name 'selection' in ASN.1 above. It's the whole AttributeSelection which is a selection, not each attribute. > Aside from the above, the term "two special values" here is confusing > as in one case is an empty SEQUENCE and the is *any* SEQUENCE which > contains attrspec. I suggest s/two special values/three special cases/ > and then use bullet list (or numbered list) to enumerate each case. Good idea, but you forgot to do it:-) > There are two special values which may be used: an empty list with ^^^ ^^^^^^^^^^^^^^^^^^ There are three special values which may be used: -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 10:56:13 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 KAA08614 for ; Fri, 9 Jan 2004 10:56:12 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08JF2rk006216; Thu, 8 Jan 2004 19:18:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i08JCxF9006095; Thu, 8 Jan 2004 19:12: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); Thu, 8 Jan 2004 19:12:59 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08JBtrY005937; Thu, 8 Jan 2004 19:11:56 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 1AefZQ-0002MJ-2G; Thu, 08 Jan 2004 20:11:52 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AefZL-0007Zv-EU; Thu, 08 Jan 2004 20:11:47 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AefZK-0006q8-00; Thu, 8 Jan 2004 20:11:46 +0100 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: Re: Protocol: control specifications. In-Reply-To: <6.0.0.22.0.20040108082956.0271b498@127.0.0.1> References: <6.0.0.22.0.20040106081000.043e87c8@127.0.0.1> <6.0.0.22.0.20040108082956.0271b498@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 8 Jan 2004 20:11:46 +0100 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=-4.9, required 12, BAYES_00 -4.90) 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: > As I previously suggested: >> Consider the need to update a specification from "clients MUST provide >> criticality field of TRUE" to "clients SHOULD provide criticality field >> of TRUE". Such a change could not be made if we require servers to >> error where the criticality is not TRUE. Oops. I notice I forgot to answer that: In terms of the current definition of criticality, this gives the control different semantics. If there is a need to change this, then the semantics of the control as currently defined is flawed. One should define a new and correct control instead, just as one should usually do instead of changing the semantics of a control in any other major way. >> Control specifications should detail under what circumstances the >> control generator should mark the control critical or non-critical. >> However, they should not detail any semantics upon the implementation >> processing that control as those are defined in the general protocol >> semantics. About the specifications doing so, I agree. About [Protocol] doing so, I still disagree, as you can see. > I offer the the following replacement text: > - guidance as to what value should be provided for the criticality > field, Which even removes existing servers' license from rfc2251 to treat wrong criticality as an error. Please, no. > and, given the past problems with control specifications > adding semantics to the criticality flag, I suggest the > following note be added as well to this bullet item: > (the processing semantics of the criticality field, defined above, > should not be altered in any way by the control specification) Fine. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 10:57: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 KAA08894 for ; Fri, 9 Jan 2004 10:57:13 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08J38rc005336; Thu, 8 Jan 2004 19:04:44 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i08J16D8005166; Thu, 8 Jan 2004 19:01: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); Thu, 8 Jan 2004 19:01:06 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08J0jrY005126 for ; Thu, 8 Jan 2004 19:00:45 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.9) with ESMTP id i08J0iu0095588 for ; Thu, 8 Jan 2004 19:00:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040108105153.02725ca0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 08 Jan 2004 11:00:25 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Protocol: attribute selection 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: > - attributes: A list of the attributes to be returned from each > entry which matches the search filter. LDAPString values of this > field are constrained to the following Augmented Backus-Naur Form > ([ABNF]): > > attributeSelection = noattrs / > *( attributedescription / specialattr ) This means a value of the SEQUENCE may be the concatenation of zero or more (attributedescription / specialattr) (as opposed to the SEQUENCE having multiple values, each either an attributedescription or specialattr. Since each value is an attributeSelection, the list can contain multiple "*" and "1.1". Also, noattrs is now pretty special. I suggest the ABNF be replaced: attributeSelection = attributedescription / selectionspecial selectionspecial = noattrs / alluserattrs noattrs = %x31.2E.31 ; "1.1" alluserattrs = %x2A ; asterisk ("*") > There are two special values which may be used: an empty list with > no attributes, and the attribute description string "*". Aside from the above, the term "two special values" here is confusing as in one case is an empty SEQUENCE and the is *any* SEQUENCE which contains attrspec. I suggest s/two special values/three special cases/ and then use bullet list (or numbered list) to enumerate each case. E.g., There are two special values which may be used: an empty list with - an empty list, - a list containing "*" (and zero or more attributedescriptions), and - a list containing only "1.1". > Both of > these signify that all user attributes are to be returned. (The > "*" allows the client to request all user attributes in addition > to any specified operational attributes). An empty list requests the return of all user attributes. A list containing "*" requests all user attributes in addition to other listed (operational) attributes. A list containing only "1.1" indicates that no values are to be returned. (Note: if "1.1" is provided with other values, the "1.1" value is ignored.) > Attributes MUST NOT be named more than once in the list, and are s/Attributes/Attribute (or specials)/ but... This "MUST NOT" seems a bit too harsh. No real harm (except in bandwidth constrained environments) is caused by listing an attribute description (or special) multiple times. And this seems to prohibit requests which list the attribute multiple times by different attributedescription strings, e.g., once by each NAME and once by OID. I've seen many clients which ask for attribute by multiple descriptors, as by "cn" and "commonName". I suggest this reworded to say that redundant values are ignored. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 10:57:15 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 KAA08904 for ; Fri, 9 Jan 2004 10:57:14 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08Gj5sK094279; Thu, 8 Jan 2004 16:52:41 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i08GfUEr094111; Thu, 8 Jan 2004 16:41: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); Thu, 8 Jan 2004 16:41:30 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08Gf9rY094092 for ; Thu, 8 Jan 2004 16:41:09 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.9) with ESMTP id i08Gf8u0093952; Thu, 8 Jan 2004 16:41:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040108082956.0271b498@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 08 Jan 2004 08:40:48 -0800 To: Jim Sermersheim From: "Kurt D. Zeilenga" Subject: Re: Protocol: control specifications. Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.0.22.0.20040106081000.043e87c8@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: The current language regarding extension document guidance to criticality is still problematic: > - whether the criticality field should be always set to TRUE, always > set to FALSE, or sender's choice, and server behavior when > constraints of this nature are violated, As I previously suggested: > Consider the need to update a specification from "clients MUST provide > criticality field of TRUE" to "clients SHOULD provide criticality field > of TRUE". Such a change could not be made if we require servers to > error where the criticality is not TRUE. > > Control specifications should detail under what circumstances the > control generator should mark the control critical or non-critical. > However, they should not detail any semantics upon the implementation > processing that control as those are defined in the general protocol > semantics. I offer the the following replacement text: - guidance as to what value should be provided for the criticality field, and, given the past problems with control specifications adding semantics to the criticality flag, I suggest the following note be added as well to this bullet item: (the processing semantics of the criticality field, defined above, should not be altered in any way by the control specification) From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 11:30:54 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 KAA07562 for ; Fri, 9 Jan 2004 10:45:22 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08Md4ru027934; Thu, 8 Jan 2004 22:42:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i08MZDKh027711; Thu, 8 Jan 2004 22:35: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); Thu, 8 Jan 2004 22:35:13 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i08MY9rY027601; Thu, 8 Jan 2004 22:34:10 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 1Aeij8-0006YR-Dn; Thu, 08 Jan 2004 23:34:06 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1Aeij7-0004xW-7e; Thu, 08 Jan 2004 23:34:05 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1Aeij7-0007In-00; Thu, 8 Jan 2004 23:34:05 +0100 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: authmeth-09 comments In-Reply-To: <6.0.0.22.0.20040106120149.043c5350@127.0.0.1> References: <6.0.0.22.0.20040106120149.043c5350@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 8 Jan 2004 23:34:05 +0100 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=-4.9, required 12, BAYES_00 -4.90) 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:35 AM 1/3/2004, Hallvard B Furuseth wrote: >>authmeth-09 says: > We also should mention spoofing of a client to trick a server > into something. I don't understand. Clients relate to specific identified servers, but the reverse is not true. Servers relate to authenticated users and access control factors for the user and the connection. Those may include the DNS domain or IP address of the client, so we should mention that as a threat to servers as well as clients. Is that what you mean? Or if you mean client certificates - I'm not sure if a server may refuse access to clients without known certificates, but stealing a certificate seems in any case no different from stealing a password to me. > LDAP offers the following security mechanisms: > >>> (1) Client authentication by means of the Secure Authentication and >>> Security Layer (SASL) [SASL] mechanism set >> >>...or LDAP's simple password mechanism... >> >>(or maybe you should just delete the part about SASL and just say >>'Client authentication'.) > > I think this can be worded: > 1) Authentication by means of the Bind operation. The Bind > operation provides a simple method which supports anonymous, > unauthenticated, and authenticated with password mechanisms, > and the Secure Authentication and Security Layer (SASL) method > which supports a wide variety of authentication mechanisms. > The Bind operation may be extended to support additional > methods of authentication. I think that's too long and too detailed for this section, which is just a summary. It's already a problem that the draft keeps repeating itself. No need to add to that. Now that I think of it, I think this is enough: (1) Client authentication by various means, including a simple password mechanism and the Secure Authentication and Security Layer (SASL) [SASL] mechanism set, as well as unauthenticated users, >>> 3. Bind Operation >> >>> The new LDAP association >>> is established upon successful completion of the authentication >>> exchange. >> >>Remove 'successful'. A failed bind establishes a new association >>too. > > I think we need to careful here... > > Maybe something like: > The Bind operation defined in section 4.2 of [Protocol] allows > authentication information to be exchanged between the client and > server to establish a new LDAP association. Upon receipt of > a Bind request, the LDAP association moved to an anonymous > state and only upon successful completion of the authentication > exchange (and the Bind operation) is the association moved to > an authenticated state. Fine. (It's not entirely correct, since successful Bind can move the association to an anonymous state too, but other parts of the draft deal with that.) >>> 8. LDAP Association State Transition Tables >> >>The more I look at this section, the less I like it... How about >>moving it to a non-normative appendix? I *really* hope this section >>doesn't contain any information which must be read and can't be seen >>elsewhere in the draft. > > I concur that these tables should be moved to an Informative > appendix (or section). Implementators should not need to grok > these tables to properly implement the protocol. The tables > should be informative, provided to help the implementor to > understand the prose. So far, I find the prose far easier to track than the table, so my _real_ preference is for the table to be deleted. Roger didn't dignify that suggestion with a reply when he replied to the message suggesting that, though... OTOH, nobody spoke up and said 'yes, I find the table useful':-) -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 12:23: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 MAA14794 for ; Fri, 9 Jan 2004 12:23:33 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i09HLOra099886; Fri, 9 Jan 2004 17:22:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i09HJ8lE099797; Fri, 9 Jan 2004 17:19:08 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, 9 Jan 2004 17:19:08 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i09HHprY099682; Fri, 9 Jan 2004 17:17:52 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 1Af0Ga-00005V-Hz; Fri, 09 Jan 2004 18:17:48 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1Af0GT-0000lr-Us; Fri, 09 Jan 2004 18:17:41 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1Af0GT-0002J8-00; Fri, 9 Jan 2004 18:17:41 +0100 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: Re: Protocol: control specifications. In-Reply-To: <6.0.0.22.0.20040108134903.0423dd10@127.0.0.1> References: <6.0.0.22.0.20040106081000.043e87c8@127.0.0.1> <6.0.0.22.0.20040108082956.0271b498@127.0.0.1> <6.0.0.22.0.20040108112609.042259e8@127.0.0.1> <6.0.0.22.0.20040108134903.0423dd10@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 9 Jan 2004 18:17:41 +0100 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=-4.9, required 12, BAYES_00 -4.90) 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: > Though I think you might have misunderstand some of my points, > I likely some of yours, and that we're not exactly seeing eye to > eye on the "why", I think we've converging on acceptable > replacement text. I don't:-( > Here is my latest offering: > > - guidance as to what value the sender should provide for the > criticality field That still has the problem that it removes the server's license to treat the 'unadvised' criticality as an error. In that, it goes exactly in the opposite direction of what I want. My preference is this text from protocol-19: - whether the criticality field should be always set to TRUE, always set to FALSE, or sender's choice Failing that, my second suggestion would be to revert to RFC 2251's text: - whether the control is always non critical, always critical, or optionally critical, which at least won't introduce any incompatibility. (Or s/optionally critical/sender's choice/, I liked the new phrase better.) Also, I'm still hoping for: If the criticality field for a supported control does not match the value required by the control specification, the server SHOULD NOT perform the operation, but instead return protocolError in the resultCode if the operation has a response. or s/required by/in/ if we use the RFC 2251 text above. > (note: the processing semantics of the > criticality field, which are defined above, should not be > altered in any way by the control's specification), I'd strengthen that: s/should not/can not/. Remove '(note: )'. (Yes, I know. Nobody is as fanatic as a convert:-) -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 13:32: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 NAA22991 for ; Fri, 9 Jan 2004 13:32:21 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i09ILKsO005922; Fri, 9 Jan 2004 18:30:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i09IFbCn005694; Fri, 9 Jan 2004 18:15:37 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, 9 Jan 2004 18:15:37 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i09IFGrY005681 for ; Fri, 9 Jan 2004 18:15: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.9) with ESMTP id i09IFEu0009206; Fri, 9 Jan 2004 18:15:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040109093219.041bf640@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 09 Jan 2004 10:15:08 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Protocol: control specifications. Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.0.22.0.20040106081000.043e87c8@127.0.0.1> <6.0.0.22.0.20040108082956.0271b498@127.0.0.1> <6.0.0.22.0.20040108112609.042259e8@127.0.0.1> <6.0.0.22.0.20040108134903.0423dd10@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: Hallvard, I believe you are missing a few aspects of the RFC 2251 text: This document does not define any controls. Controls may be defined in other documents. The definition of a control consists of: ... - whether the control is always noncritical, always critical, or critical at the client's option, Note that the bullet is part of a statement of practices to be followed in writing extension documents. That is, this bullet is not stating a requirement upon implementations of LDAP (including those implement any control). Someone implementing LDAP can completely ignore this paragraph as it simply does not pertain to implementations. Second, your interpretation of this text as an implementation requirement is counter to the previous text detailing the protocol: The criticality field is either TRUE or FALSE. If the server recognizes the control type and it is appropriate for the operation, the server will make use of the control when performing the operation. This text, as been interpreted by most implementors as meaning that, regardless of the value of criticality presented, a server is to make use of a control when they recognize the control type and that control type is appropriate for the operation. You suggested text is also problematic for a number of reasons: 1) servers don't, as far as I know, don't behave in the manner you describe, 2) the suggestion is counter to "be liberal in what they accept" principle, and 3) the suggestion hinders changes to guidance given (based upon operational experiences or otherwise). Your primary argument to make the change is that servers should check user input. I think it can be reasonable be argued that checking user input in this case is primarily the responsibility of the client (under the clients "should be strict in what they send" principle). I oppose the direction you suggest we take. A few additional comments below. At 09:17 AM 1/9/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> Though I think you might have misunderstand some of my points, >> I likely some of yours, and that we're not exactly seeing eye to >> eye on the "why", I think we've converging on acceptable >> replacement text. > >I don't:-( > >> Here is my latest offering: >> >> - guidance as to what value the sender should provide for the >> criticality field > >That still has the problem that it removes the server's license to >treat the 'unadvised' criticality as an error. Again, the RFC 2251 text which this replaced does not specify any implementation "license" as it simply did not pertain to implementors. Was a profiling statement for extension specifications, as is the replacement text. >In that, it goes >exactly in the opposite direction of what I want. My preference is >this text from protocol-19: > > - whether the criticality field should be always set to TRUE, > always set to FALSE, or sender's choice As previously noted, this language could be viewed as limiting the kinds of guidance which an extension specification could give. For instance, it does not allow an extension from saying: Criticality should be TRUE when X is TRUE. or Criticality should be FALSE when Y is FALSE. The intent of this original text was to encourage extension authors to discuss the circumstances of when particular criticality values are appropriate. The text I proposes attempts clarify the text to that intent while removing ambiguity that some have raised that the text could be viewed as stating an implementation requirement (instead of a document profile). >Failing that, my second suggestion would be to revert to RFC 2251's >text: > > - whether the control is always non critical, always critical, or > optionally critical, > >which at least won't introduce any incompatibility. >(Or s/optionally critical/sender's choice/, I liked the new phrase >better.) The original text has most of the same problems as your suggested text. >Also, I'm still hoping for: > > If the criticality field for a supported control does not match > the value required by the control specification, the server SHOULD > NOT perform the operation, but instead return protocolError in the > resultCode if the operation has a response. It would be inappropriate to make such a statement in text intended to detail a document profile. When considers this as an addition to the technical specification, absent the document profile, it becomes clear that you are asking for a change in protocol semantics. >or s/required by/in/ if we use the RFC 2251 text above. > >> (note: the processing semantics of the >> criticality field, which are defined above, should not be >> altered in any way by the control's specification), > >I'd strengthen that: s/should not/can not/. Remove '(note: )'. >(Yes, I know. Nobody is as fanatic as a convert:-) I think it clearer as suggested. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 16:00: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 QAA15052 for ; Fri, 9 Jan 2004 16:00:26 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i09Kvera015239; Fri, 9 Jan 2004 20:58:16 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i09Ku1Uw015192; Fri, 9 Jan 2004 20:56: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); Fri, 9 Jan 2004 20:56:01 +0000 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i09KtdrY015171 for ; Fri, 9 Jan 2004 20:55:39 GMT (envelope-from jmcmeek@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i09KtI9n498678 for ; Fri, 9 Jan 2004 15:55:18 -0500 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i09KtHqa115792 for ; Fri, 9 Jan 2004 15:55:18 -0500 In-Reply-To: <6.0.0.22.0.20040109093219.041bf640@127.0.0.1> Subject: Re: Protocol: control specifications. To: ietf-ldapbis@OpenLDAP.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Fri, 9 Jan 2004 14:55:16 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at 01/09/2004 02:55:17 PM 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: No recommendation - just some observations... X.511 has a similar notion of recommended criticality. And it is just that, a recommendation. As far as I could tell, doing the equivalent of modifyDN with new superior is done via an extension that the DUA may, or may not mark as critical. If the DUA does not mark this as critical and it goes to a DSA that does not support this extension, the result will most likely not be what was intended. If the operation specifies a new RDN and new superior, the result could be that the entry is renamed but left with the same superior. Weird, but... I'm not saying that this doesn't have any risks. I sympathize with Hallvard's view that we ought to leave leeway for a server to discourage such risky practices. I'm tempted to suggest "A server MAY reject a control that has a criticality that violates the recommended criticality defined in the control specification." That doesn't introduce an incompatibility with older servers, and it gives leeway to implementations with Hallvard's perspective on control criticality. However, it does introduce the possibility that a [popular or critical] application that works great with servers that do not enforce recommended criticality will not work with some servers. You're going to make someone unhappy either way -- the user whose application is doing bad things because it didn't specify the proper criticality, or the user whose application works on other vendor's servers, but not on his. John McMeeking owner-ietf-ldapbis@OpenLDAP.org wrote on 01/09/2004 12:15:08 PM: > Hallvard, > > I believe you are missing a few aspects of the RFC 2251 text: > This document does not define any controls. Controls may be defined > in other documents. The definition of a control consists of: > ... > - whether the control is always noncritical, always critical, or > critical at the client's option, > > Note that the bullet is part of a statement of practices to be followed > in writing extension documents. That is, this bullet is not stating a > requirement upon implementations of LDAP (including those implement > any control). Someone implementing LDAP can completely ignore this > paragraph as it simply does not pertain to implementations. > > Second, your interpretation of this text as an implementation requirement > is counter to the previous text detailing the protocol: > The criticality field is either TRUE or FALSE. > > If the server recognizes the control type and it is appropriate for > the operation, the server will make use of the control when > performing the operation. > > This text, as been interpreted by most implementors as meaning that, > regardless of the value of criticality presented, a server is to make use > of a control when they recognize the control type and that control type > is appropriate for the operation. > > You suggested text is also problematic for a number of reasons: > 1) servers don't, as far as I know, don't behave in the manner you > describe, > 2) the suggestion is counter to "be liberal in what > they accept" principle, and > 3) the suggestion hinders changes to guidance given (based upon > operational experiences or otherwise). > > Your primary argument to make the change is that servers should check > user input. I think it can be reasonable be argued that checking user > input in this case is primarily the responsibility of the client (under > the clients "should be strict in what they send" principle). > > I oppose the direction you suggest we take. > > A few additional comments below. > > At 09:17 AM 1/9/2004, Hallvard B Furuseth wrote: > >Kurt D. Zeilenga writes: > >> Though I think you might have misunderstand some of my points, > >> I likely some of yours, and that we're not exactly seeing eye to > >> eye on the "why", I think we've converging on acceptable > >> replacement text. > > > >I don't:-( > > > >> Here is my latest offering: > >> > >> - guidance as to what value the sender should provide for the > >> criticality field > > > >That still has the problem that it removes the server's license to > >treat the 'unadvised' criticality as an error. > > Again, the RFC 2251 text which this replaced does not specify any > implementation "license" as it simply did not pertain to implementors. > Was a profiling statement for extension specifications, as is the > replacement text. > > >In that, it goes > >exactly in the opposite direction of what I want. My preference is > >this text from protocol-19: > > > > - whether the criticality field should be always set to TRUE, > > always set to FALSE, or sender's choice > > As previously noted, this language could be viewed as limiting the > kinds of guidance which an extension specification could give. For > instance, it does not allow an extension from saying: > Criticality should be TRUE when X is TRUE. > or > Criticality should be FALSE when Y is FALSE. > > The intent of this original text was to encourage extension authors > to discuss the circumstances of when particular criticality values > are appropriate. The text I proposes attempts clarify the text > to that intent while removing ambiguity that some have raised that > the text could be viewed as stating an implementation requirement > (instead of a document profile). > > >Failing that, my second suggestion would be to revert to RFC 2251's > >text: > > > > - whether the control is always non critical, always critical, or > > optionally critical, > > > >which at least won't introduce any incompatibility. > >(Or s/optionally critical/sender's choice/, I liked the new phrase > >better.) > > The original text has most of the same problems as your suggested > text. > > >Also, I'm still hoping for: > > > > If the criticality field for a supported control does not match > > the value required by the control specification, the server SHOULD > > NOT perform the operation, but instead return protocolError in the > > resultCode if the operation has a response. > > It would be inappropriate to make such a statement in text intended > to detail a document profile. When considers this as an addition > to the technical specification, absent the document profile, it becomes > clear that you are asking for a change in protocol semantics. > > >or s/required by/in/ if we use the RFC 2251 text above. > > > >> (note: the processing semantics of the > >> criticality field, which are defined above, should not be > >> altered in any way by the control's specification), > > > >I'd strengthen that: s/should not/can not/. Remove '(note: )'. > >(Yes, I know. Nobody is as fanatic as a convert:-) > > I think it clearer as suggested. > > Kurt > From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 16:18: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 QAA15809 for ; Fri, 9 Jan 2004 16:18:38 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i09L9Ds2015805; Fri, 9 Jan 2004 21:14:58 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i09L6COZ015709; Fri, 9 Jan 2004 21:06: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, 9 Jan 2004 21:06:12 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i09L56rY015606; Fri, 9 Jan 2004 21:05:10 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 1Af3oV-0002lp-Cp; Fri, 09 Jan 2004 22:05:03 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1Af3oT-0008Sb-LS; Fri, 09 Jan 2004 22:05:01 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1Af3oT-0002qu-00; Fri, 9 Jan 2004 22:05:01 +0100 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: Re: Protocol: control specifications. In-Reply-To: <6.0.0.22.0.20040109093219.041bf640@127.0.0.1> References: <6.0.0.22.0.20040106081000.043e87c8@127.0.0.1> <6.0.0.22.0.20040108082956.0271b498@127.0.0.1> <6.0.0.22.0.20040108112609.042259e8@127.0.0.1> <6.0.0.22.0.20040108134903.0423dd10@127.0.0.1> <6.0.0.22.0.20040109093219.041bf640@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 9 Jan 2004 22:05:01 +0100 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=-4.9, required 12, BAYES_00 -4.90) 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, I'm suddenly wondering if I've misunderstood you completely, and if so I don't know where. So I need a bit of clarification before replying to your latest message: You are saying, I think, that current practice is for most servers to ignore the criticality protocol field when the criticality is given by the control spec. Yet you suggest that control specs should no longer say what the criticality _is_, they should merely give guidance to what the field should be _set_ to. Thus, there will no longer be a criticality in the control spec which servers can follow, so they all MUST change from current practice to always obeying the protocol field. Yet one of your arguments against my suggestion is that it changes current practice. My suggested change is merely a SHOULD. Servers may ignore it and keep doing what they do now. Or if you disagree about that, I may have made a mistake and should modify my suggestion, but we can get back to that later. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 19:37:52 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 TAA01803 for ; Fri, 9 Jan 2004 19:37:51 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0A0XRra028760; Sat, 10 Jan 2004 00:34:58 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0A0UqBX028573; Sat, 10 Jan 2004 00:30:52 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, 10 Jan 2004 00:30:52 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0A0UVrY028518 for ; Sat, 10 Jan 2004 00:30: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.9) with ESMTP id i0A0USu0013330; Sat, 10 Jan 2004 00:30:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040109150840.041a8298@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 09 Jan 2004 16:30:22 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Protocol: control specifications. Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.0.22.0.20040106081000.043e87c8@127.0.0.1> <6.0.0.22.0.20040108082956.0271b498@127.0.0.1> <6.0.0.22.0.20040108112609.042259e8@127.0.0.1> <6.0.0.22.0.20040108134903.0423dd10@127.0.0.1> <6.0.0.22.0.20040109093219.041bf640@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:05 PM 1/9/2004, Hallvard B Furuseth wrote: >Kurt, I'm suddenly wondering if I've misunderstood you completely, >and if so I don't know where. So I need a bit of clarification >before replying to your latest message: After a couple of draft responses, I've concluded that there isn't a good way to clarify my reply without taking a (big) step back. LDAP provides, in controls, a mechanism for extending the semantics of an existing operation. The extended semantics are associated with the type of control (an OID) and associated type-specific data (an octet string). This mechanism also provides a facility by which a client can indicate to the server that the extended semantics associated with any particular control instance is critical. That is, by marking a control critical, the client demands that server not process the operation if it cannot make use of the control. Criticality was intended to be in the eye of the client (based upon user input and/or guidance in the specification of the particular control), not the server. Also, the criticality field was not intended to have any other semantic. That is, the performance of the operation as extended by the control is not intended to be dependent on the criticality value. I believe that most implementations behave as I describe above, which I content is as intended. I also believe this section needs clarification to ensure future clients and servers implement the technical specification in a manner consistent with today's implementations. My suggestions are intended to do this. I object to your suggestions are numerous grounds: 1) that wasn't what was intended, 2) that isn't what is implemented, 3) that violates interoperability principles on which Internet is built on (be strict in what you send, be liberal in what you accept), 4) that hinders subsequent revision of extension specifications, and 5) it will limit how one control could extend an operation extended by other control(s). (The last one is new. For now, I'll leave it as something for you and others to think about.) Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 20:53:27 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 UAA04957 for ; Fri, 9 Jan 2004 20:53:26 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0A1jMsM033936; Sat, 10 Jan 2004 01:51:36 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0A1gnoY033804; Sat, 10 Jan 2004 01:42: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); Sat, 10 Jan 2004 01:42:49 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0A1fjrY033708; Sat, 10 Jan 2004 01:41:45 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 09 Jan 2004 18:41:31 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 09 Jan 2004 18:41:07 -0700 From: "Jim Sermersheim" To: , Cc: Subject: Re: Protocol: control specifications. Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartD38D1E23.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. --=__PartD38D1E23.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit So, what I think is being asked is this: If a control specification states: The criticality of the XYZ control is always TRUE, and some client sends the XYZ control with criticality of FALSE, what is the server to do? Similar but more explicitly, if the control specification says: The criticality of the XYZ control SHALL be TRUE, and some client sends the XYZ control with criticality of FALSE, what is the server to do? If in either of these scenarios, it seems correct for the server to always fail the operation (in order to ensure some aspect of interoperability), then somewhere there should be language to that effect. Personally, I think such language would belong in the specific control specification, and likely, the appropriate resultCode is protocolError. On the other hand, if it always inappropriate for any specification to mandate behavior when a client violates an imperative regarding criticality, then I guess it's always server-defined. And on yet some other hand, maybe it is inappropriate for a control specification to use imperatives. I think that's a discussion to be had on its own. Certainly RFC 2251 reads as though the control specifications will contain imperatives (implied through the term "is always"). Jim >>> "Kurt D. Zeilenga" 1/9/04 5:30:22 PM >>> At 01:05 PM 1/9/2004, Hallvard B Furuseth wrote: >Kurt, I'm suddenly wondering if I've misunderstood you completely, >and if so I don't know where. So I need a bit of clarification >before replying to your latest message: After a couple of draft responses, I've concluded that there isn't a good way to clarify my reply without taking a (big) step back. LDAP provides, in controls, a mechanism for extending the semantics of an existing operation. The extended semantics are associated with the type of control (an OID) and associated type-specific data (an octet string). This mechanism also provides a facility by which a client can indicate to the server that the extended semantics associated with any particular control instance is critical. That is, by marking a control critical, the client demands that server not process the operation if it cannot make use of the control. Criticality was intended to be in the eye of the client (based upon user input and/or guidance in the specification of the particular control), not the server. Also, the criticality field was not intended to have any other semantic. That is, the performance of the operation as extended by the control is not intended to be dependent on the criticality value. I believe that most implementations behave as I describe above, which I content is as intended. I also believe this section needs clarification to ensure future clients and servers implement the technical specification in a manner consistent with today's implementations. My suggestions are intended to do this. I object to your suggestions are numerous grounds: 1) that wasn't what was intended, 2) that isn't what is implemented, 3) that violates interoperability principles on which Internet is built on (be strict in what you send, be liberal in what you accept), 4) that hinders subsequent revision of extension specifications, and 5) it will limit how one control could extend an operation extended by other control(s). (The last one is new. For now, I'll leave it as something for you and others to think about.) Kurt --=__PartD38D1E23.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
So, what I think is being asked is this:
 
If a control specification states: The criticality of the XYZ control is always TRUE, and some client sends the XYZ control with criticality of FALSE, what is the server to do?
 
Similar but more explicitly, if the control specification says: The criticality of the XYZ control SHALL be TRUE, and some client sends the XYZ control with criticality of FALSE, what is the server to do?
 
If in either of these scenarios, it seems correct for the server to always fail the operation (in order to ensure some aspect of interoperability), then somewhere there should be language to that effect. Personally, I think such language would belong in the specific control specification, and likely, the appropriate resultCode is protocolError.
 
On the other hand, if it always inappropriate for any specification to mandate behavior when a client violates an imperative regarding criticality, then I guess it's always server-defined.
 
And on yet some other hand, maybe it is inappropriate for a control specification to use imperatives. I think that's a discussion to be had on its own. Certainly RFC 2251 reads as though the control specifications will contain imperatives (implied through the term "is always").
 
Jim
 
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 1/9/04 5:30:22 PM >>>
At 01:05 PM 1/9/2004, Hallvard B Furuseth wrote:
>Kurt, I'm suddenly wondering if I've misunderstood you completely,
>and if so I don't know where. So I need a bit of clarification
>before replying to your latest message:

After a couple of draft responses, I've concluded that there
isn't a good way to clarify my reply without taking a (big)
step back.

LDAP provides, in controls, a mechanism for extending the
semantics of an existing operation. The extended semantics
are associated with the type of control (an OID) and
associated type-specific data (an octet string).

This mechanism also provides a facility by which a client
can indicate to the server that the extended semantics
associated with any particular control instance is critical.
That is, by marking a control critical, the client demands
that server not proc! ess the operation if it cannot make
use of the control.

Criticality was intended to be in the eye of the client
(based upon user input and/or guidance in the specification
of the particular control), not the server.

Also, the criticality field was not intended to have any
other semantic. That is, the performance of the operation
as extended by the control is not intended to be dependent
on the criticality value.

I believe that most implementations behave as I describe
above, which I content is as intended. I also believe
this section needs clarification to ensure future clients
and servers implement the technical specification in
a manner consistent with today's implementations. My
suggestions are intended to do this.

I object to your suggestions are numerous grounds:
1) that wasn't what was intended,
2) that isn't what is implemented,
3) that violates interoperability principles on
which Internet is b! uilt on (be strict in what you
send, be liberal in what you! accept) ,
4) that hinders subsequent revision of extension
specifications, and
5) it will limit how one control could extend
an operation extended by other control(s).

(The last one is new. For now, I'll leave it as something
for you and others to think about.)

Kurt

--=__PartD38D1E23.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 23:05: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 XAA08302 for ; Fri, 9 Jan 2004 23:05:58 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0A43Eri041315; Sat, 10 Jan 2004 04:03:37 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0A3wxNd040670; Sat, 10 Jan 2004 03:58: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); Sat, 10 Jan 2004 03:58:59 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0A3wcrY040621 for ; Sat, 10 Jan 2004 03:58: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.9) with ESMTP id i0A3wau0015855; Sat, 10 Jan 2004 03:58:36 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040109190833.042d8488@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 09 Jan 2004 19:58:29 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Protocol: control specifications. 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 05:41 PM 1/9/2004, Jim Sermersheim wrote: >So, what I think is being asked is this: > >If a control specification states: The criticality of the XYZ control is always TRUE, and some client sends the XYZ control with criticality of FALSE, what is the server to do? If the server recognizes the control type and it is appropriate for the operation, the server will make use of the control when performing the operation. otherwise, the control is to be ignored. >Similar but more explicitly, if the control specification says: The criticality of the XYZ control SHALL be TRUE, and some client sends the XYZ control with criticality of FALSE, what is the server to do? If the server recognizes the control type and it is appropriate for the operation, the server will make use of the control when performing the operation. otherwise, the unsupportedCriticalExtension is to returned. >If in either of these scenarios, it seems correct for the server to always fail the operation (in order to ensure some aspect of interoperability), then somewhere there should be language to that effect. Exactly, if RFC 2251 had intended this, the text: If the server recognizes the control type and it is appropriate for the operation, the server will make use of the control when performing the operation. would have be qualified as only apply when the criticality had a value consistent with the control's specification. >Personally, I think such language would belong in the specific control specification, and likely, the appropriate resultCode is protocolError. Authors of such documents should be very careful in including such language as it likely to cause far more problems that it will ever solve. (As many of us have learned already.) In particular, one should consider whether there will ever be a need to change that language and what impact such a change would have on forwards/backwards compatibility. Also, one should not assume that such a check would be trivial extension to the servers existing code handling criticality checks (given that the check is likely in a different code path). (Yada, yada, yada.) >On the other hand, if it always inappropriate for any specification to mandate behavior when a client violates an imperative regarding criticality, then I guess it's always server-defined. My suggestion is worded as a strong recommendation, not a mandate. It's also worded as a requirement upon the document defining the control, not as a restriction upon extent of which control can extend the operation. >And on yet some other hand, maybe it is inappropriate for a control specification to use imperatives. I think that's a discussion to be had on its own. Certainly RFC 2251 reads as though the control specifications will contain imperatives (implied through the term "is always"). I believe it is assumed that control specifications will use imperatives where appropriate. > >Jim > >>>> "Kurt D. Zeilenga" 1/9/04 5:30:22 PM >>> >At 01:05 PM 1/9/2004, Hallvard B Furuseth wrote: >>Kurt, I'm suddenly wondering if I've misunderstood you completely, >>and if so I don't know where. So I need a bit of clarification >>before replying to your latest message: > >After a couple of draft responses, I've concluded that there >isn't a good way to clarify my reply without taking a (big) >step back. > >LDAP provides, in controls, a mechanism for extending the >semantics of an existing operation. The extended semantics >are associated with the type of control (an OID) and >associated type-specific data (an octet string). > >This mechanism also provides a facility by which a client >can indicate to the server that the extended semantics >associated with any particular control instance is critical. >That is, by marking a control critical, the client demands >that server not proc! ess the operation if it cannot make >use of the control. > >Criticality was intended to be in the eye of the client >(based upon user input and/or guidance in the specification >of the particular control), not the server. > >Also, the criticality field was not intended to have any >other semantic. That is, the performance of the operation >as extended by the control is not intended to be dependent >on the criticality value. > >I believe that most implementations behave as I describe >above, which I content is as intended. I also believe >this section needs clarification to ensure future clients >and servers implement the technical specification in >a manner consistent with today's implementations. My >suggestions are intended to do this. > >I object to your suggestions are numerous grounds: >1) that wasn't what was intended, >2) that isn't what is implemented, >3) that violates interoperability principles on >which Internet is b! uilt on (be strict in what you >send, be liberal in what you! accept) , >4) that hinders subsequent revision of extension >specifications, and >5) it will limit how one control could extend >an operation extended by other control(s). > >(The last one is new. For now, I'll leave it as something >for you and others to think about.) > >Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 9 23:23: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 XAA08847 for ; Fri, 9 Jan 2004 23:23:34 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0A4LEra046001; Sat, 10 Jan 2004 04:22:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0A4FQiH045602; Sat, 10 Jan 2004 04:15: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, 10 Jan 2004 04:15:26 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0A4F5rY042935 for ; Sat, 10 Jan 2004 04:15: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.9) with ESMTP id i0A4F4u0016087; Sat, 10 Jan 2004 04:15:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040109200051.042f0f18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 09 Jan 2004 20:11:02 -0800 To: John McMeeking From: "Kurt D. Zeilenga" Subject: Re: Protocol: control specifications. Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.0.22.0.20040109093219.041bf640@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 12:55 PM 1/9/2004, John McMeeking wrote: >X.511 has a similar notion of recommended criticality. Similar or same? Given that one of planned uses of LDAP Controls was to provide a mechanism in which additional X.511 semantics could be added to LDAP in a manner which would facilitate implementation of LDAP<->X.511 gateways, I think the intent was for the criticality semantics to be the same. X.511: The criticalExtensions component provides a mechanism to list a set of extensions which are critical to the performance of a Directory operation. If the originator of the extended operation wishes to indicate that the operation shall be performed with one or more extensions (i.e. that performing the operation without these extensions is not acceptable), it does so by setting the criticalExtensions bit(s) which corresponds to the extension(s). If the Directory, or some part of it, is unable to perform a critical extension it returns an indication of unavailableCriticalExtension (as a ServiceError or PartialOutcomeQualifier). If the Directory is unable to perform an extension which is not critical, it ignores the presence of the extension. Sounds the same to me. From owner-ietf-ldapbis@OpenLDAP.org Sun Jan 11 17:54: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 RAA19649 for ; Sun, 11 Jan 2004 17:54:39 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0BMptra086013; Sun, 11 Jan 2004 22:52:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0BMnSnR085966; Sun, 11 Jan 2004 22:49: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); Sun, 11 Jan 2004 22:49:28 +0000 Received: from adacel.com (gunsmoke.adacel.com.au [210.11.130.7]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0BMn5rY085922 for ; Sun, 11 Jan 2004 22:49:06 GMT (envelope-from mark.ennis@adacel.com) Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id ; Mon, 12 Jan 2004 09:40:22 +1100 Received: (qmail 22698 invoked from network); 11 Jan 2004 22:48:44 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 11 Jan 2004 22:48:44 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i0BMmhJ29668; Mon, 12 Jan 2004 09:48:44 +1100 Message-ID: <4001D2CA.7060904@adacel.com> Date: Mon, 12 Jan 2004 09:48:42 +1100 From: Mark Ennis User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jim Sermersheim , h.b.furuseth@usit.uio.no, ietf-ldapbis@OpenLDAP.org Subject: Re: Protocol: control specifications. References: <6.0.0.22.0.20040109190833.042d8488@127.0.0.1> In-Reply-To: <6.0.0.22.0.20040109190833.042d8488@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 I agree with Kurt that a server implementation should be flexible in what it receives. The criticality flag is not intended to check that client implementations are behaving correctly. It is a tool for clients to indicate whether they wish to be informed on whether extension behaviour is available or not. A control specification should only be recommending the setting of this flag to the client implementation. If a server supports a requested control, then the criticality flag is of no interest and should be ignored. If the server supports a requested control, but the client supplies the control for an inappropraite operation type, it should be ignored unless the control specification indicates a specific action in this case. - Mark Ennis. From owner-ietf-ldapbis@OpenLDAP.org Sun Jan 11 19:41:32 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 TAA24297 for ; Sun, 11 Jan 2004 19:41:26 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0C0dZra090397; Mon, 12 Jan 2004 00:39:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0C0Zx04090337; Mon, 12 Jan 2004 00:35: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); Mon, 12 Jan 2004 00:35:59 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0C0YprY090267; Mon, 12 Jan 2004 00:34:52 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 1Afq2a-00007P-7z; Mon, 12 Jan 2004 01:34:48 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1Afq2W-0001Hp-Fh; Mon, 12 Jan 2004 01:34:44 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1Afq2V-0002VV-00; Mon, 12 Jan 2004 01:34:43 +0100 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: Re: Protocol: control specifications. In-Reply-To: <6.0.0.22.0.20040109093219.041bf640@127.0.0.1> References: <6.0.0.22.0.20040106081000.043e87c8@127.0.0.1> <6.0.0.22.0.20040108082956.0271b498@127.0.0.1> <6.0.0.22.0.20040108112609.042259e8@127.0.0.1> <6.0.0.22.0.20040108134903.0423dd10@127.0.0.1> <6.0.0.22.0.20040109093219.041bf640@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 12 Jan 2004 01:34:43 +0100 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=-4.9, required 12, BAYES_00 -4.90) 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 believe this message answers the clarifying message as well as the one I'm replying to. Kurt D. Zeilenga writes: > Hallvard, > > I believe you are missing a few aspects of the RFC 2251 text: > This document does not define any controls. Controls may be defined > in other documents. The definition of a control consists of: > ... > - whether the control is always noncritical, always critical, or > critical at the client's option, > > Note that the bullet is part of a statement of practices to be followed > in writing extension documents. That is, this bullet is not stating a > requirement upon implementations of LDAP (including those implement > any control). Someone implementing LDAP can completely ignore this > paragraph as it simply does not pertain to implementations. Yes, of course. But that leads to control specifications which say that the criticality for a control is . What we are talking about is how to implement . And given that combined spec, and interpreting criticality in the text you quoted as the criticality protocol element and not the criticality given in the control spec (which seems the natural way to read rfc2251 to me, given the context of that text), it is a user error to provide the other criticality value. Which is why I at the very least want servers to continue to be allowed to return an error for it. > Second, your interpretation of this text as an implementation requirement > is counter to the previous text detailing the protocol: > The criticality field is either TRUE or FALSE. > > If the server recognizes the control type and it is appropriate for > the operation, the server will make use of the control when > performing the operation. That text says how to perform such an operation if it is performed at all. Then the RFC goes on to list, among other things, circumstances when _not_ to perform the operation. At least, that's how I'm reading it. > This text, as been interpreted by most implementors as meaning that, > regardless of the value of criticality presented, a server is to make use > of a control when they recognize the control type and that control type > is appropriate for the operation. Yes, I agree with that. We disagree about - whether or not to perform the operation at all in various circumstances, - how the various parties should get to participate in that decision: LDAP spec, control spec, server, and/or client, and - what it is desirable that implementors choose to do about it. > [Moving this part of your message further down - will need to > address a few other points first] > Your primary argument to make the change is that servers should check > user input. I think it can be reasonable be argued that checking user > input in this case is primarily the responsibility of the client (under > the clients "should be strict in what they send" principle). That helps, but I'm afraid s/user/user or client programmer/ in my arguments better expresses what I meant to say. It's a good point, though. A statement that clients SHOULD NOT (or MUST NOT) send controls with wrong criticality would help. However, that's incompatible with telling control specs to merely supply 'guidance' about what criticality to send, like you suggest. >At 09:17 AM 1/9/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: > >>> - guidance as to what value the sender should provide for the >>> criticality field >> >>That still has the problem that it removes the server's license to >>treat the 'unadvised' criticality as an error. > > Again, the RFC 2251 text which this replaced does not specify any > implementation "license" as it simply did not pertain to implementors. Again, the LDAP spec + such a control spec does. Or rather, can be interpreted to do. If you read it as, the control spec may say what the client SHALL set the criticality to, then it's a client error to set it differently. If you read it as saying what the criticality of the control as considered by the server is, then it is not a client error, but OTOH all the other text talks about how the server shall react not to the spec's value but the criticality _field_. Your proposal redefines what was previously client bugs - and potentially quite harmful ones - to be features. This solution does not appeal to me, to put it mildly. >> My preference is this text from protocol-19: >> >> - whether the criticality field should be always set to TRUE, >> always set to FALSE, or sender's choice > > As previously noted, this language could be viewed as limiting the > kinds of guidance which an extension specification could give. For > instance, it does not allow an extension from saying: > Criticality should be TRUE when X is TRUE. > or > Criticality should be FALSE when Y is FALSE. I must have missed that. I agree, allowing that is good. However, it can be done while retaining the spirit of the current text: - when to set the criticality field to TRUE, when to set it to FALSE, and when the sender may choose (Or if going back to the rfc2251 text, reword to not talk about 'setting' the 'field', so people may interpret it either way. But if you see no point in that, then I certainly prefer text based on the current [Protocol] text.) That should also take care of this point in your clarifying message, unless I've missed some implications of it: > 5) it will limit how one control could extend > an operation extended by other control(s). > The intent of this original text was to encourage extension authors > to discuss the circumstances of when particular criticality values > are appropriate. I wouldn't know. If that was the intent, it's strangely worded - strangely enough that I suspect you may be wrong about the intent, however certain you sound. It isn't what it says at all. As for X.511 which is mentioned elsewhere in this thread, looking that up left me rather confused. A little below the text in section 7.3.1 (Critical extensions) which you quoted, it says: If the criticality of an extension is defined to be critical, the DUA shall set the corresponding bit in criticalExtensions. If the defined criticality is non-critical, the DUA may or may not set the corresponding bit in criticalExtensions. i.e. the criticality in the spec is a mandate, not just a guidance. However, it later says: The extensions, their identifiers, the operations in which they are permitted, the recommended criticality, and the clauses in which they are defined are shown in Table 1. which indicates that e.g. the targetSystem's criticality=TRUE in Table 1 is merely recommended, not mandated. Then, in the definition of targetSystem in section 11.1.2 (Add Entry arguments), it reverts to saying: If the [targetSystem] argument is present, the targetSystem bit in the criticalExtensions parameter in CommonArguments shall be set, indicating that this extension is critical. i.e. criticality=TRUE is mandated. So I guess X.511 can be read either way, but it seems to lean towards mandated criticality, not mere guidance. There doesn't seem to be any text about which criticality to assume if the client sends FALSE when TRUE is mandated, unless (a) you read X.500 as saying the criticality is mandated, so this would be a client error, and (b) there is text somewhere which requires the server to catch such errors. BTW, one note: Unlike LDAP, X.511 does not seem to allow the control spec to mandate that the criticality is FALSE. > The text I proposes attempts clarify the text > to that intent while removing ambiguity that some have raised that > the text could be viewed as stating an implementation requirement > (instead of a document profile). However, it also removes the possibility of interpreting the text as saying the wrong criticality is a user error. So any server which reads rfc2251 as I do and returns an error, will be in violation of the new LDAP spec. > [Snip] > >>Also, I'm still hoping for: >> >> If the criticality field for a supported control does not match >> the value required by the control specification, the server SHOULD >> NOT perform the operation, but instead return protocolError in the >> resultCode if the operation has a response. > > It would be inappropriate to make such a statement in text intended > to detail a document profile. Of course. It would be in the text about the LDAP protocol, not about the control spec. > When considers this as an addition to the technical specification, > absent the document profile, it becomes clear that you are asking > for a change in protocol semantics. I don't understand what you mean here. I'm suggesting to change an implicit 'MAY' - implicit if one reads rfc2251 as I do - to an explicit 'SHOULD'. That is no change in protocol semantics. I might even argue that it is an implicit 'SHOULD' in rfc2251 (when reading it as I do), since good quality servers SHOULD catch client/user errors. > You suggested text is also problematic for a number of reasons: > 1) servers don't, as far as I know, don't behave in the manner you > describe, A SHOULD about that does not make such servers wrong, but will push them into moving in that direction. Such a move will be a problem for some clients, but only the ones that are buggy according to rfc2251. I seem to care less about keeping buggy clients working than you do, at least when the bug can cause the client to do significant harm if someone switches to another server implementation than the client was designed for. > 2) the suggestion is counter to "be liberal in what > they accept" principle, and I've already said why I don't buy this argument. This principle is a guidance, not a command cast in stone. I think it is harmful to follow it here, and I see little advantage in following it. If you wish to argue that LDAP should always follow this principle, then remove error returns from Stringprep, where LDAPbis has broken this principle. > 3) the suggestion hinders changes to guidance given (based upon > operational experiences or otherwise). No, people can change the criticality in a new spec. As I've said, I think that is a major change in the semantics of the control, and to make such a change rather than making a new control is a choice to consider very carefully. After all, the main effect of criticality is when the server _doesn't_ implement the control, not when it does, so modifying the control spec isn't going to help there. The client is still sending an operation which that server should not perform because the operation is wrong without performing the control. E.g. the no-op control. Changing the control spec won't affect that client. >>> (note: the processing semantics of the >>> criticality field, which are defined above, should not be >>> altered in any way by the control's specification), >> >>I'd strengthen that: s/should not/can not/. Remove '(note: )'. >>(Yes, I know. Nobody is as fanatic as a convert:-) > > I think it clearer as suggested. Both seem clear to me, they just say different things. Your 'should not' allows implementations to go against this note, my 'can not' does not. However, I have to retract that suggestion, because I have bad news: There already are control spec RFCs that give the criticality field additional semantics. Look: RFC2649 An LDAP Control and Schema for Holding Operation Signatures 1.1. Audit Trail Mechanism The SignedOperation Control MAY be marked CRITICAL, and if it is CRITICAL then if the LDAP Server performs the LDAP operation, then must include the signature in the signedAuditTrail information. 2. Signed Results Mechanism This control MAY be marked as CRITICAL. If it is marked as CRITICAL and the LDAP Server supports this operation, then all search results MUST be returned with a signature as attached in the SignedResult control if it is willing to sign results for this user. RFC2891 LDAP Control Extension for Server Side Sorting of Search Results 2.1 Behavior in a chained environment If a client submits a sort request to a server which chains the request and gets entries from multiple servers, and the client has set the criticality of the sort extension to TRUE, the server MUST merge sort the results before returning them to the client or MUST return unwillingToPerform. That RFC also has this mess: 2. Client-Server Interaction 3 - If the server supports this sorting control but for some reason cannot sort the search results using the specified sort keys and the client specified TRUE for the control's criticality field, then the server SHOULD do the following: return unavailableCriticalExtension as a return code in the searchResultDone message; include the sortKeyResponseControl in the searchResultDone message, and not send back any search result entries. 4 - If the server supports this sorting control but for some reason cannot sort the search results using the specified sort keys and the client specified FALSE for the control's criticality field, then the server should return all search results unsorted and include the sortKeyResponseControl in the searchResultDone message. So, (3) the control has an effect (returning sortKeyResponseControl) even when the operation fails and unavailableCriticalExtension is returned, and (4) if the server implements the control, there is no such thing as the control having no effect when the criticality is FALSE - even if the real point which the control was designed for is not achieved. Maybe it's less messy - but still ugly - to restate the control spec as follows: The server SHOULD do this: - the control always succeeds if it is supported. Its effect is to _attempt_ to sort the entries (according to a point I didn't quote) and to set the sortKeyResponseControl field in the result. - if sorting failed, the effect of setting criticality=TRUE is to return no entries, and to return unavailableCriticalExtension even though the control succeeded. (Does that mean the control succeeded even though operation failed? Or does it mean that the operation succeeded but returned an error anyway? My head hurts...) It's a bit more complicated because of the rest of section 2, but not significantly, I believe. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sun Jan 11 21:05: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 VAA26211 for ; Sun, 11 Jan 2004 21:05:41 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0C23dra096374; Mon, 12 Jan 2004 02:03:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0C22Arm096313; Mon, 12 Jan 2004 02:02:10 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, 12 Jan 2004 02:02:10 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0C216rY096262; Mon, 12 Jan 2004 02:01:07 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 1AfrO3-0001NT-GE; Mon, 12 Jan 2004 03:01:03 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AfrNy-0001cZ-6M; Mon, 12 Jan 2004 03:00:58 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AfrNy-0002hZ-00; Mon, 12 Jan 2004 03:00:58 +0100 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: Re: Protocol: control specifications. In-Reply-To: <6.0.0.22.0.20040109190833.042d8488@127.0.0.1> References: <6.0.0.22.0.20040109190833.042d8488@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 12 Jan 2004 03:00:58 +0100 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=-4.9, required 12, BAYES_00 -4.90) 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 really should digest the implications of the control RFCs I just posted before replying to some of this, but anyway: Kurt D. Zeilenga writes: >At 05:41 PM 1/9/2004, Jim Sermersheim wrote: >> So, what I think is being asked is this: >> >> If a control specification states: The criticality of the XYZ control >> is always TRUE, and some client sends the XYZ control with >> criticality of FALSE, what is the server to do? > > If the server recognizes the control type and it is appropriate for > the operation, the server will make use of the control when > performing the operation. > > otherwise, the control is to be ignored. > >> Similar but more explicitly, if the control specification says: The >> criticality of the XYZ control SHALL be TRUE, and some client sends >> the XYZ control with criticality of FALSE, what is the server to do? > > (...) > otherwise, the unsupportedCriticalExtension is to returned. I don't like to make a difference between these two cases: I hope you do not wish to give the control spec the same right to override criticality=TRUE sent by the client. I haven't quite thought through the consequences of that, but it feels a lot more dangerous. If not, then figuring out whether the effective criticality is TRUE or FALSE gets rather complicated, and I'm not sure I see the justification for that. Also, the difference between these two texts is very small. An control spec author might choose one when he meant the other, and a reader of the spec might assume one when the author meant the other. It's just like the disagreement in this tread about the wording in RFC2251. So we'd have to demand that the specs are worded very carefully, and perhaps go through existing control specs and update them to clarify this. >> If in either of these scenarios, it seems correct for the server to >> always fail the operation (in order to ensure some aspect of >> interoperability), then somewhere there should be language to that >> effect. > > Exactly, if RFC 2251 had intended this, the text: > If the server recognizes the control type and it is appropriate for > the operation, the server will make use of the control when > performing the operation. > > would have be qualified as only apply when the criticality had a value > consistent with the control's specification. Not so, because that text is about how to perform the operation when it _is_ performed, not about whether or not to perform it. >> Personally, I think such language would belong in the specific >> control specification, and likely, the appropriate resultCode is >> protocolError. > > Authors of such documents should be very careful in including such > language as it likely to cause far more problems that it will ever > solve. (...) I agree. It should be possible to put such additional semantics in the controlValue instead, if one needs to. Also, I don't see much benefit from giving control specs this freedom, when it's all about an error anyway so the correct thing to do is to fix the client. >> On the other hand, if it always inappropriate for any specification >> to mandate behavior when a client violates an imperative regarding >> criticality, then I guess it's always server-defined. > > My suggestion is worded as a strong recommendation, not a mandate. But if we keep the text which lets the spec mandate criticality, the spec is still free to give recommendations. Or we could mention that explicitly in [Protocol]. > It's also > worded as a requirement upon the document defining the control, That's no advantage, if I understand the context correctly:-) > not as a > restriction upon extent of which control can extend the operation. I didn't understand that. Can you rephrase? >> And on yet some other hand, maybe it is inappropriate for a control >> specification to use imperatives. I think that's a discussion to be >> had on its own. Certainly RFC 2251 reads as though the control >> specifications will contain imperatives (implied through the term "is >> always"). > > I believe it is assumed that control specifications will use imperatives > where appropriate. I read both your suggested text and your arguments up to now as denying them that possibility. If you wish to allow the spec to mandate criticality, please add it to your suggested text. Also, are you talking about client-supplied criticality, the criticality which the server assumes, or both? If the former, is it possible that we actually agree about something - that even if we take your suggested text, you would allow servers to treat wrong criticality as an error if they wished? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 12 13:11: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 NAA09012 for ; Mon, 12 Jan 2004 13:11:17 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0CI9ira086112; Mon, 12 Jan 2004 18:09:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0CI8Ts0086047; Mon, 12 Jan 2004 18:08:29 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, 12 Jan 2004 18:08:29 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0CI88rY086017 for ; Mon, 12 Jan 2004 18:08:08 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 12 Jan 2004 11:07:54 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 12 Jan 2004 11:07:25 -0700 From: "Jim Sermersheim" To: Cc: "Duane Buss" , "Steve McLain" Subject: Protocol: Add, ModDN, and RDN attrs 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 For the Add operation, the protocol document states: >Clients MUST include distinguished values (those forming the entry's own RDN) in this list It is silent on whether the distinguished value(s) are to be present when renaming an entry's RDN using Modify DN. I believe the language in Add is flawed, as a read of X.511 says Add: 'The entry argument contains the attribute information which, together with that from the RDN, constitutes the entry to be created" Modify DN: "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 error is returned." The statements from X.511 are clear that the attribute(s) named in the RDN are added (if needed) as part of the operation. I propose aligning the Protocol text for Add and Modify DN with X.511. I worry about breaking implementations though. I know of at least one implementation that is aligned with the wording in X.511. I imagine most or all X.500 vendors also follow this. Comments? Jim From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 12 17:12: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 RAA25088 for ; Mon, 12 Jan 2004 17:12:49 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0CM9qro003513; Mon, 12 Jan 2004 22:11:23 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0CM3MWT003019; Mon, 12 Jan 2004 22:03: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, 12 Jan 2004 22:03:22 +0000 Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0CM31rY002991 for ; Mon, 12 Jan 2004 22:03:01 GMT (envelope-from mcs@pearlcrescent.com) Received: from pearlcrescent.com (pcp05006455pcs.sanarb01.mi.comcast.net[68.40.228.200]) by comcast.net (rwcrmhc11) with SMTP id <20040112220234013005eiase> (Authid: mcs); Mon, 12 Jan 2004 22:02:34 +0000 Message-ID: <40031974.1070405@pearlcrescent.com> Date: Mon, 12 Jan 2004 17:02:28 -0500 From: Mark Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: ietf-ldapbis@OpenLDAP.org, Duane Buss , Steve McLain Subject: Re: Protocol: Add, ModDN, and RDN attrs References: In-Reply-To: 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 Jim Sermersheim wrote: > > I propose aligning the Protocol text for Add and Modify DN with X.511. > I worry about breaking implementations though. I know of at least one > implementation that is aligned with the wording in X.511. I imagine most > or all X.500 vendors also follow this. > > Comments? I am not sure this change is justified. What problem are you trying to address? The language in 2251 is fairly clear; I suspect we will break implementations if we make this change to the LDAP protocol. -Mark From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 12 23:48: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 XAA12682 for ; Mon, 12 Jan 2004 23:48:36 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0D4jtra020870; Tue, 13 Jan 2004 04:46:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0D4hSkS020769; Tue, 13 Jan 2004 04:43: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, 13 Jan 2004 04:43:28 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0D4h7rY020716 for ; Tue, 13 Jan 2004 04:43:07 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 12 Jan 2004 21:42:53 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 12 Jan 2004 15:25:43 -0700 From: "Jim Sermersheim" To: Cc: "Duane Buss" , "Steve McLain" , Subject: Re: Protocol: Add, ModDN, and RDN attrs Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartC2E38CF7.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. --=__PartC2E38CF7.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >>> Mark Smith 1/12/04 3:02:28 PM >>> >Jim Sermersheim wrote: >> >> I propose aligning the Protocol text for Add and Modify DN with X.511. >> I worry about breaking implementations though. I know of at least one >> implementation that is aligned with the wording in X.511. I imagine most >> or all X.500 vendors also follow this. >> >> Comments? > >I am not sure this change is justified. What problem are you trying to >address? The language in 2251 is fairly clear; I suspect we will break >implementations if we make this change to the LDAP protocol. > >-Mark The problem is one of consistency and proper alignment with X.500. I was asked by a directory developer whether the attributes of an RDN MUST also be named in the attribute list during an add. My reply was that according to the protocol document and RFC 2251, yes. Then I was asked how the same scenario works with Modify DN. My reply was that there was no guidance. This prompted me to look at the X.500 specifications and found the discrepancy. You're right, the language in RFC 2251 is clear, but it is opposite of that in X.511. Aside from possibly making some server implementations overly restrictive, What justification is there to leave the language as it is? I can't think of a reason as to why it would have been added without an explanation as to why it is different from the instructions in X.511. If we decide to leave the imperative for compatability with older implementations, we need to explain why it is there. Jim --=__PartC2E38CF7.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
>>> Mark Smith <mcs@pearlcrescent.com> 1/12/04 3:02:28 PM >>>
>Jim Sermersheim wrote:
>>
>> I propose aligning the Protocol text for Add and Modify DN with X.511.
>> I worry about breaking implementations though. I know of at least one
>> implementation that is aligned with the wording in X.511. I imagine most
>> or all X.500 vendors also follow this.
>>
>> Comments?
>
>I am not sure this change is justified. What problem are you trying to
>address? The language in 2251 is fairly clear; I suspect we will break
>implementations if we make this change to the LDAP protocol.
>
>-Mark

The problem is one of consistency and proper alignment with X.500. I was asked by a directory developer whether the attributes of an RDN MUST also be named in the attribute list during an add. My reply was that according to the protocol document and RFC 2251! , yes. Then I was asked how the same scenario works with Modify DN. My reply was that there was no guidance. This prompted me to look at the X.500 specifications and found the discrepancy.
 
You're right, the language in RFC 2251 is clear, but it is opposite of that in X.511. Aside from possibly making some server implementations overly restrictive, What justification is there to leave the language as it is? I can't think of a reason as to why it would have been added without an explanation as to why it is different from the instructions in X.511. If we decide to leave the imperative for compatability with older implementations, we need to explain why it is there.
 
Jim
--=__PartC2E38CF7.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 13 10:31: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 KAA18812 for ; Tue, 13 Jan 2004 10:31:09 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DFT1ra064786; Tue, 13 Jan 2004 15:29:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0DFN6Vc064273; Tue, 13 Jan 2004 15:23: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); Tue, 13 Jan 2004 15:23:06 +0000 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DFMjrY064196 for ; Tue, 13 Jan 2004 15:22:45 GMT (envelope-from jmcmeek@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0DFMO9n373128 for ; Tue, 13 Jan 2004 10:22:24 -0500 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0DFMN9H034022 for ; Tue, 13 Jan 2004 10:22:23 -0500 In-Reply-To: <6.0.0.22.0.20040109200051.042f0f18@127.0.0.1> Subject: Re: Protocol: control specifications. To: ietf-ldapbis@OpenLDAP.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Tue, 13 Jan 2004 09:22:19 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at 01/13/2004 09:22:22 AM 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: After further discussion here, I side with Hallvard. There are likely to be cases where the behavior of a control is such that it really ought to be marked critical because the outcome when used with a server that doesn't support the control is clearly undesirable. To the end user, it is little consolation that the application they are using is at fault because it neglected to mark the control critical. I haven't come up with an argument that a control must have criticality=FALSE to prevent similar situations, so I suggest we get rid of the "criticality always set to FALSE" part. To make it clear that "criticality MUST be TRUE" is a requirement to both the client and server and to avoid confusion (I hope) with previous guidance that criticality always be set to TRUE, I suggest a specific RFC "MUST" clause that can be used in future control specifications. I don't believe current control specification have such language, so there should be no compatibility issue. Support for a new control generally requires some sort of server change; support for a new control could include a mandatory criticality check. That leaves control criticality options as: - critical at senders choice, with a recommended criticality in the control specification, or - criticality MUST be TRUE I suggest that we update protocal 4.1.11 as follows. 1) add the following text somewhere in 4.1.11: A control specification MAY state that "the control criticality MUST be TRUE." If a control is defined in this way and the sender's control criticality is FALSE, the server MUST return protocolError. If a specification does not state that "the control criticality MUST be TRUE" the sender's control criticality is used. 2) update the guidance to control specification writers: The specification of a control consists of: ... - a recommended control criticality, or a requirement that the control criticality MUST be TRUE. John McMeeking "Kurt D. Zeilenga" wrote on 01/09/2004 10:11:02 PM: > At 12:55 PM 1/9/2004, John McMeeking wrote: > >X.511 has a similar notion of recommended criticality. > > Similar or same? Given that one of planned uses of LDAP > Controls was to provide a mechanism in which additional > X.511 semantics could be added to LDAP in a manner which > would facilitate implementation of LDAP<->X.511 gateways, > I think the intent was for the criticality semantics to > be the same. Yes, I could have used "the same". > > X.511: > The criticalExtensions component provides a mechanism > to list a set of extensions which are critical to the > performance of a Directory operation. If the originator > of the extended operation wishes to indicate that the > operation shall be performed with one or more extensions > (i.e. that performing the operation without these > extensions is not acceptable), it does so by setting the > criticalExtensions bit(s) which corresponds to the > extension(s). If the Directory, or some part of it, is > unable to perform a critical extension it returns an > indication of unavailableCriticalExtension (as a > ServiceError or PartialOutcomeQualifier). If the Directory > is unable to perform an extension which is not critical, > it ignores the presence of the extension. > > Sounds the same to me. > From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 13 11:31: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 LAA22315 for ; Tue, 13 Jan 2004 11:31:06 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DGFosU069833; Tue, 13 Jan 2004 16:29:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0DGEXgp069728; Tue, 13 Jan 2004 16:14: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); Tue, 13 Jan 2004 16:14:33 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DGEBrY069644 for ; Tue, 13 Jan 2004 16:14: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.9) with ESMTP id i0DGEBec084191; Tue, 13 Jan 2004 16:14:11 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040113074035.042a6130@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 13 Jan 2004 08:14:04 -0800 To: John McMeeking From: "Kurt D. Zeilenga" Subject: Re: Protocol: control specifications. Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <6.0.0.22.0.20040109200051.042f0f18@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: John, Hallvard, Are you aware of any server implementation which behaves consistently with the interpretation that you and Hallvard favor? Is there any existing clients which relies on this behavior? If not, I don't think it makes sense to make a change which require changes to be made to most (if not all) servers, especially where those changes would cause breakage between pairs of interoperating implementations. I think the suggested new text is pretty clear that if a control specification really needs to alter the semantics of the server's general criticality processing, the control specification needs to state an imperative separately from the guidance it gives to client. That imperative would logically be part of the control's semantics as it is semantics associated with a particular control type. Changing the 'core' TS to say that a "criticality MUST be TRUE" implies both a requirement on the client and a requirement upon the server is quite problematic as there are numerous control specifications in existence which said this but intended that statement to apply only to the client. I know of know control specification which stated "criticality MUST be TRUE" which intended that statement to apply to servers nor am I aware of any server implementation which took such a statement as applying to them. Do you? At 07:22 AM 1/13/2004, John McMeeking wrote: >After further discussion here, I side with Hallvard. There are likely to >be cases where the behavior of a control is such that it really ought to be >marked critical because the outcome when used with a server that doesn't >support the control is clearly undesirable. To the end user, it is little >consolation that the application they are using is at fault because it >neglected to mark the control critical. > >I haven't come up with an argument that a control must have >criticality=FALSE to prevent similar situations, so I suggest we get rid of >the "criticality always set to FALSE" part. > >To make it clear that "criticality MUST be TRUE" is a requirement to both >the client and server and to avoid confusion (I hope) with previous >guidance that criticality always be set to TRUE, I suggest a specific RFC >"MUST" clause that can be used in future control specifications. I don't >believe current control specification have such language, so there should >be no compatibility issue. Support for a new control generally requires >some sort of server change; support for a new control could include a >mandatory criticality check. > >That leaves control criticality options as: >- critical at senders choice, with a recommended criticality in the control >specification, or >- criticality MUST be TRUE > >I suggest that we update protocal 4.1.11 as follows. > >1) add the following text somewhere in 4.1.11: > > A control specification MAY state that "the control criticality MUST be >TRUE." > If a control is defined in this way and the sender's control criticality >is > FALSE, the server MUST return protocolError. If a specification does not > state that "the control criticality MUST be TRUE" the sender's control > criticality is used. This would change the interpretation of existing specifications in a manner which was intended by their authors nor implemented by previous readers, and this would lead to breakage. >2) update the guidance to control specification writers: > > The specification of a control consists of: > > ... > > - a recommended control criticality, or a requirement that the control > criticality MUST be TRUE. A control specification needs to provide adequate guidance. Beyond that, if a control specification wants to change the general semantics of the any protocol field, it should do so in its text which details the semantics of the extension information carried in the control. I have prepared replacement text for the whole section for the WG to consider. I'll be posting it separately. >John McMeeking > > >"Kurt D. Zeilenga" wrote on 01/09/2004 10:11:02 PM: > >> At 12:55 PM 1/9/2004, John McMeeking wrote: >> >X.511 has a similar notion of recommended criticality. >> >> Similar or same? Given that one of planned uses of LDAP >> Controls was to provide a mechanism in which additional >> X.511 semantics could be added to LDAP in a manner which >> would facilitate implementation of LDAP<->X.511 gateways, >> I think the intent was for the criticality semantics to >> be the same. > >Yes, I could have used "the same". > >> >> X.511: >> The criticalExtensions component provides a mechanism >> to list a set of extensions which are critical to the >> performance of a Directory operation. If the originator >> of the extended operation wishes to indicate that the >> operation shall be performed with one or more extensions >> (i.e. that performing the operation without these >> extensions is not acceptable), it does so by setting the >> criticalExtensions bit(s) which corresponds to the >> extension(s). If the Directory, or some part of it, is >> unable to perform a critical extension it returns an >> indication of unavailableCriticalExtension (as a >> ServiceError or PartialOutcomeQualifier). If the Directory >> is unable to perform an extension which is not critical, >> it ignores the presence of the extension. >> >> Sounds the same to me. >> From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 13 11:31: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 LAA22350 for ; Tue, 13 Jan 2004 11:31:09 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DGLisw070656; Tue, 13 Jan 2004 16:29:29 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0DGDrdb069606; Tue, 13 Jan 2004 16:13: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); Tue, 13 Jan 2004 16:13:53 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DGDVrY069553 for ; Tue, 13 Jan 2004 16:13:31 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 13 Jan 2004 09:13:17 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 13 Jan 2004 09:12:36 -0700 From: "Jim Sermersheim" To: , Subject: Re: Protocol: control specifications. Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartD0F199E4.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. --=__PartD0F199E4.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit John, If there were such a control specification, only servers supporting the control would know to return protocolError when that control is marked FALSE. All other servers will allow the operation to progress, and the undesireable results to occur. Also, a client implementation could receive either protocolError or success (or other) in the resultCode of an operation containing such a control by two compliant servers. It may even receive these different results from the same server, depending on configuration state and control architecture. I'm not sure that this is worth the benefit of having servers that 'slap the hand' of clients that don't properly populate the criticality field. It does seem more straght forward for servers to keep doing what has historically been done. That is; examine the control type for support and applicability, if not supported or innapropriate, check the criticality field and act accordingly. When the contol is supported and appropriate, I believe most servers do not even bother making any decisions (and may not even read or store) the criticality field. Jim >>> John McMeeking 1/13/04 8:22:19 AM >>> After further discussion here, I side with Hallvard. There are likely to be cases where the behavior of a control is such that it really ought to be marked critical because the outcome when used with a server that doesn't support the control is clearly undesirable. To the end user, it is little consolation that the application they are using is at fault because it neglected to mark the control critical. I haven't come up with an argument that a control must have criticality=FALSE to prevent similar situations, so I suggest we get rid of the "criticality always set to FALSE" part. To make it clear that "criticality MUST be TRUE" is a requirement to both the client and server and to avoid confusion (I hope) with previous guidance that criticality always be set to TRUE, I suggest a specific RFC "MUST" clause that can be used in future control specifications. I don't believe current control specification have such language, so there should be no compatibility issue. Support for a new control generally requires some sort of server change; support for a new control could include a mandatory criticality check. That leaves control criticality options as: - critical at senders choice, with a recommended criticality in the control specification, or - criticality MUST be TRUE I suggest that we update protocal 4.1.11 as follows. 1) add the following text somewhere in 4.1.11: A control specification MAY state that "the control criticality MUST be TRUE." If a control is defined in this way and the sender's control criticality is FALSE, the server MUST return protocolError. If a specification does not state that "the control criticality MUST be TRUE" the sender's control criticality is used. 2) update the guidance to control specification writers: The specification of a control consists of: ... - a recommended control criticality, or a requirement that the control criticality MUST be TRUE. John McMeeking "Kurt D. Zeilenga" < Kurt@OpenLDAP.org > wrote on 01/09/2004 10:11:02 PM: > At 12:55 PM 1/9/2004, John McMeeking wrote: > >X.511 has a similar notion of recommended criticality. > > Similar or same? Given that one of planned uses of LDAP > Controls was to provide a mechanism in which additional > X.511 semantics could be added to LDAP in a manner which > would facilitate implementation of LDAP<->X.511 gateways, > I think the intent was for the criticality semantics to > be the same. Yes, I could have used "the same". > > X.511: > The criticalExtensions component provides a mechanism > to list a set of extensions which are critical to the > performance of a Directory operation. If the originator > of the extended operation wishes to indicate that the > operation shall be performed with one or more extensions > (i.e. that performing the operation without these > extensions is not acceptable), it does so by setting the > criticalExtensions bit(s) which corresponds to the > extension(s). If the Directory, or some part of it, is > unable to perform a critical extension it returns an > indication of unavailableCriticalExtension (as a > ServiceError or PartialOutcomeQualifier). If the Directory > is unable to perform an extension which is not critical, > it ignores the presence of the extension. > > Sounds the same to me. > --=__PartD0F199E4.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
John,
 
If there were such a control specification, only servers supporting the control would know to return protocolError when that control is marked FALSE. All other servers will allow the operation to progress, and the undesireable results to occur.
 
Also, a client implementation could receive either protocolError or success (or other) in the resultCode of an operation containing such a control by two compliant servers. It may even receive these different results from the same server, depending on configuration state and control architecture.
 
I'm not sure that this is worth the benefit of having servers that 'slap the hand' of clients that don't properly populate the criticality field. It does seem more straght forward for servers to keep doing what has historically been done. That is; examine the control type for support and applicability, if not supported or innapropriate, check the criticality field and act accordingly. When the contol is supported and appropriate, I believe most servers do not even bother making any decisions (and may not even read or store) the criticality field.
 
Jim
 


>>> John McMeeking <jmcmeek@us.ibm.com> 1/13/04 8:22:19 AM >>>




After further discussion here, I side with Hallvard. There are likely to
be cases where the behavior of a control is such that it really ought to be
marked critical because the outcome when used with a server that doesn't
support the control is clearly undesirable. To the end user, it is little
consolation that the application they are using is at fault because it
neglected to mark the control critical.

I haven't come up with an argument that a control must have
criticality=FALSE to prevent similar situations, so I suggest we get rid of
the "criticality always set to FALSE" part.

To make it clear that "criticality MUST be TRUE" is a requirement to both
the client and server and to avoid confusion (I hope) with previous
guidance that criticality always be set to TRUE, I suggest a specific RFC
"MUST" clause that can ! be used in future control specifications. I don't
believe current control specification have such language, so there should
be no compatibility issue. Support for a new control generally requires
some sort of server change; support for a new control could include a
mandatory criticality check.

That leaves control criticality options as:
- critical at senders choice, with a recommended criticality in the control
specification, or
- criticality MUST be TRUE

I suggest that we update protocal 4.1.11 as follows.

1) add the following text somewhere in 4.1.11:

A control specification MAY state that "the control criticality MUST be
TRUE."
If a control is defined in this way and the sender's control criticality
is
FALSE, the server MUST return protocolError. If a specification does not
state that "the control criticality MUST be TRUE" the sender's control
criticality is used.

2) update the guidance to control ! specification writers:

The specification of a control c! onsists of:

...

- a recommended control criticality, or a requirement that the control
criticality MUST be TRUE.


John McMeeking


"Kurt D. Zeilenga" < Kurt@OpenLDAP.org > wrote on 01/09/2004 10:11:02 PM:

> At 12:55 PM 1/9/2004, John McMeeking wrote:
> >X.511 has a similar notion of recommended criticality.
>
> Similar or same? Given that one of planned uses of LDAP
> Controls was to provide a mechanism in which additional
> X.511 semantics could be added to LDAP in a manner which
> would facilitate implementation of LDAP<->X.511 gateways,
> I think the intent was for the criticality semantics to
> be the same.

Yes, I could have used "the same".

>
> X.511:
> The criticalExtensions component provides a mechanism
> to list a set of extensions which are critical to the
> performance of a Direc! tory operation. If the originator
> of the extended operation wishes to indicate that the
> operation shall be performed with one or more extensions
> (i.e. that performing the operation without these
> extensions is not acceptable), it does so by setting the
> criticalExtensions bit(s) which corresponds to the
> extension(s). If the Directory, or some part of it, is
> unable to perform a critical extension it returns an
> indication of unavailableCriticalExtension (as a
> ServiceError or PartialOutcomeQualifier). If the Directory
> is unable to perform an extension which is not critical,
> it ignores the presence of the extension.
>
> Sounds the same to me.
>

--=__PartD0F199E4.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 13 11:58: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 LAA24647 for ; Tue, 13 Jan 2004 11:58:19 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DGpmra075148; Tue, 13 Jan 2004 16:53:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0DGn8bp074710; Tue, 13 Jan 2004 16:49:08 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, 13 Jan 2004 16:49:08 +0000 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DGmkrY074627 for ; Tue, 13 Jan 2004 16:48:46 GMT (envelope-from jmcmeek@us.ibm.com) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0DGmPd6380598 for ; Tue, 13 Jan 2004 11:48:25 -0500 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0DGmOh4231124 for ; Tue, 13 Jan 2004 11:48:24 -0500 In-Reply-To: Subject: Re: Protocol: control specifications. To: ietf-ldapbis@OpenLDAP.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Tue, 13 Jan 2004 10:48:22 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at 01/13/2004 10:48:24 AM 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: See comments below. John McMeeking "Jim Sermersheim" wrote on 01/13/2004 10:12:36 AM: > John, > > If there were such a control specification, only servers supporting > the control would know to return protocolError when that control is > marked FALSE. All other servers will allow the operation to > progress, and the undesireable results to occur. > True, but assuming the application had been tested with a server that supports such a control properly, the app would not be using criticality=FALSE. So the app should get unavailable critical extension. The concern was going the other way -- an application was developed and tested on a server that supported the extension, then used with a server that does not support it. > > Also, a client implementation could receive either protocolError or > success (or other) in the resultCode of an operation containing such > a control by two compliant servers. It may even receive these > different results from the same server, depending on configuration > state and control architecture. I don't follow this part. If the control spec says the control critcality MUST be TRUE, and the client follows this, how would it get protocolError? I would hope that the current control architectures allow the "control implementation" to access criticality, as controls now certainly can be inappropriate (must be able to return unavailable critical extension if criticality is TRUE), and implementations should be able to return protocol error if the control value is in error. > > I'm not sure that this is worth the benefit of having servers that > 'slap the hand' of clients that don't properly populate the > criticality field. It does seem more straght forward for servers to > keep doing what has historically been done. That is; examine the > control type for support and applicability, if not supported or > innapropriate, check the criticality field and act accordingly. When > the contol is supported and appropriate, I believe most servers do > not even bother making any decisions (and may not even read or > store) the criticality field. > Folks disagree on this ;-) I was casting my vote. I would suggest, then, that if we do not choose to enforce criticality, that "always set to TRUE, ... FALSE, or sender's choice" does not add anything and has been the source of questions that folks have received as to what it means when a control is "always critical". If the server does not enforce criticality, a control is, by definition, critical at sender's choice. X.511 just has a table with a column labeled "recommended criticality" (critical or not critical). Limit the control specification guidance in 4.1.11 to: - a recommended control criticality, > Jim > > > > >>> John McMeeking 1/13/04 8:22:19 AM >>> > > > > > After further discussion here, I side with Hallvard. There are likely to > be cases where the behavior of a control is such that it really ought to be > marked critical because the outcome when used with a server that doesn't > support the control is clearly undesirable. To the end user, it is little > consolation that the application they are using is at fault because it > neglected to mark the control critical. > > I haven't come up with an argument that a control must have > criticality=FALSE to prevent similar situations, so I suggest we get rid of > the "criticality always set to FALSE" part. > > To make it clear that "criticality MUST be TRUE" is a requirement to both > the client and server and to avoid confusion (I hope) with previous > guidance that criticality always be set to TRUE, I suggest a specific RFC > "MUST" clause that can ! be used in future control specifications. I don't > believe current control specification have such language, so there should > be no compatibility issue. Support for a new control generally requires > some sort of server change; support for a new control could include a > mandatory criticality check. > > That leaves control criticality options as: > - critical at senders choice, with a recommended criticality in the control > specification, or > - criticality MUST be TRUE > > I suggest that we update protocal 4.1.11 as follows. > > 1) add the following text somewhere in 4.1.11: > > A control specification MAY state that "the control criticality MUST be > TRUE." > If a control is defined in this way and the sender's control criticality > is > FALSE, the server MUST return protocolError. If a specification does not > state that "the control criticality MUST be TRUE" the sender's control > criticality is used. > > 2) update the guidance to control ! specification writers: > > The specification of a control consists of: > > ... > > - a recommended control criticality, or a requirement that the control > criticality MUST be TRUE. > > > John McMeeking > > > "Kurt D. Zeilenga" < Kurt@OpenLDAP.org > wrote on 01/09/2004 10:11:02 PM: > > > At 12:55 PM 1/9/2004, John McMeeking wrote: > > >X.511 has a similar notion of recommended criticality. > > > > Similar or same? Given that one of planned uses of LDAP > > Controls was to provide a mechanism in which additional > > X.511 semantics could be added to LDAP in a manner which > > would facilitate implementation of LDAP<->X.511 gateways, > > I think the intent was for the criticality semantics to > > be the same. > > Yes, I could have used "the same". > > > > > X.511: > > The criticalExtensions component provides a mechanism > > to list a set of extensions which are critical to the > > performance of a Direc! tory operation. If the originator > > of the extended operation wishes to indicate that the > > operation shall be performed with one or more extensions > > (i.e. that performing the operation without these > > extensions is not acceptable), it does so by setting the > > criticalExtensions bit(s) which corresponds to the > > extension(s). If the Directory, or some part of it, is > > unable to perform a critical extension it returns an > > indication of unavailableCriticalExtension (as a > > ServiceError or PartialOutcomeQualifier). If the Directory > > is unable to perform an extension which is not critical, > > it ignores the presence of the extension. > > > > Sounds the same to me. > > From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 13 12:43: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 MAA28238 for ; Tue, 13 Jan 2004 12:43:11 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DHdkra078641; Tue, 13 Jan 2004 17:41:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0DHYoRS078443; Tue, 13 Jan 2004 17:34:50 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, 13 Jan 2004 17:34:50 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DHYTrY078390 for ; Tue, 13 Jan 2004 17:34:29 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 13 Jan 2004 10:34:15 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 13 Jan 2004 10:33:22 -0700 From: "Jim Sermersheim" To: , Subject: Re: Protocol: control specifications. 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 >>> John McMeeking jmcmeek@us.ibm.com> 1/13/04 9:48:22 AM >> >> >> Also, a client implementation could receive either protocolError or >> success (or other) in the resultCode of an operation containing such >> a control by two compliant servers. It may even receive these >> different results from the same server, depending on configuration >> state and control architecture. > >I don't follow this part. If the control spec says the control critcality >MUST be TRUE, and the client follows this, how would it get protocolError? I mean in the case where there is a misbehaving client (which sets criticality to FALSE). >I would hope that the current control architectures allow the "control >implementation" to access criticality, as controls now certainly can be >inappropriate (must be able to return unavailable critical extension if >criticality is TRUE), Yes. >and implementations should be able to return protocol >error if the control value is in error. Current implementations likely only do this iff the criticality field is malformed. >I would suggest, then, that if we do not choose to enforce criticality, >that >"always set to TRUE, ... FALSE, or sender's choice" does not add anything >and has been the source of questions that folks have received as to what it >means >when a control is "always critical". If the server does not enforce >criticality, >a control is, by definition, critical at sender's choice. X.511 just has a >table >with a column labeled "recommended criticality" (critical or not critical). >Limit >the control specification guidance in 4.1.11 to: > >- a recommended control criticality, Yes. I think this is the direction we are likely headed. Jim From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 13 12:47:17 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 MAA28693 for ; Tue, 13 Jan 2004 12:47:16 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DHjira079044; Tue, 13 Jan 2004 17:45:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0DHhvSZ078927; Tue, 13 Jan 2004 17:43: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, 13 Jan 2004 17:43:57 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DHhYrY078893 for ; Tue, 13 Jan 2004 17:43:35 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.9) with ESMTP id i0DHhYec085527 for ; Tue, 13 Jan 2004 17:43:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040113092617.042a9ca8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 13 Jan 2004 09:43:27 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Section 4.1.11 "Controls" replacement text 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: The text in RFC 2251 relies, I believe, on the reader understanding the X.511 service model, especially in regards to the meaning of a control's criticality. Comments? Kurt (Note: I defer chair action in regards to this replacement text to Bob.) 4.1.11. Controls LDAP provides, in Controls, a mechanism for extending existing operations. Each control contains extension information including a control type (controlType) and, optionally, a value (controlValue) which type-specific information. The semantics of the extension information contained in a control instance apply only to the message instance the control was attached to. Additionally, each control includes a field (criticality) which allows the originator of the operation to indicate that the operation must be performed as extended by the control (i.e., that performing the operation without these extensions is unacceptable.) Controls which are attached sent by clients are termed "request controls" and those sent by servers are termed "request controls". Where an extension calls for a particular response control to be returned in response to a request control, the response and request are termed to be "paired". Controls ::= SEQUENCE OF control Control Control ::= SEQUENCE { controlType LDAPOID, criticality BOOLEAN DEFAULT FALSE, controlValue OCTET STRING OPTIONAL } The controlType field is the dotted-decimal representation of an OBJECT IDENTIFIER which identifies the control, or the request control and its paired response control. This provides unambigous naming of controls. The criticality field applies only to request controls excepting those attached to unbindRequest. For these controls, the value TRUE indicates that it is unacceptable to perform the operation without making use of the extension information provided by the control and FALSE otherwise. Specifically, If the server recognizes the control type and it is appropriate for the operation, the server is to make use of the control when performing the operation. If the server does not recognize the control type or it is not appropriate for the operation, and the criticality field is TRUE, the server MUST NOT perform the operation, and for operations that have a response, MUST return unavailableCriticalExtension in the resultCode. If the control is unrecognized or inappropriate but the criticality field is FALSE, the server MUST ignore the control. For all other controls (all response controls and controls attached to the unbindRequest), the sender SHOULD provide a criticality value of FALSE and, regardless of the value provided, receiver MUST ignore the criticality value. The controlValue contains information associated with the control type. Its format is defined in the specification of the control. Implementations MUST be prepared to handle arbitrary contents of the controlValue octet string, including zero bytes. It is absent only if there is no value information which is associated with a control of its type. Servers list the controlType of all request controls they recognize in the supportedControl attribute in the root DSE (Section 5.1 of [Models]). Controls SHOULD NOT be combined unless the semantics of the combination has been specified. The semantics of control combinations, if specified, are generally found in the control specification most recently published. In the absence of combination semantics, the behavior of the operation is undefined. Additionally, unless order-dependent semantics are given in a specification, the order of a combination of controls in the SEQUENCE is ignored. This document does not specify any controls. Controls may be specified in other documents. Documents detailing control extensions are to provide for each control: - the OBJECT IDENTIFIER assigned to the control, - direction as to what value the sender should provide for the criticality field (note: the semantics of the criticality field are defined above should not be altered by the control's specification), - and indication as to whether the controlValue field is to be provided and, if so, the format of the controlValue field (note: where the format of controlValue is defined in terms of ASN.1 and BER encoded according to Section 5.1, the ASN.1 is assumed to follow the extensibility rules provided in Section 4), - the semantics of the control, and - optionally, semantics regarding the combination of the control with other controls. Note: where the format of controlValue that are defined in terms of ASN.1 and BER encoded according to Section 5.1, also follow the extensibility rules in Section 4. From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 13 13:23: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 NAA01515 for ; Tue, 13 Jan 2004 13:23:21 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DILnra081078; Tue, 13 Jan 2004 18:21:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0DIIQQn080971; Tue, 13 Jan 2004 18:18: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); Tue, 13 Jan 2004 18:18:26 +0000 Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0DIHNrY080837; Tue, 13 Jan 2004 18:17:23 GMT (envelope-from ludovic.poitou@Sun.COM) Received: from odin.France.Sun.COM ([129.157.174.8]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i0DIHKqV023126; Tue, 13 Jan 2004 11:17:21 -0700 (MST) Received: from Sun.COM (dhcp-gnb07-211-108 [129.157.211.108]) by odin.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id i0DIHKP26693; Tue, 13 Jan 2004 19:17:20 +0100 (MET) Message-ID: <400435F1.7040909@Sun.COM> Date: Tue, 13 Jan 2004 19:16:17 +0100 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapbis@OpenLDAP.org Subject: Re: Section 4.1.11 "Controls" replacement text References: <6.0.0.22.0.20040113092617.042a9ca8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20040113092617.042a9ca8@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: >The text in RFC 2251 relies, I believe, on the reader understanding >the X.511 service model, especially in regards to the meaning of >a control's criticality. > >Comments? > >Kurt > >(Note: I defer chair action in regards to this replacement text to Bob.) > > >4.1.11. Controls > >LDAP provides, in Controls, a mechanism for extending existing >operations. > >Each control contains extension information including a control >type (controlType) and, optionally, a value (controlValue) which >type-specific information. The semantics of the extension information >contained in a control instance apply only to the message instance >the control was attached to. > >Additionally, each control includes a field (criticality) which >allows the originator of the operation to indicate that the operation >must be performed as extended by the control (i.e., that performing >the operation without these extensions is unacceptable.) > >Controls which are attached sent by clients are termed "request >controls" and those sent by servers are termed "request controls". > > the second one should be "response controls". Otherwise, the proposed text looks good. Ludovic. >Where an extension calls for a particular response control to be >returned in response to a request control, the response and request >are termed to be "paired". > > Controls ::= SEQUENCE OF control Control > > Control ::= SEQUENCE { > controlType LDAPOID, > criticality BOOLEAN DEFAULT FALSE, > controlValue OCTET STRING OPTIONAL } > >The controlType field is the dotted-decimal representation of an >OBJECT IDENTIFIER which identifies the control, or the request >control and its paired response control. This provides unambigous >naming of controls. > >The criticality field applies only to request controls excepting >those attached to unbindRequest. For these controls, the value >TRUE indicates that it is unacceptable to perform the operation >without making use of the extension information provided by the >control and FALSE otherwise. Specifically, > > If the server recognizes the control type and it is appropriate > for the operation, the server is to make use of the control when > performing the operation. > > If the server does not recognize the control type or it is not > appropriate for the operation, and the criticality field is TRUE, > the server MUST NOT perform the operation, and for operations > that have a response, MUST return unavailableCriticalExtension > in the resultCode. > > If the control is unrecognized or inappropriate but the criticality > field is FALSE, the server MUST ignore the control. > >For all other controls (all response controls and controls attached >to the unbindRequest), the sender SHOULD provide a criticality value >of FALSE and, regardless of the value provided, receiver MUST ignore >the criticality value. > >The controlValue contains information associated with the control >type. Its format is defined in the specification of the control. >Implementations MUST be prepared to handle arbitrary contents of >the controlValue octet string, including zero bytes. It is absent >only if there is no value information which is associated with a >control of its type. > >Servers list the controlType of all request controls they recognize >in the supportedControl attribute in the root DSE (Section 5.1 of >[Models]). > >Controls SHOULD NOT be combined unless the semantics of the combination >has been specified. The semantics of control combinations, if >specified, are generally found in the control specification most >recently published. In the absence of combination semantics, the >behavior of the operation is undefined. Additionally, unless >order-dependent semantics are given in a specification, the order >of a combination of controls in the SEQUENCE is ignored. > >This document does not specify any controls. Controls may be specified >in other documents. Documents detailing control extensions are to >provide for each control: > >- the OBJECT IDENTIFIER assigned to the control, > >- direction as to what value the sender should provide for the > criticality field (note: the semantics of the criticality field > are defined above should not be altered by the control's > specification), > >- and indication as to whether the controlValue field is to be > provided and, if so, the format of the controlValue field > (note: where the format of controlValue is defined in terms > of ASN.1 and BER encoded according to Section 5.1, the ASN.1 > is assumed to follow the extensibility rules provided in > Section 4), > >- the semantics of the control, and > >- optionally, semantics regarding the combination of the control > with other controls. > >Note: where the format of controlValue that are defined in terms of >ASN.1 and BER encoded according to Section 5.1, also follow the >extensibility rules in Section 4. > > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ietf-ldapbis@OpenLDAP.org Wed Jan 14 09: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 JAA20322 for ; Wed, 14 Jan 2004 09:37:22 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0EETora063939; Wed, 14 Jan 2004 14:34:45 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0EELrR2063188; Wed, 14 Jan 2004 14:21: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, 14 Jan 2004 14:21:53 +0000 Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0EELVrY063043 for ; Wed, 14 Jan 2004 14:21:32 GMT (envelope-from mcs@pearlcrescent.com) Received: from pearlcrescent.com (pcp05006455pcs.sanarb01.mi.comcast.net[68.40.228.200]) by comcast.net (rwcrmhc11) with SMTP id <20040114142105013008c1jse> (Authid: mcs); Wed, 14 Jan 2004 14:21:06 +0000 Message-ID: <4005504B.4090408@pearlcrescent.com> Date: Wed, 14 Jan 2004 09:20:59 -0500 From: Mark Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: Duane Buss , Steve McLain , ietf-ldapbis@OpenLDAP.org Subject: Re: Protocol: Add, ModDN, and RDN attrs References: In-Reply-To: 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 Jim Sermersheim wrote: > > The problem is one of consistency and proper alignment with X.500. I was > asked by a directory developer whether the attributes of an RDN MUST > also be named in the attribute list during an add. My reply was that > according to the protocol document and RFC 2251, yes. Then I was asked > how the same scenario works with Modify DN. My reply was that there was > no guidance. This prompted me to look at the X.500 specifications and > found the discrepancy. OK; that makes sense. We should certainly specify how things work with Modify DN as well as Add. > You're right, the language in RFC 2251 is clear, but it is opposite of > that in X.511. Aside from possibly making some server implementations > overly restrictive, What justification is there to leave the language as > it is? I can't think of a reason as to why it would have been added > without an explanation as to why it is different from the instructions > in X.511. If we decide to leave the imperative for compatability with > older implementations, we need to explain why it is there. Fair enough. I can only speculate on why the language was included. Possible reasons: 1) Accidental (someone wanted to be consistent with X.511 but got it wrong). I think this is an unlikely reason. 2) Intentional. Perhaps someone thought LDAP server implementations would be simpler if distinguished values were included. It seems likely that some server implementations rely on clients including distinguished values. But I am not sure. The Netscape implementation I used to work on was "enhanced" at some point in the somewhat distant past to be liberal in what it accepts and handle clients that include or omit such values. -Mark From owner-ietf-ldapbis@OpenLDAP.org Sat Jan 17 00:02: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 AAA13386 for ; Sat, 17 Jan 2004 00:02:08 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0H500rY061385; Sat, 17 Jan 2004 05:00:00 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0H4phPD060704; Sat, 17 Jan 2004 04:51:43 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 Jan 2004 04:51:43 +0000 Received: from highlandsun.propagation.net (highlandsun.propagation.net [66.221.212.168]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0H4pMrY060639 for ; Sat, 17 Jan 2004 04:51:22 GMT (envelope-from hyc@highlandsun.com) Received: from CELLO (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with SMTP id i0H4pHEb019975; Fri, 16 Jan 2004 22:51:18 -0600 From: "Howard Chu" To: "'Mark Smith'" Cc: Subject: RE: Protocol: Add, ModDN, and RDN attrs Date: Fri, 16 Jan 2004 20:50:03 -0800 Message-ID: <03e301c3dcb5$65cd23c0$1801a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4005504B.4090408@pearlcrescent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 > -----Original Message----- > From: owner-ietf-ldapbis@OpenLDAP.org > [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Mark Smith > Jim Sermersheim wrote: > > You're right, the language in RFC 2251 is clear, but it is > opposite of > > that in X.511. Aside from possibly making some server > implementations > > overly restrictive, What justification is there to leave > the language as > > it is? I can't think of a reason as to why it would have been added > > without an explanation as to why it is different from the > instructions > > in X.511. If we decide to leave the imperative for > compatability with > > older implementations, we need to explain why it is there. > > Fair enough. I can only speculate on why the language was included. > Possible reasons: > > 1) Accidental (someone wanted to be consistent with X.511 but got it > wrong). I think this is an unlikely reason. > > 2) Intentional. Perhaps someone thought LDAP server implementations > would be simpler if distinguished values were included. > > It seems likely that some server implementations rely on clients > including distinguished values. But I am not sure. The Netscape > implementation I used to work on was "enhanced" at some point in the > somewhat distant past to be liberal in what it accepts and handle > clients that include or omit such values. It would certainly be more user-friendly to do it this way. The current 2251 language goes against the "be liberal in what you accept" philosophy; if there's no good justification for it then it appears to be a bug. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support From owner-ietf-ldapbis@OpenLDAP.org Wed Jan 21 02:12: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 CAA25005 for ; Wed, 21 Jan 2004 02:12:07 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0L7AXrY073773; Wed, 21 Jan 2004 07:10:33 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0L6wpjW072697; Wed, 21 Jan 2004 06:58: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); Wed, 21 Jan 2004 06:58:51 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0L6wUrY072682 for ; Wed, 21 Jan 2004 06:58:30 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 20 Jan 2004 23:58:19 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 20 Jan 2004 23:57:46 -0700 From: "Jim Sermersheim" To: Subject: Outstanding protocol issues Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartFEDFBDFA.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. --=__PartFEDFBDFA.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit All, Here are the current issues that I have not yet added to the protocol doc: 1) What does 'extensibility is implied where it is allowed' mean? (see http://www.openldap.org/lists/ietf-ldapbis/200401/msg00025.html) I need to re-research and add wording. 2) From a private message from Hallvard: >> 4.7. Add Operation > >> If the parent entry exists >> but is not in a naming context held by the server, the server SHOULD >> return a referral to the server holding the parent entry. > >This is wrong when adding the root entry of the naming context. I think I just need to articulate properly why I believe that the current wording is correct. 3) Thread started in http://www.openldap.org/lists/ietf-ldapbis/200401/msg00085.html I need to gauge consensus. If you have input on any of these, it will help. Jim --=__PartFEDFBDFA.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
All,
 
Here are the current issues that I have not yet added to the protocol doc:
 
1) What does 'extensibility is implied where it is allowed' mean? (see http://www.openldap.org/lists/ietf-ldapbis/200401/msg00025.html)
 
I need to re-research and add wording.
 
2) From a private message from Hallvard:
>> 4.7. Add Operation
>
>>    If the parent entry exists
>>    but is not in a naming context held by the server, the server SHOULD
>>    return a referral to the server holding the parent entry.
>
>This is wrong when adding the root entry of the naming context.
I think I just need to articulate properly why I believe that the current wording is correct.
 
I need to gauge consensus.
 
 
If you have input on any of these, it will help.
 
Jim
 
--=__PartFEDFBDFA.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 29 10:38: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 KAA25240 for ; Thu, 29 Jan 2004 10:38:29 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [127.0.0.1]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0TFSDYx075653; Thu, 29 Jan 2004 15:36:23 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.10/8.12.10/Submit) with SMTP id i0TFM1DJ075165; Thu, 29 Jan 2004 15:22: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); Thu, 29 Jan 2004 15:22:01 +0000 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by boole.openldap.org (8.12.10/8.12.10) with ESMTP id i0TFLxYX075119 for ; Thu, 29 Jan 2004 15:22:00 GMT (envelope-from dinaras@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 KAA23760; Thu, 29 Jan 2004 10:21:57 -0500 (EST) Message-Id: <200401291521.KAA23760@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapbis@OpenLDAP.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapbis-protocol-21.txt Date: Thu, 29 Jan 2004 10:21:56 -0500 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-21.txt Pages : 59 Date : 2004-1-28 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-21.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-21.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-21.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-1-29104357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapbis-protocol-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapbis-protocol-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-29104357.I-D@ietf.org> --OtherAccess-- --NextPart--