From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 1 00:07:09 2005 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 AAA20937 for ; Fri, 1 Apr 2005 00:07:08 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3156MPs045995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 05:06:25 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j3152pKE045883; Fri, 1 Apr 2005 05:02:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 1 Apr 2005 05:02:51 +0000 Received: from highlandsun.propagation.net (highlandsun.propagation.net [66.221.212.168]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3152j0c045874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Apr 2005 05:02:49 GMT (envelope-from hyc@highlandsun.com) Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id j3152ReQ020957; Thu, 31 Mar 2005 23:02:38 -0600 Message-ID: <424CD5E5.4060907@highlandsun.com> Date: Thu, 31 Mar 2005 21:02:29 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050318 MIME-Version: 1.0 To: Jim Sermersheim CC: ietf-ldapbis@OpenLDAP.org Subject: Re: draft-ietf-ldapbis-protocol - controls References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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-ID: ietf-ldapbis mailing list List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > >There is nothing in RFC2251 that suggests the current LDAPbis > >interpretation is either intended or correct. Call me crazy, but I'd say > >a behavior that is fundamentally useless doesn't belong in the spec. > When I read RFC2251, I have to disagree. ... > "If the control is not appropriate for the operation and criticality > field is TRUE, the server MUST NOT perform the operation, and MUST > instead return the resultCode unsupportedCriticalExtension." > If "appropriate" means that the server found *any* reason in which the > control causes the operation to fail, this says it should return > unsupportedCriticalExtension (as opposed to something like > insufficientAccessRights) for critical controls. OK. Some might view that as confusing, but I think that agrees with the principle of least disclosure. (E.g., not disclosing the existence of entries/attributes in a search result, if the user lacks permission to see them.) > In your view, what would be the proper definition of "appropriate"? Or > if that's too limiting, what would you like the criticality to mean? We are talking about non-critical controls, specifying that an optional feature be used if it is available. I'm fine with "appropriate" meaning, in part, that the control and operation are suitable for use together as defined in the control's specification. I'm fine with critical controls behaving as specified; clearly marking a control as Critical means the feature is mandatory and not optional. One could make a case for returning an error (e.g. protocolError) if the server receives a non-critical control that is not appropriate for the accompanying request type. I wouldn't, because it's always possible for the control spec to be extended later, and the combination may be legal in the new spec. (Sure this is a bad example, and a new spec ought to get a new OID.) So even with the limited definition where "appropriate" only means "appropriate as defined by the control specification" I think it is wrong for a server to return an error for an improperly specified non-critical control. If the request is handed off to some other agent/backend that does not support the control, then to me that should behave exactly the same as if the client had directly issued the request to that agent, i.e., the agent lacking support for the control would just ignore it. Really, whatever the frontend entity is should be acting as a transparent pipe here, it cannot accurately validate support for the control so it shouldn't ever try to. The point is that the mere presence of a non-critical control should not be sufficient to cause the server to reject a request. By reject, I mean that the server returns an error before even beginning to execute the actual request. Once a server has accepted all the parameters of the request, including any controls it recognizes and supports, and started generating results, then the criticality consideration no longer applies, and the request succeeds or fails as it may. -- -- 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 Fri Apr 1 00:11:50 2005 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 AAA21463 for ; Fri, 1 Apr 2005 00:11:50 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j315B6CG046148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 05:11:08 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j3158b9T046070; Fri, 1 Apr 2005 05:08: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, 1 Apr 2005 05:08:37 +0000 Received: from highlandsun.propagation.net (highlandsun.propagation.net [66.221.212.168]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3158Xrt046051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 05:08:34 GMT (envelope-from hyc@highlandsun.com) Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id j3158O1D021067; Thu, 31 Mar 2005 23:08:25 -0600 Message-ID: <424CD74A.9050709@highlandsun.com> Date: Thu, 31 Mar 2005 21:08:26 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050318 MIME-Version: 1.0 To: Jim Sermersheim CC: Kurt@OpenLDAP.org, mark.ennis@eb2bcom.com, ietf-ldapbis@OpenLDAP.org Subject: Re: draft-ietf-ldapbis-protocol - controls References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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-ID: ietf-ldapbis mailing list List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > I believe the broad interpretation of "appropriate" leads to far more > interoperability problems than the narrow view. > > I'm glad to see that you don't believe a control can be partially applied. > > The fact is, every implementation is going to behave quite differently > when it is allowed to either fail-over to ignoring a control or return > an error which was caused by the application of that control. > > It will be extremely difficult to evaluate all error paths in code to > determine whether the error could be allieviated by ignoring any > non-critical controls that might be present. If one cooses not to do > that, one could instead, upon encountering any error condition, ignore > one non-critical control. If the operation still fails, one could ignore > another non-critical error (and probably should un-ignore that first > one). One could keep doing this until one has ignored enough > non-critical controls (rolling back the transaction each time), > until one determines that the operation is just going to fail no matter > what, or until the the operation succeeds (one hopes one hasn't > accidentally ignored a few non-critical controls that really wouldn't > have caused the error) I am not suggesting that servers do any back-tracking to mitigate the failures encountered while processing a request accompanied by non-critical controls. Only stating that the presence of a non-critical control should not cause a server to choose not to *begin* executing the accompanying request. Once the server has decided to begin executing the request, any incidental errors should of course be reported back to the client as usual. -- -- 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 Fri Apr 1 00:11:52 2005 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 AAA21481 for ; Fri, 1 Apr 2005 00:11:51 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j315B6CI046148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 05:11:09 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j3154Uxr045928; Fri, 1 Apr 2005 05:04: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); Fri, 1 Apr 2005 05:04:30 +0000 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3154MT8045911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 05:04:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050331204622.02fb52f0@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 31 Mar 2005 21:04:00 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-ldapbis-protocol - controls Cc: , , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-ID: ietf-ldapbis mailing list List-Unsubscribe: Content-Transfer-Encoding: 8bit The server has choose to either ignore the non-critical control for the entire operation or make use of the non-critical control for the entire operation. If the server has different capabilities in different portions of the DIT (due to chaining or whatever), the server has to deal with that in some fashion that ensures the entire operation is processed in a manner consistent with the above. How to make use of the control over the entire operation depends on the control and implementation choices. In some cases (for instance, likely w/ managedsait), the right answer is to mark the control as critical when forwarding it and, if unavailable, return a search continuation for that portion of DIT. In other cases, the server might leave the control non-critical in chaining (for instance, possible with sorted results... easier to merge sorted results than to merge unsorted results). And it other cases, it might be best to strip the control and handle all the operation semantics locally (for instance, possibly with sorted results). But the issue here shouldn't be how the server maintains the semantics, but what semantics the client can rely on the server to maintain. The client be able to rely on each non-critical control applying to all the results or none of the results returned for the request. Kurt At 08:18 PM 3/31/2005, Jim Sermersheim wrote: >>>> Mark Ennis 3/31/05 8:21:43 PM >>> >>While I agree that the idea of testing the capabilities of the servers >>is not practical, I do think the idea of defining procedures for >>distributed operations which force controls to be critical and then >>process the results of distributed requests to form an appropriate >>response to the clients original request is potentially viable. This >>assumes that a control specification is not permitted to mandate that a >>control MUST be non-critical. >> >>That said, I do agree that non-critical controls should be ignored >>rather then result in an error code for the operation. And this would >>simplify procedures for distributed operations for LDAP. >If it is not immediately known whether a control would cause an error, then at what point can a non-critical control be ignored? Prior to name resolution? Prior to operation evaluation? During operation evaluation? Before sending any responses to the client? After sending responses to the client? > >Similarly, when does one know whether to return an error versus discarding an transaction which has begun and re-starting the operation sans the control? > >Also, some controls define error codes to be returned for certain conditions (see VLV for example). When these conditions are met when the control is non-critical, should it also be ignored and the operation be re-applied without the control? > >There are cases where allowing non-critical controls to be ignored doesn't simplify the distributed operation problem. When a control is paired with a response control which indicates whether or not the control was successfully applied, then the chaining server is still faced with having to deal with different behaviors of chained-to servers. Also, any non-critical control on search operations may succeed on an initial server, and be ignored when chained to another server. Meaning the control was partially supported. I think most people would agree that this is undesirable — a control should either be applied or ignored unless that control specification allows it to be partially applied. > >Also consider the tree delete control. A client may send this as non-critical, knowing (well, expecting) that if it's recognized and appropriate, it will be applied, and the subtree will be deleted. If it can partially fail (due to being chained or sent to multiple backends), the subtree may be partially deleted and the tree left with a hole in it. > >Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 1 00:51:24 2005 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 AAA23907 for ; Fri, 1 Apr 2005 00:51:24 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j315nk23047091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 05:50:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j315hlVJ046987; Fri, 1 Apr 2005 05:43: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); Fri, 1 Apr 2005 05:43:47 +0000 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j315hcLg046969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 05:43:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050331210634.02e65aa8@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 31 Mar 2005 21:43:16 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-ldapbis-protocol - controls Cc: , , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-ID: ietf-ldapbis mailing list List-Unsubscribe: Content-Transfer-Encoding: 8bit At 08:49 PM 3/31/2005, Jim Sermersheim wrote: >I believe the broad interpretation of "appropriate" leads to far more interoperability problems than the narrow view. > >I'm glad to see that you don't believe a control can be partially applied. This, I think, needs to be made crystal clear. >The fact is, every implementation is going to behave quite differently when it is allowed to either fail-over to ignoring a control or return an error which was caused by the application of that control. The specification don't prescribe same behavior. The specification prescribes syntaxes and semantics aimed at allowing implementations to communicate requests and responses allowing clients to receive service from the server. If the client communicates that portions of the request are not critical, the server should not only be free to ignore those portions when responding, but the server should be encouraged to ignore those portions would lead to responses that deny service to the client. Deny service will certainly lead to interoperability problems as the protocol provides no mechanism allowing the server to communicate which portions of the request it couldn't deal with. Fallbacking is problematic as the protocol has no mechanism to express how far to fallback, or whether fallbacking would allow service to be provided. >It will be extremely difficult to evaluate all error paths in code to determine whether the error could be allieviated by ignoring any non-critical controls that might be present. If one cooses not to do that, one could instead, upon encountering any error condition, ignore one non-critical control. If the operation still fails, one could ignore another non-critical error (and probably should un-ignore that first one). One could keep doing this until one has ignored enough non-critical controls (rolling back the transaction each time), until one determines that the operation is just going to fail no matter what, or until the the operation succeeds (one hopes one hasn't accidentally ignored a few non-critical controls that really wouldn't have caused the error) > >If the implementation instead, just performs some arbitrary pre-checks to make sure it's fairly certain that the control won't cause the operation to fail, it will never perform the same as another implementation. The issue is not whether the operation will perform the same on another implementation. The issue is whether the service provided is within the prescribed possibilities. If the client requested an operation with two non-critical controls X and Y, then the service provided should be consistent with one of the following prescribed semantics: a) operation b) operation+X c) operation+Y d) operation+X+Y I would hope that servers recognizing both X and Y would try to provide the "best" service possible. If they know that they cannot provide operation+X+Y in a particular scenario, and are able to detect that scenario up front, they should by all means ignore one or both of the controls if by doing so they can provide service. Since the client did not mark X or Y critical, the server should assume that service with a) semantics is better than service with b) or c) than no d) service. >Maybe I'm over-complicating or over-simplifying or over-thinking this? > >I rather doubt anyone is confused as to whether a control may be partially applied — that's just silly, so I don't think we need to add language to that effect. > >I think the confusion has to do with what "appropriate" means. >If the WG wants it to be more precicely defined, then let's come up with some wording. As it is, it just says appropriate. My only fear is that it will ultimately lead to worse interoperability. I think s/appropriate/appropriate in the server's determination/ would be appropriately vague. Now, maybe what we need is to clarify is servers should, where feasible and consistent with semantics choices of the request (e.g., no partial application of controls), favor providing some service over providing no service. >Jim > >>>> "Kurt D. Zeilenga" 3/31/05 9:09:46 PM >>> >I find this comment from Steve Kille interesting: >Some extensions can safely be ignored without loss of service. >Others will simply not work if they are not understood and >need to be rejected. The criticality mechanism allows this >to be communicated. This is particularly important in a >store and forward messaging environment, or where >directory requests are chained. >< http://www.openldap.org/lists/ietf-ldapext/199802/msg00088.html > > >I think the key point I and Howard are making is that by not >ignoring a recognized and applicable (per the specification) >non-critical control one cannot service, one causes an >unnecessary and inappropriate loss of service. > >The language in RFC 2251 was: >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. > >I think it natural for implementors interpret "appropriate >for the operation" in a broad manner, and I think it clear that >many client and server implementors have interpreted "appropriate >for the operation" in a broad manner. Narrow interpretations, >such as viewing the language as a mandatory requirement >for servers to "make use" of applicable controls they recognize >leads to idiotic behavior. > >For instance, I could code an LDAP server to "recognize" >every known request control but not support any of them. >Under the narrow interpretation taken by the WG, my server would >be obligated to turn unwillingToPerform (or some other >appropriate result code). I do not believe this is what was >intended by designers of LDAP. But regardless of their intent, >the interpretation taken by the WG will lead to significant >interoperability problems and hinder development/deployment >of distributed directory services. > >What I think needs to be clarified is the above text is that >the server is to perform the operation, the whole operation, >as extended by the control. It cannot perform only part of >the operation as extended by the control. This, of course, >has some implications on distributed systems, but I argue >that the server ability to ignore applicable non-critical >controls is key to making such systems work in face of >extensions... which is what I think Steve was hinting at >in is 1998 ASID/LDAPEXT post. > >-- Kurt > > > >At 07:01 PM 3/31/2005, Howard Chu wrote: >>Jim Sermersheim wrote: >>>Sorry, if the operation is chained before being applied locally, don't change criticality. >>> >>>And yes, other options are to test the capabilities of the other agents/backends, and to perform the behavior locally when not supported (a server or frontend could do this with the sorting or vlv control, but would have to gather all entries first. >> >>The idea of testing the capabilities of the other servers/backends in advance really doesn't scale well. If you have a large distributed set of directory servers, where any server may be the frontend for yet another arbitrarily large set of servers, you may spend more time querying the capabilities (and getting unreliable answers) than actually processing the client's original request. Nor is this sort of thing properly cachable, since different servers with different capabilities may enter and leave the network at arbitrary times. >> >>Following this line of attack is futile. It imposes additional overhead on the servers to collect a type of information in which the client has absolutely no interest. >> >>There is nothing in RFC2251 that suggests the current LDAPbis interpretation is either intended or correct. Call me crazy, but I'd say a behavior that is fundamentally useless doesn't belong in the spec. >> >>> >>> Mark Ennis < mark.ennis@eb2bcom.com > 3/30/05 12:13:20 AM >>> >>>Jim Sermersheim wrote: >>> > I believe this is what our chaining server does as well, though we >>> > have talked about changing chained controls to be critical in the >>> > past. >>> > >>> > I think your work around could be implemented and render (somewhat) >>> > expected effects: >>> > >>> > Say a search operation has attached to it a non-critical control >>> > (which the DSA supports). When the local DSA chains, it forces it to >>> > be critical. >>> > >>> > If the operation was chained before the control was used in >>> > processing the operation, then any resultCode returned from the >>> > chained-to DSA would be preserved. >>>Such as an unavailableCriticalExtension resultCode when the original >>>request had no critical controls? >>> > >>> > If the operation was chained during operation evaluation after being >>> > partially supported by the local DSA, and if the chained-to DSA >>> > returned unavailableCriticalExtension, the operation could return a >>> > different error (which would indicate that the operation could not be >>> > completed as specified). >>>Might work, although this strategy would lead to a difference in the >>>results obtained depending on whether the server handles the chaining >>>versus returning referrals and the client handling followup of the >>>referrals. >>>Possibly the question of "what result would a client get if it handled >>>requests to each individual context?" is worth exploring. I would be >>>inclined to think a client would send the same request to each context >>>with the control marked non-critical (or not bother to send it to the >>>contexts which do not advertise support for the control). This leads me >>>to be inclined to have a server replicate this behaviour rather than >>>return errors for non-critical controls. >>> > >>> > >>> > >>> > >>> >>>> Mark Ennis <_ mark.ennis@acm.org < mailto:mark.ennis@acm.org >_ > 3/29/05 6:11:00 PM >>> >>> > >>> > As indicated in the message Jim referenced, our server will ignore >>> > the criticality flag of a control it recognises. However, this does >>> > not entirely address the issue Howard raised. >>> > >>> > In a distributed environment, a server receiving a request may need >>> > to chain this request to a number of other servers, where the support >>> > of various controls in the different servers may be different. Where >>> > a given server receiving a chained request does not support a >>> > control, it will base its processing decision on the criticality of >>> > the control. So even if the server which received the request from >>> > the client can support a given control, the control will potentially >>> > be ignored for some part of the result set. This results in the >>> > effective behaviour of the server, which received the original >>> > request from the client, ignoring the non-critical control for some >>> > contexts, even though it does support the control. This is the way >>> > our server effectively behaves. >>> > >>> > The only way around this, at present, would seem to be to force all >>> > the controls in a chained request to be critical, which would seem to >>> > be counter to the client's request that the processing of a >>> > non-critical control is optional. >>> > >>> > Our policy is to handle controls, in general, in the way John >>> > McMeeking described, which is to ignore unsupported and inapropriate >>> > non-critical controls. >>> > >>> > - Mark. >>> > >>> > Jim Sermersheim wrote: >>> > >>> >>> From another vendor: >>> >> _http://www.openldap.org/lists/ietf-ldapbis/200403/msg00055.html_ >>> >> >>> >> >>> >> >>> >>>>> "Jim Sermersheim" < _jimse@novell.com < mailto:jimse@novell.com >_ > 3/29/05 5:08:37 PM >>> >>> >>>>> >>> >> >>> >> >>> >> Our implementations do this: >>> >> >>> >> Is the control recognized and appropriate (as specified) for the >>> >> operation? Yes, process the operation No, Is it marked critical? >>> >> Yes, fail with unavailable critical extension No, Ignore the >>> >> control and process the operation >>> >> >>> >> This has been discussed at length in the past, and consensus was >>> >> that this was the original intent and that this is what should be >>> >> conveyed in the new document. >>> >> >>> >> IIRC, there were interoperability side effects of allowing >>> >> "appropriate" to mean anything the server wishes it to mean. >>> >> >>> >> Jim >> >>-- >> -- 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 Fri Apr 1 01:17:50 2005 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 BAA25935 for ; Fri, 1 Apr 2005 01:17:49 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j316FvkG047940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 06:17:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j316FRI5047921; Fri, 1 Apr 2005 06:15: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, 1 Apr 2005 06:15:27 +0000 Received: from micah.software-aus.com.au (cust3103.vic01.dataco.com.au [202.63.62.31]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j316FC8p047887; Fri, 1 Apr 2005 06:15:14 GMT (envelope-from mark.ennis@eb2bcom.com) Received: from [192.168.1.148] (192.168.1.148) by micah.software-aus.com.au (7.1.016.1) id 42129E3E00003548; Fri, 1 Apr 2005 16:19:54 +1000 Message-ID: <424CE6B7.7060009@eb2bcom.com> Date: Fri, 01 Apr 2005 16:14:15 +1000 From: Mark Ennis User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jim Sermersheim , hyc@highlandsun.com, ietf-ldapbis@OpenLDAP.org Subject: Re: draft-ietf-ldapbis-protocol - controls References: <6.2.1.2.0.20050331210634.02e65aa8@mail.openldap.org> In-Reply-To: <6.2.1.2.0.20050331210634.02e65aa8@mail.openldap.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; 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-ID: ietf-ldapbis mailing list List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > At 08:49 PM 3/31/2005, Jim Sermersheim wrote: > >> I believe the broad interpretation of "appropriate" leads to far >> more interoperability problems than the narrow view. >> >> I'm glad to see that you don't believe a control can be partially >> applied. > > > This, I think, needs to be made crystal clear. > A control which results in modification of multiple objects must not be partially applied, but what about a control that modifies the behaviour of a query? A control requesting extra information from each entry in a search result, for example a control to reproduce the behaviour of the modifyRightsRequest in a DAP read operation, may be partially applied, without having any serious implications. To what extent should the allowance to partially apply a control be regulated by the specification controlling the infrastructure, i.e. [protocols], versus the control specification? For example, a control specification for a tree delete control should include a discussion of considerations relating to application of the control in a distributed environment or across different contexts, regardless of what [protocols] may say. From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 1 01:41:55 2005 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 BAA27709 for ; Fri, 1 Apr 2005 01:41:54 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j316dwh2048797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 06:40:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j316a9dH048693; Fri, 1 Apr 2005 06:36:09 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 1 Apr 2005 06:36:09 +0000 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j316a4GQ048657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 06:36:05 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050331221608.0311f2a0@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 31 Mar 2005 22:35:42 -0800 To: Mark Ennis From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-ldapbis-protocol - controls Cc: Jim Sermersheim , hyc@highlandsun.com, ietf-ldapbis@OpenLDAP.org In-Reply-To: <424CE6B7.7060009@eb2bcom.com> References: <6.2.1.2.0.20050331210634.02e65aa8@mail.openldap.org> <424CE6B7.7060009@eb2bcom.com> 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-ID: ietf-ldapbis mailing list List-Unsubscribe: At 10:14 PM 3/31/2005, Mark Ennis wrote: >Kurt D. Zeilenga wrote: >>At 08:49 PM 3/31/2005, Jim Sermersheim wrote: >> >>>I believe the broad interpretation of "appropriate" leads to far >>>more interoperability problems than the narrow view. >>>I'm glad to see that you don't believe a control can be partially >>>applied. >> >>This, I think, needs to be made crystal clear. >A control which results in modification of multiple objects must not be partially applied, but what about a control that modifies the behaviour of a query? Meaning that given a request+control where the control is non-critical, the server is to perform either the operation indicated by the request OR to perform the operation indicated by request+control. The server cannot perform a portion of the operation as indicated by request+control and a portion of the operation as indicated by request. For instance, it would be inappropriate for a server, in response to a search+manageDsaIt request, to only apply the semantics indicated by the manageDsaIt to a subset of the results. The server is obligated to apply those semantics across all results or no results. >A control requesting extra information from each entry in a search result, for example a control to reproduce the behaviour of the modifyRightsRequest in a DAP read operation, may be partially applied, without having any serious implications. Different kind of "apply". If the prescribed semantics of the operation indicated by request+control allow for some of these modifications to be applied to the DIT and others not, that fine. But if the prescribed semantics of this operation required that all or none of these modifications to be applied to the DIT, then that's what has to be done in performance of that operation. >To what extent should the allowance to partially apply a control be regulated by the specification controlling the infrastructure, i.e. [protocols], versus the control specification? The control specification defines what operation to perform in response to a request+control message. Where the control is non-critical, the server has a choice of perform either: the operation indicated by the request as extended by the control or the operation indicated by the request. Performing some other operation is not an option. >For example, a control specification for a tree delete control should include a discussion of considerations relating to application of the control in a distributed environment or across different contexts, regardless of what [protocols] may say. From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 1 02:13:56 2005 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 CAA12395 for ; Fri, 1 Apr 2005 02:13:55 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j317CVgD049761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 07:12:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j317507J049606; Fri, 1 Apr 2005 07:05:00 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, 1 Apr 2005 07:05:00 +0000 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3174txH049589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 07:04:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050331223605.031f5130@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 31 Mar 2005 23:04:33 -0800 To: Mark Ennis From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-ldapbis-protocol - controls Cc: Jim Sermersheim , hyc@highlandsun.com, ietf-ldapbis@OpenLDAP.org In-Reply-To: <424CE6B7.7060009@eb2bcom.com> References: <6.2.1.2.0.20050331210634.02e65aa8@mail.openldap.org> <424CE6B7.7060009@eb2bcom.com> 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-ID: ietf-ldapbis mailing list List-Unsubscribe: At 10:14 PM 3/31/2005, Mark Ennis wrote: >Kurt D. Zeilenga wrote: >>At 08:49 PM 3/31/2005, Jim Sermersheim wrote: >> >>>I believe the broad interpretation of "appropriate" leads to far >>>more interoperability problems than the narrow view. >>>I'm glad to see that you don't believe a control can be partially >>>applied. >> >>This, I think, needs to be made crystal clear. >A control which results in modification of multiple objects must not be partially applied, You're using "applied" here differently that how I, and I think Jim, used it. My point was that that a server has to apply the semantics of the request+control to the entire operation OR apply the semantics of the request (less the control) to the entire operation. It cannot invent an operation that applies applies semantics request and control not consistent with these two options. The semantics of a request+control that prescribe an operation which modified multiple DIT objects could require that all or none of these modifications are to be applied to the DIT, or it could allow that some of the modifications apply and others not. That's up to the control specification. That is NOT what I was referring to here. >but what about a control that modifies the behaviour of a query? >A control requesting extra information from each entry in a search result, for example a control to reproduce the behaviour of the modifyRightsRequest in a DAP read operation, may be partially applied, without having any serious implications. If the control specification says that the operation indicated by the request+control allows the actions to be performed on a subset of the objects, then a server is free to do that. The key here is that server is applying the semantics of request+control throughout operation. It is the semantics of the request+control which say whether or not certain actions are to be performed. >To what extent should the allowance to partially apply a control be regulated by the specification controlling the infrastructure, i.e. [protocols], versus the control specification? The control specifications defines the semantics of the operation requested by request+control. The protocol specification states how the client can request a) the operation indicated by request be performed, b) the operation indicated by request+control be performed, c) either operation be performed. When the client requests c), the server then has the choice to: 1) perform the operation indicated by the request 2) perform the operation indicated by the request+control >For example, a control specification for a tree delete control should include a discussion of considerations relating to application of the control in a distributed environment or across different contexts, regardless of what [protocols] may say. Likely so. From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 1 02:28:02 2005 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 CAA21579 for ; Fri, 1 Apr 2005 02:28:01 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j317G5h2049961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 07:26:55 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j3179rON049706; Fri, 1 Apr 2005 07:09: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); Fri, 1 Apr 2005 07:09:53 +0000 Received: from micah.software-aus.com.au (cust3103.vic01.dataco.com.au [202.63.62.31]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3179mwM049683; Fri, 1 Apr 2005 07:09:49 GMT (envelope-from mark.ennis@eb2bcom.com) Received: from [192.168.1.148] (192.168.1.148) by micah.software-aus.com.au (7.1.016.1) id 42129E3E0000355B; Fri, 1 Apr 2005 17:15:22 +1000 Message-ID: <424CF394.2040208@eb2bcom.com> Date: Fri, 01 Apr 2005 17:09:08 +1000 From: Mark Ennis User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jim Sermersheim , hyc@highlandsun.com, ietf-ldapbis@OpenLDAP.org Subject: Re: draft-ietf-ldapbis-protocol - controls References: <6.2.1.2.0.20050331210634.02e65aa8@mail.openldap.org> <424CE6B7.7060009@eb2bcom.com> <6.2.1.2.0.20050331221608.0311f2a0@mail.openldap.org> In-Reply-To: <6.2.1.2.0.20050331221608.0311f2a0@mail.openldap.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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-ID: ietf-ldapbis mailing list List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > At 10:14 PM 3/31/2005, Mark Ennis wrote: > >> Kurt D. Zeilenga wrote: >> >>> At 08:49 PM 3/31/2005, Jim Sermersheim wrote: >>> >>> >>>> I believe the broad interpretation of "appropriate" leads to >>>> far more interoperability problems than the narrow view. I'm >>>> glad to see that you don't believe a control can be partially >>>> applied. >>> >>> This, I think, needs to be made crystal clear. >> >> A control which results in modification of multiple objects must >> not be partially applied, but what about a control that modifies >> the behaviour of a query? > > > Meaning that given a request+control where the control is > non-critical, the server is to perform either the operation indicated > by the request OR to perform the operation indicated by > request+control. > > The server cannot perform a portion of the operation as indicated by > request+control and a portion of the operation as indicated by > request. For instance, it would be inappropriate for a server, in > response to a search+manageDsaIt request, to only apply the semantics > indicated by the manageDsaIt to a subset of the results. The server > is obligated to apply those semantics across all results or no > results. But this does not address a distributed environment where a server chaining a request may not know the capabilities of the servers it may chain a request to. A search request or a tree delete request may be chained to multiple servers, each with different capabilities. The only way to enforce the requirements you have stated is to never apply the control. > > >> A control requesting extra information from each entry in a search >> result, for example a control to reproduce the behaviour of the >> modifyRightsRequest in a DAP read operation, may be partially >> applied, without having any serious implications. > > > Different kind of "apply". If the prescribed semantics of the > operation indicated by request+control allow for some of these > modifications to be applied to the DIT and others not, that fine. But > if the prescribed semantics of this operation required that all or > none of these modifications to be applied to the DIT, then that's > what has to be done in performance of that operation. The example I quote is a request for information about what parts of entries are modifiable, not a request to modify anything. Again, in a distributed environment, servers supporting the control may return a control response indicating the information as requested. Servers not supporting the control may ignore the control. The application of the control in this case would be "partial" and quite safe. > > >> To what extent should the allowance to partially apply a control be >> regulated by the specification controlling the infrastructure, i.e. >> [protocols], versus the control specification? > > > The control specification defines what operation to perform in > response to a request+control message. > > Where the control is non-critical, the server has a choice of perform > either: the operation indicated by the request as extended by the > control or the operation indicated by the request. > > Performing some other operation is not an option. This assumes complete knowledge by the server of how the control will be applied over the entire area affected by the operation. In a distributed environment, this knowledge cannot be guaranteed, meaning the above requirements can only be met by never doing request+control in these circumstances. > > >> For example, a control specification for a tree delete control >> should include a discussion of considerations relating to >> application of the control in a distributed environment or across >> different contexts, regardless of what [protocols] may say. > > > From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 1 04:01:10 2005 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 EAA04051 for ; Fri, 1 Apr 2005 04:01:10 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j318kWu3054367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 08:59:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j318iIFq054283; Fri, 1 Apr 2005 08:44:18 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, 1 Apr 2005 08:44:18 +0000 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j318iDOu054263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 08:44:13 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050331234443.02dbc6a0@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 01 Apr 2005 00:43:50 -0800 To: Mark Ennis From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-ldapbis-protocol - controls Cc: Jim Sermersheim , hyc@highlandsun.com, ietf-ldapbis@OpenLDAP.org In-Reply-To: <424CF394.2040208@eb2bcom.com> References: <6.2.1.2.0.20050331210634.02e65aa8@mail.openldap.org> <424CE6B7.7060009@eb2bcom.com> <6.2.1.2.0.20050331221608.0311f2a0@mail.openldap.org> <424CF394.2040208@eb2bcom.com> 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-ID: ietf-ldapbis mailing list List-Unsubscribe: At 11:09 PM 3/31/2005, Mark Ennis wrote: >Kurt D. Zeilenga wrote: >>At 10:14 PM 3/31/2005, Mark Ennis wrote: >> >>>Kurt D. Zeilenga wrote: >>> >>>>At 08:49 PM 3/31/2005, Jim Sermersheim wrote: >>>> >>>>>I believe the broad interpretation of "appropriate" leads to >>>>>far more interoperability problems than the narrow view. I'm >>>>>glad to see that you don't believe a control can be partially applied. >>>>This, I think, needs to be made crystal clear. >>>A control which results in modification of multiple objects must >>>not be partially applied, but what about a control that modifies >>>the behaviour of a query? >> >>Meaning that given a request+control where the control is >>non-critical, the server is to perform either the operation indicated >>by the request OR to perform the operation indicated by >>request+control. >>The server cannot perform a portion of the operation as indicated by >>request+control and a portion of the operation as indicated by >>request. For instance, it would be inappropriate for a server, in >>response to a search+manageDsaIt request, to only apply the semantics >>indicated by the manageDsaIt to a subset of the results. The server >>is obligated to apply those semantics across all results or no >>results. >But this does not address a distributed environment where a server chaining a request may not know the capabilities of the servers it may chain a request to. Some operations cannot be chained, or easily chained. That's a issue with their specification. That is, if the semantics of that operation (whether defined solely by a request, or defined by a request plus some number of controls) allow different actions to be applied to entries of interest, then that's that. If the specification of that operation requires that the same actions be all entries, then that's that. The server cannot do the former when specification prescribes the latter. But where the client has requested that either operation X or Y be performed, the server has a choice of doing either X or Y. But it cannot do Z. >A search request or a tree delete request may be chained to multiple servers, each with different capabilities. The only way to enforce the requirements you have stated is to never apply the control. Depends on the semantics of the operation (defined by the request+control, as specified in the control specification). The protocol specification is not defining the semantics of operations defined by request+control. The protocol specification is defining what operations may choose between to perform. A client sending a request with a non-critical control is requesting one of the following be performed: a) operation defined by request+control b) operation defined by request (less control) Howard and I argue that the server choose b) if it unable or unwilling to do a). The server does not have the option (c) to perform operation a) on a fraction of the entries of interest and operation b) on the another fraction of the entries of interest. Note that if a) allowed different actions to be applied to different fractions of entries of interest, while the server would have the option to do so, that's part of a). That is, options with a) shouldn't be regarded as a new operation (c), but as options within the operation (a). >>>A control requesting extra information from each entry in a search >>>result, for example a control to reproduce the behaviour of the >>>modifyRightsRequest in a DAP read operation, may be partially >>>applied, without having any serious implications. >> >>Different kind of "apply". If the prescribed semantics of the operation indicated by request+control allow for some of these modifications to be applied to the DIT and others not, that fine. But >>if the prescribed semantics of this operation required that all or >>none of these modifications to be applied to the DIT, then that's >>what has to be done in performance of that operation. >The example I quote is a request for information about what parts of entries are modifiable, not a request to modify anything. Matters not to my argument. See below. >Again, in a distributed environment, servers supporting the control may return a control response indicating the information as requested. Servers not supporting the control may ignore the control. Depends on the specification of the operation indicated by the request+control. If the specification says MUST provide the requested information for each entry returned, then the server violates the protocol if it returns an entry without that information. If on the other hand, the specification says the information is OPTIONAL, then the server need not ever return the information. >The application of the control in this case would be "partial" and quite safe. If the control specification says the extra information MUST be returned, it is not safe nor appropriate for the server to ignore that MUST. >>>To what extent should the allowance to partially apply a control be >>>regulated by the specification controlling the infrastructure, i.e. >>>[protocols], versus the control specification? >> >>The control specification defines what operation to perform in >>response to a request+control message. >>Where the control is non-critical, the server has a choice of perform >>either: the operation indicated by the request as extended by the >>control or the operation indicated by the request. >>Performing some other operation is not an option. >This assumes complete knowledge by the server of how the control will be applied over the entire area affected by the operation. I am assuming that the server is providing requested service. If that service requires knowledge to perform that the server doesn't have, then the server shouldn't perform that operation. If it has the choice of performing another operation (by ignoring a non-critical control), it would be appropriate for it to give that a go. That operation might require knowledge the server doesn't have either, in that case, if there or no other operations to choose from (no more controls to ignore), an error will have to be returned. >In a distributed environment, this knowledge cannot be guaranteed, meaning the above requirements can only be met by never doing request+control in these circumstances. In a distributed environments, knowledge for any operation, including base operations, is not guaranteed. >>>For example, a control specification for a tree delete control >>>should include a discussion of considerations relating to >>>application of the control in a distributed environment or across >>>different contexts, regardless of what [protocols] may say. >> From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 1 11:20:46 2005 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 LAA09855 for ; Fri, 1 Apr 2005 11:20:46 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31GG8to076619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 16:19:31 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j31GAO5Z076491; Fri, 1 Apr 2005 16:10:24 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 1 Apr 2005 16:10:24 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31GAL48076470; Fri, 1 Apr 2005 16:10:21 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 01 Apr 2005 09:10:00 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Fri, 01 Apr 2005 09:09:34 -0700 From: "Jim Sermersheim" To: Cc: , , Subject: Re: draft-ietf-ldapbis-protocol - controls Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part3B18392E.2__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-ID: ietf-ldapbis mailing list 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. --=__Part3B18392E.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable >>> "Kurt D. Zeilenga" 3/31/05 10:43:16 PM >>> >I think s/appropriate/appropriate in the server's determination/ >would be appropriately vague. If the WG is fine with the added behavioral differences (at the benefit of = added service) this brings, then fine. We can update with this, and even = add that the operation + any controls is not to be applied in a partial = manner. =20 It's still confusing to implementors and clients. Does "appropriate for = the operation in the server's determination" extend to include "and the = server is willing to perform it"? Meaning, if the server can (at some = early or pre stage) determine that the user has insufficient rights to = perform the operation + non-critical control, can it ignore the control? = "Appropriate for the operation" (whether determined by the server or not), = still seems to me to indicate that the control specification named that = operation as one valid for the control to be attached. =20 I'm not sure the reader is left with an any more clear understanding of = how to implement or what to expect. If we want the behavior to be what you = and Howard are suggesting, then I think replacing the word "appropriate" = altogether is better. It should say "If the server is able and willing to = support...".=20 =20 That's what you're really saying isn't it? --=__Part3B18392E.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 3/31/05 = 10:43:16 PM >>>
<snip>

>I think s/appropriate/appropriate in the server's determinatio= n/
>would be appropriately vague.
If the WG is fine with the added behavioral differences (at the = benefit of added service) this brings, then fine. We can update with this, = and even add that the operation + any controls is not to be applied in a = partial manner.
 
It's still confusing to implementors and clients. Does "appropriate = for the operation in the server's determination" extend to include "and = the server is willing to perform it"? Meaning, if the server can (at some = early or pre stage) determine that the user has insufficient rights to = perform the operation + non-critical control, can it ignore the control? = "Appropriate for the operation" (whether determined by the server or not), = still seems to me to indicate that the control specification named that = operation as one valid for the control to be attached.
 
I'm not sure the reader is left with an any more clear understanding = of how to implement or what to expect. If we want the behavior to be what = you and Howard are suggesting, then I think replacing the word = "appropriate" altogether is better. It should say "If the server is able = and willing to support...".
 
That's what you're really saying isn't it?
--=__Part3B18392E.2__=-- From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 1 11:20:50 2005 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 LAA09892 for ; Fri, 1 Apr 2005 11:20:50 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31GG8tq076619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 16:19:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j31GC9XZ076564; Fri, 1 Apr 2005 16:12:09 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 1 Apr 2005 16:12:09 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31GC6u4076515; Fri, 1 Apr 2005 16:12:06 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 01 Apr 2005 09:11:46 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Fri, 01 Apr 2005 09:11:23 -0700 From: "Jim Sermersheim" To: Cc: , , Subject: Re: draft-ietf-ldapbis-protocol - controls Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartAE8DACBB.2__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-ID: ietf-ldapbis mailing list 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. --=__PartAE8DACBB.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable >I am not suggesting that servers do any back-tracking to mitigate the=20 >failures encountered while processing a request accompanied by=20 >non-critical controls. Only stating that the presence of a non-critical=20= >control should not cause a server to choose not to *begin* executing = the=20 >accompanying request. Once the server has decided to begin executing = the=20 >request, any incidental errors should of course be reported back to = the=20 >client as usual. Servers deciding what it means to "begin execution" is what will cause = confusion and different implementations to behave contrary to clients = expectations. =20 Some servers might, during the process of name resolution, discover that = the non-critical control is not allowed or supported in that part of the = tree, and drop it. If this is a "dereferenceAliases" control, then = dropping it at this point may constitute partial service of the control. = If it's a different control, it may be safe to ignore the control after, = or during, name resolution. =20 Some servers might evaluate a search request, apply the filter to the = backing database, and not until the first object candidate is located peer = into the ber packet holding the attribute selection list. At this point = the server may decide that a non-critical control is at odds with = something in the selection list. Now, this server may safely ignore the = control, but ignoring the control might (or might not) require the server = to re-apply the original filter to the backing database, so instead, it = might just choose to fail the operation. =20 Re-reading your original post, I think slapd is being overly strict = anyway. The control was in fact not recognized by the ultimate service it = was sent to and thus should have been dropped (if not also being used in = other contexts). This is the same as a non-critical control attached to a = request which immediately chains to another server (with no part of the = operation being affected prior to the chaining). In other words, if the = server can determine that the non-critical control is not recognized or = appropriate for the operation, then it can ignore it (as long as it can = ensure it will not be applied partially). Changing the definition of = appropriate *might* alleviate part of your original concern, and it might = not. If a non-critical manageDSAit is attached, it can be ignored if it is = known that it will only be applied to a single context/backend. But if the = request can span backends, or will be chained, then the original problem = is still there. =20 =20 --=__PartAE8DACBB.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<snip>
>I am not suggesting that servers do any back-track= ing to mitigate the
>failures encountered while processing a = request accompanied by
>non-critical controls. Only stating that = the presence of a non-critical
>control should not cause a server = to choose not to *begin* executing the
>accompanying request. Once = the server has decided to begin executing the
>request, any = incidental errors should of course be reported back to the
>client = as usual.

Servers deciding what it means to "begin execution" is = what will cause confusion and different implementations to behave contrary = to clients expectations.
 
Some servers might, during the process of name resolution, = discover that the non-critical control is not allowed or supported in that = part of the tree, and drop it. If this is a "dereferenceAliases" control, = then dropping it at this point may constitute partial service of the = control. If it's a different control, it may be safe to ignore the control = after, or during, name resolution.
 
Some servers might evaluate a search request, apply the filter to the = backing database, and not until the first object candidate is located peer = into the ber packet holding the attribute selection list. At this point = the server may decide that a non-critical control is at odds with = something in the selection list. Now, this server may safely ignore the = control, but ignoring the control might (or might not) require the server = to re-apply the original filter to the backing database, so instead, it = might just choose to fail the operation.
 
Re-reading your original post, I think slapd is being overly stri= ct anyway. The control was in fact not recognized by the ultimate service = it was sent to and thus should have been dropped (if not also being used = in other contexts). This is the same as a non-critical control attached to = a request which immediately chains to another server (with no part of the = operation being affected prior to the chaining). In other words, if the = server can determine that the non-critical control is not recognized or = appropriate for the operation, then it can ignore it (as long as it can = ensure it will not be applied partially). Changing the definition of = appropriate *might* alleviate part of your original concern, and it might = not. If a non-critical manageDSAit is attached, it can be ignored if it is = known that it will only be applied to a single context/backend. But if the = request can span backends, or will be chained, then the original problem = is still there.
 
 
--=__PartAE8DACBB.2__=-- From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 1 11:47:46 2005 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 LAA13949 for ; Fri, 1 Apr 2005 11:47:45 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31Gduja077702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 16:46:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j31GQ02S077122; Fri, 1 Apr 2005 16:26:00 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, 1 Apr 2005 16:26:00 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31GPwsJ077110 for ; Fri, 1 Apr 2005 16:25:59 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 01 Apr 2005 09:25:38 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Fri, 01 Apr 2005 09:25:12 -0700 From: "Jim Sermersheim" To: Subject: Fwd: Re: draft-ietf-ldapbis-protocol - controls Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartEAC9E8F8.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-ID: ietf-ldapbis mailing list 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. --=__PartEAC9E8F8.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I also think we are not actually solving the real original issues of: =20 a) how does a server fronting other servers/services advertise support for = extensions b) how does that server treat non-critical controls as they are applied = over the distributed servers/services >>> Jim Sermersheim 4/1/05 9:23:30 AM >>> >>> Jim Sermersheim 4/1/05 9:09:34 AM >>> >>> "Kurt D. Zeilenga" 3/31/05 10:43:16 PM >>> >I think s/appropriate/appropriate in the server's determination/ >would be appropriately vague. If the WG is fine with the added behavioral differences (at the benefit of = added service) this brings, then fine. We can update with this, and even = add that the operation + any controls is not to be applied in a partial = manner. =20 It's still confusing to implementors and clients. Does "appropriate for = the operation in the server's determination" extend to include "and the = server is willing to perform it"? Meaning, if the server can (at some = early or pre stage) determine that the user has insufficient rights to = perform the operation + non-critical control, can it ignore the control? = "Appropriate for the operation" (whether determined by the server or not), = still seems to me to indicate that the control specification named that = operation as one valid for the control to be attached. =20 I'm not sure the reader is left with an any more clear understanding of = how to implement or what to expect. If we want the behavior to be what you = and Howard are suggesting, then I think replacing the word "appropriate" = altogether is better. It should say "If the server is able and willing to = support...".=20 =20 That's what you're really saying isn't it? --=__PartEAC9E8F8.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I also think we are not actually solving the real original issues = of:
 
a) how does a server fronting other servers/services advertise = support for extensions
b) how does that server treat non-critical controls as they are = applied over the distributed servers/services


>>> = Jim Sermersheim 4/1/05 9:23:30 AM >>>


>>> Jim = Sermersheim 4/1/05 9:09:34 AM >>>
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 3/31/05 = 10:43:16 PM >>>
<snip>

>I think s/appropriate/appropriate in the server's determinatio= n/
>would be appropriately vague.
If the WG is fine with the added behavioral differences (at the = benefit of added service) this brings, then fine. We can update with this, = and even add that the operation + any controls is not to be applied in a = partial manner.
 
It's still confusing to implementors and clients. Does "appropriate = for the operation in the server's determination" extend to include "and = the server is willing to perform it"? Meaning, if the server can (at some = early or pre stage) determine that the user has insufficient rights to = perform the operation + non-critical control, can it ignore the control? = "Appropriate for the operation" (whether determined by the server or not), = still seems to me to indicate that the control specification named that = operation as one valid for the control to be attached.
 
I'm not sure the reader is left with an any more clear understanding = of how to implement or what to expect. If we want the behavior to be what = you and Howard are suggesting, then I think replacing the word = "appropriate" altogether is better. It should say "If the server is able = and willing to support...".
 
That's what you're really saying isn't it?
--=__PartEAC9E8F8.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 1 12:23:17 2005 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 MAA18386 for ; Fri, 1 Apr 2005 12:23:16 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31HImxO080037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 17:18:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j31H41kM079323; Fri, 1 Apr 2005 17:04: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, 1 Apr 2005 17:04:01 +0000 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31H3v2O079294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 17:03:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050401084332.05c2cba0@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 01 Apr 2005 09:03:34 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-ldapbis-protocol - controls 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-ID: ietf-ldapbis mailing list List-Unsubscribe: Jim, Under the current [Protocol] wording, the server which recognizes a control properly attached to a request is obligated to make use of that control in performance of the operation. As this establishes a client expectation, that server is not freed from this obligation to the client simply because it chooses to chain the whole operation to another server. And that's a major problem. [Protocol] has established the wrong client expectation. The client expectation of a request+control where the control is non-critical is for the directory service (whether involving one or many servers) will provide service by either performing the operation indicated by the request+control or the operation indicated by the request, and hence, that all discernable outcomes of the operation performed including all intermediate and final results, all DIT changes, etc.) will be entirely consistent with the choice the service makes. As long as the service has yet to produce an outcome that has a discernable difference between the choices, the service maintains the choice. Once it has produced an outcome which has discernable difference, the service is locked into its choice. But we don't need to confuse folks with "begin execution" stuff. We simply need to say something like: If the server recognizes the control type and it is appropriate (in the server's determination) for the operation, the server will perform the requested operation as extended by control. Otherwise, ... Kurt At 08:11 AM 4/1/2005, Jim Sermersheim wrote: > >>I am not suggesting that servers do any back-tracking to mitigate the >>failures encountered while processing a request accompanied by >>non-critical controls. Only stating that the presence of a non-critical >>control should not cause a server to choose not to *begin* executing the >>accompanying request. Once the server has decided to begin executing the >>request, any incidental errors should of course be reported back to the >>client as usual. > >Servers deciding what it means to "begin execution" is what will cause confusion and different implementations to behave contrary to clients expectations. > >Some servers might, during the process of name resolution, discover that the non-critical control is not allowed or supported in that part of the tree, and drop it. If this is a "dereferenceAliases" control, then dropping it at this point may constitute partial service of the control. If it's a different control, it may be safe to ignore the control after, or during, name resolution. > >Some servers might evaluate a search request, apply the filter to the backing database, and not until the first object candidate is located peer into the ber packet holding the attribute selection list. At this point the server may decide that a non-critical control is at odds with something in the selection list. Now, this server may safely ignore the control, but ignoring the control might (or might not) require the server to re-apply the original filter to the backing database, so instead, it might just choose to fail the operation. > >Re-reading your original post, I think slapd is being overly strict anyway. The control was in fact not recognized by the ultimate service it was sent to and thus should have been dropped (if not also being used in other contexts). This is the same as a non-critical control attached to a request which immediately chains to another server (with no part of the operation being affected prior to the chaining). In other words, if the server can determine that the non-critical control is not recognized or appropriate for the operation, then it can ignore it (as long as it can ensure it will not be applied partially). Changing the definition of appropriate *might* alleviate part of your original concern, and it might not. If a non-critical manageDSAit is attached, it can be ignored if it is known that it will only be applied to a single context/backend. But if the request can span backends, or will be chained, then the original problem is still there. > > From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 1 13:35:06 2005 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 NAA24754 for ; Fri, 1 Apr 2005 13:35:05 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31IFuIH082337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 18:33:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j31I6SVw081948; Fri, 1 Apr 2005 18:06: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); Fri, 1 Apr 2005 18:06:28 +0000 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31I6QXQ081912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 18:06:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050401093119.05c51988@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 01 Apr 2005 10:06:03 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Fwd: Re: draft-ietf-ldapbis-protocol - controls 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-ID: ietf-ldapbis mailing list List-Unsubscribe: At 08:25 AM 4/1/2005, Jim Sermersheim wrote: >I also think we are not actually solving the real original issues of: > >a) how does a server fronting other servers/services advertise support for extensions A server only publishes what controls it recognizes. The client's expectation is that a server will ignore any control which the server doesn't recognize. However, the client should expect servers to ignore other non-critical controls, as the server might implement a different specification which considers the control not to be applicable, or the server is otherwise unwilling or able to perform the operation as extended by these controls. As you noted, this expectation is necessary to set if were ever going to support distributed directory services. The issue now is whether the client expects the server to return an error in this case, or does the client expect the server to ignore the non-critical controls in performing the operation. I believe it reasonable and quite appropriate for clients to expect servers to provide service when the able and willing. >b) how does that server treat non-critical controls as they are applied over the distributed servers/services The same as it would in single server system... in a manner consistent with the client's expectations. Or more to the point, the client's expectations are the same regardless of whether the service is distributed or not. Why do you think the server is free to ignore some or all of those expectations simply because it fronting a distributed service? Kurt >>>> Jim Sermersheim 4/1/05 9:23:30 AM >>> > > >>>> Jim Sermersheim 4/1/05 9:09:34 AM >>> >>>> "Kurt D. Zeilenga" 3/31/05 10:43:16 PM >>> > > >>I think s/appropriate/appropriate in the server's determination/ >>would be appropriately vague. >If the WG is fine with the added behavioral differences (at the benefit of added service) this brings, then fine. We can update with this, and even add that the operation + any controls is not to be applied in a partial manner. > >It's still confusing to implementors and clients. Does "appropriate for the operation in the server's determination" extend to include "and the server is willing to perform it"? Meaning, if the server can (at some early or pre stage) determine that the user has insufficient rights to perform the operation + non-critical control, can it ignore the control? "Appropriate for the operation" (whether determined by the server or not), still seems to me to indicate that the control specification named that operation as one valid for the control to be attached. > >I'm not sure the reader is left with an any more clear understanding of how to implement or what to expect. If we want the behavior to be what you and Howard are suggesting, then I think replacing the word "appropriate" altogether is better. It should say "If the server is able and willing to support...". > >That's what you're really saying isn't it? From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 1 13:38:29 2005 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 NAA25120 for ; Fri, 1 Apr 2005 13:38:28 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31IbRKo083611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 18:37:27 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j31IRdn0082970; Fri, 1 Apr 2005 18:27:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 1 Apr 2005 18:27:39 +0000 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31IRadY082938; Fri, 1 Apr 2005 18:27:37 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 01 Apr 2005 11:27:16 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Fri, 01 Apr 2005 11:26:57 -0700 From: "Jim Sermersheim" To: Cc: Subject: Re: Fwd: Re: draft-ietf-ldapbis-protocol - controls Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part94B79661.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-ID: ietf-ldapbis mailing list 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. --=__Part94B79661.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable >>> "Kurt D. Zeilenga" 4/1/05 11:06:03 AM >>> >At 08:25 AM 4/1/2005, Jim Sermersheim wrote: >>I also think we are not actually solving the real original issues of: >>=20 >>a) how does a server fronting other servers/services advertise support = for extensions > >A server only publishes what controls it recognizes. The >client's expectation is that a server will ignore any control >which the server doesn't recognize. However, the client >should expect servers to ignore other non-critical controls, >as the server might implement a different specification >which considers the control not to be applicable, or >the server is otherwise unwilling or able to perform the >operation as extended by these controls. As you noted, >this expectation is necessary to set if were ever going >to support distributed directory services. > >The issue now is whether the client expects the server to >return an error in this case, or does the client expect >the server to ignore the non-critical controls in >performing the operation. I believe it reasonable and >quite appropriate for clients to expect servers to >provide service when the able and willing. > >>b) how does that server treat non-critical controls as they are applied = over the distributed servers/services > >The same as it would in single server system... in >a manner consistent with the client's expectations. > >Or more to the point, the client's expectations are the >same regardless of whether the service is distributed or >not. Why do you think the server is free to ignore >some or all of those expectations simply because it >fronting a distributed service? I don't. What I'm saying is there was a message from Howard which seemed = to me to raise these two issues (a and b). Relaxing what "appropriate" = means doesn't address either of these issues. Maybe I'm wrong and the only = issue raised was that we want "appropriate for the operation" to mean more = than specified as appropriate for the operation by the control spec. No = response is needed though, I'm too tired of this issue to argue anymore, = no one else is concerned. I'll make the change. --=__Part94B79661.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>> "Kurt = D. Zeilenga" <Kurt@OpenLDAP.org> 4/1/05 11:06:03 AM >>>
&= gt;At 08:25 AM 4/1/2005, Jim Sermersheim wrote:
>>I also think we = are not actually solving the real original issues of:
>> =
>>a) how does a server fronting other servers/services advertise = support for extensions
>
>A server only publishes what = controls it recognizes. The
>client's expectation is that a server = will ignore any control
>which the server doesn't recognize. = However, the client
>should expect servers to ignore other non-critic= al controls,
>as the server might implement a different specification=
>which considers the control not to be applicable, or
>the = server is otherwise unwilling or able to perform the
>operation as = extended by these controls. As you noted,
>this expectation is = necessary to set if were ever going
>to support distributed = directory services.
>
>The issue now is whether the client = expects the server to
>return an error in this case, or does the = client expect
>the server to ignore the non-critical controls = in
>performing the operation. I believe it reasonable and
>quit= e appropriate for clients to expect servers to
>provide service when = the able and willing.
>
>>b) how does that server treat = non-critical controls as they are applied over the distributed servers/serv= ices
>
>The same as it would in single server system... = in
>a manner consistent with the client's expectations.
>
&g= t;Or more to the point, the client's expectations are the
>same = regardless of whether the service is distributed or
>not. Why do you = think the server is free to ignore
>some or all of those expectations= simply because it
>fronting a distributed service?

I don't. = What I'm saying is there was a message from Howard which seemed to me to = raise these two issues (a and b). Relaxing what "appropriate" means = doesn't address either of these issues. Maybe I'm wrong and the only issue = raised was that we want "appropriate for the operation" to mean more than = specified as appropriate for the operation by the control spec. No = response is needed though, I'm too tired of this issue to argue anymore, = no one else is concerned. I'll make the change. --=__Part94B79661.0__=-- From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 1 14:26:48 2005 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 OAA28212 for ; Fri, 1 Apr 2005 14:26:47 -0500 (EST) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31JPnTX086649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 19:26:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j31J7ET4085390; Fri, 1 Apr 2005 19:07:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 1 Apr 2005 19:07:14 +0000 Received: from highlandsun.propagation.net (highlandsun.propagation.net [66.221.212.168]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j31J7BhH085371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 19:07:12 GMT (envelope-from hyc@highlandsun.com) Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id j31J73fk004158; Fri, 1 Apr 2005 13:07:03 -0600 Message-ID: <424D9BE1.8080508@highlandsun.com> Date: Fri, 01 Apr 2005 11:07:13 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050322 MIME-Version: 1.0 To: Jim Sermersheim CC: Kurt@OpenLDAP.org, ietf-ldapbis@OpenLDAP.org Subject: Re: Fwd: Re: draft-ietf-ldapbis-protocol - controls References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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-ID: ietf-ldapbis mailing list List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > >>> "Kurt D. Zeilenga" 4/1/05 11:06:03 AM >>> > >At 08:25 AM 4/1/2005, Jim Sermersheim wrote: > >>I also think we are not actually solving the real original issues of: > >> > >>a) how does a server fronting other servers/services advertise > support for extensions > >>b) how does that server treat non-critical controls as they are > applied over the distributed servers/services > > > >The same as it would in single server system... in > >a manner consistent with the client's expectations. > > > >Or more to the point, the client's expectations are the > >same regardless of whether the service is distributed or > >not. Why do you think the server is free to ignore > >some or all of those expectations simply because it > >fronting a distributed service? > > I don't. What I'm saying is there was a message from Howard which seemed > to me to raise these two issues (a and b). Relaxing what "appropriate" > means doesn't address either of these issues. Maybe I'm wrong and the > only issue raised was that we want "appropriate for the operation" to > mean more than specified as appropriate for the operation by the control > spec. No response is needed though, I'm too tired of this issue to argue > anymore, no one else is concerned. I'll make the change. Yes, I raised at least (a) but only to provide background for the current problem. I think it might be nice if we had a mechanism for advertising support that worked for this case, but I'm not looking to design it today, here in LDAPbis. Sorry if that muddied the water too much. -- -- 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 Mon Apr 4 15:57:46 2005 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 PAA22138 for ; Mon, 4 Apr 2005 15:57:45 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j34JqhEh088535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2005 19:56:08 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j34JpeIU088520; Mon, 4 Apr 2005 19:51:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 4 Apr 2005 19:51:40 +0000 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j34JpcxD088511 for ; Mon, 4 Apr 2005 19:51:38 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 PAA19505; Mon, 4 Apr 2005 15:51:35 -0400 (EDT) Message-Id: <200504041951.PAA19505@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ldapbis@OpenLDAP.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapbis-user-schema-09.txt Date: Mon, 04 Apr 2005 15:51:35 -0400 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-ID: ietf-ldapbis mailing list 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: Schema for User Applications Author(s) : A. Sciberras Filename : draft-ietf-ldapbis-user-schema-09.txt Pages : 35 Date : 2005-4-4 This document is a integral part of the Lightweight Directory Access Protocol (LDAP) technical specification [ROADMAP]. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as, White Pages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-user-schema-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapbis-user-schema-09.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-user-schema-09.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: <2005-4-4161305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapbis-user-schema-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapbis-user-schema-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-4161305.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldapbis@OpenLDAP.org Mon Apr 4 18:33:39 2005 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 SAA20216 for ; Mon, 4 Apr 2005 18:33:39 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j34MScDi094108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2005 22:32:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j34MQ0GN094087; Mon, 4 Apr 2005 22:26:00 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, 4 Apr 2005 22:26:00 +0000 Received: from amos.eb2bcom.com (cust3103.vic01.dataco.com.au [202.63.62.31]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j34MPpiG094078 for ; Mon, 4 Apr 2005 22:25:55 GMT (envelope-from andrew.sciberras@eB2Bcom.com) Received: from [192.168.1.159] (10.1.2.225) by amos.eb2bcom.com (7.1.016.1) (authenticated as andrew.sciberras) id 4236430A00001CD8 for ietf-ldapbis@OpenLDAP.org; Tue, 5 Apr 2005 08:35:46 +1000 Message-ID: <4251BF05.3020205@eB2Bcom.com> Date: Tue, 05 Apr 2005 08:26:13 +1000 From: Andrew Sciberras Reply-To: andrew.sciberras@eB2Bcom.com Organization: eB2Bcom User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ldapbis@OpenLDAP.org Subject: Re: I-D ACTION:draft-ietf-ldapbis-user-schema-09.txt References: <200504041951.PAA19505@ietf.org> In-Reply-To: <200504041951.PAA19505@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; 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-ID: ietf-ldapbis mailing list List-Unsubscribe: Content-Transfer-Encoding: 7bit As you may have noticed, version -09 of User Schema has now been made available. A number of changes have been made to this document, which include editorial corrections, additional examples, additional object class definitions, changes to the SYNTAX of 'c', etc. Please review this revision to ensure that the changes made appropriately address issues raised since the last revision. Thank You, Andrew Sciberras eB2Bcom Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the LDAP (v3) Revision Working Group of the IETF. > > Title : LDAP: Schema for User Applications > Author(s) : A. Sciberras > Filename : draft-ietf-ldapbis-user-schema-09.txt > Pages : 35 > Date : 2005-4-4 > > This document is a integral part of the Lightweight Directory Access > Protocol (LDAP) technical specification [ROADMAP]. It provides a > technical specification of attribute types and object classes > intended for use by LDAP directory clients for many directory > services, such as, White Pages. These objects are widely used as a > basis for the schema in many LDAP directories. This document does > not cover attributes used for the administration of directory > servers, nor does it include directory objects defined for specific > uses in other documents. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-user-schema-09.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ldapbis-user-schema-09.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-user-schema-09.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. From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 5 00:17:39 2005 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 AAA14489 for ; Tue, 5 Apr 2005 00:17:38 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j354AYCB003695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2005 04:13:58 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j3546SKq003542; Tue, 5 Apr 2005 04:06: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, 5 Apr 2005 04:06:28 +0000 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3546Ps8003516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Apr 2005 04:06:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050404205945.027954a8@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 04 Apr 2005 21:06:03 -0700 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Fwd: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard 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-ID: ietf-ldapbis mailing list List-Unsubscribe: We'll need to update all LDAPBIS documents referencing RFC2234 to instead reference this I-D. Editors, please make this change in your next planned revision (but do not revise solely for this change). For documents already approved (or which are subsequently approved prior to this change being made), we'll pick the change up at AUTH48 or via an IESG note to RFC Editor. Thanks, Kurt >From: The IESG >To: IETF-Announce >Date: Mon, 04 Apr 2005 16:35:53 -0400 >Cc: Internet Architecture Board , > RFC Editor >Subject: Protocol Action: 'Augmented BNF for Syntax Specifications: > ABNF' to Draft Standard > >The IESG has approved the following document: > >- 'Augmented BNF for Syntax Specifications: ABNF ' > as a Draft Standard > >This document has been reviewed in the IETF but is not the product of an >IETF Working Group. > >The IESG contact person is Scott Hollenbeck. > >Technical Summary > >Internet technical specifications often need to define a format >syntax. Over the years a modified version of Backus-Naur Form (BNF), >called Augmented BNF (ABNF), has been popular among many Internet >specifications. The current specification documents ABNF. It >balances compactness and simplicity, with reasonable representational >power. The differences between standard BNF and ABNF involve naming >rules, repetition, alternatives, order-independence, and value >ranges. This specification also supplies additional rule definitions >and encoding for a core lexical analyzer of the type common to >several Internet specifications. > >This document obsoletes RFC 2234. > >Working Group Summary > >This document is the work of individual submitters. It was produced >to address comments received from the IESG when the IESG was asked >to elevate RFC 2234 to Draft Standard status. An IETF last call on >the request to elevate RFC 2234 was completed in June 2004. > >Protocol Quality > >Harald Alvestrand, Bill Fenner, and Scott Hollenbeck evaluated this >specification for the IESG. > >RFC Editor Note: > >Abstract and Section 1, first sentence: >OLD: >"Internet technical specifications often need to define a format" > ^^^^^^ > >NEW: >"Internet technical specifications often need to define a formal" >(change "format" to "formal") > >Section 1: >OLD: >"Changes in the latest version of this Internet Draft:" > >NEW: >"Changes Since RFC 2234:" > >Section 3.1: >OLD: >NOTE: > > NOTE: This specification for ABNF does not provide for implicit > specification of linear white space. > >NEW: > NOTE: This specification for ABNF does not provide for implicit > specification of linear white space. >(remove frist instance of "NOTE") > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 5 23:26:05 2005 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 XAA17542 for ; Tue, 5 Apr 2005 23:26:04 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j363MYLF054569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2005 03:24:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j363IDN8054510; Wed, 6 Apr 2005 03:18: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); Wed, 6 Apr 2005 03:18:13 +0000 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j363I8Vt054475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2005 03:18:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050405201247.054e2328@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 05 Apr 2005 20:17:44 -0700 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Subject: Fwd: I-D ACTION:draft-zeilenga-ldap-cosine-00.txt Cc: ietf-ldapbis@OpenLDAP.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-ID: ietf-ldapbis mailing list List-Unsubscribe: This I-D is primarily an update of RFC 1274. With LDAPBIS's user-schema I-D, and a soon to be submitted zeilenga-ldap-domains, replaces RFC 2247 as well. (I'm thinking about 2377bis as well.) My intent is to submit this for publication in conjunction with the revised LDAP TS being produced by the LDAPBIS WG. Please review. Technical comments to and editorial comments to . Thanks, Kurt >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Date: Tue, 05 Apr 2005 15:29:59 -0400 >Subject: I-D ACTION:draft-zeilenga-ldap-cosine-00.txt >Reply-To: internet-drafts@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : COSINE LDAP/X.500 Schema > Author(s) : K. Zeilenga > Filename : draft-zeilenga-ldap-cosine-00.txt > Pages : 25 > Date : 2005-4-5 > >This document provides a collection of schema elements for use with > the Lightweight Directory Access Protocol (LDAP) from the COSINE and > Internet X.500 pilot projects. > > This document obsoletes RFC 1274 and RFC 2247. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-cosine-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-zeilenga-ldap-cosine-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-zeilenga-ldap-cosine-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <2005-4-5160053.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-zeilenga-ldap-cosine-00.txt > > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 8 07:01:43 2005 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 HAA03024 for ; Fri, 8 Apr 2005 07:01:43 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j38AxQ1i081671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2005 10:59:55 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j38Av6RZ081630; Fri, 8 Apr 2005 10:57:06 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) X-Authentication-Warning: boole.openldap.org: majordomo owned process doing -bs Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 8 Apr 2005 10:57:06 +0000 Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j38Av36c081610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Apr 2005 10:57:04 GMT (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.4+UW05.03/8.13.3+UW05.01) with ESMTP id j38Av3aC011067 for ; Fri, 8 Apr 2005 03:57:03 -0700 Received: from [192.168.1.101] (c-67-170-101-104.hsd1.wa.comcast.net [67.170.101.104]) (authenticated bits=0) by smtp.washington.edu (8.13.4+UW05.03/8.13.3+UW05.01) with ESMTP id j38Av226019886 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 8 Apr 2005 03:57:02 -0700 Message-ID: <4256637E.3030807@washington.edu> Date: Fri, 08 Apr 2005 03:57:02 -0700 From: "RL 'Bob' Morgan" User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF ldapbis WG Subject: draft minutes for ldapbis WG meeting at IETF 62 Content-Type: text/plain; charset=ISO-8859-1; 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-ID: ietf-ldapbis mailing list List-Unsubscribe: Content-Transfer-Encoding: 7bit Draft minutes for the March meeting, corrections to the list please. - RL "Bob" --- ldapbis WG meeting IETF 62, Minneapolis, MN USA 2005-03-10 scribe: RL "Bob" Morgan The meeting was called to order at 1530 by co-chairs Kurt and Bob. Kurt reviewed the status of WG documents. The syntaxes and ldapprep documents are ready to be advanced to the IESG. The chairs are seeking a new author for the schema document, to finish up a couple of small issues and get it to the IESG. The models, filter, DN, and URL documents are all approved by the IESG and waiting in the RFC Editor queue. The BCP64bis and roadmap documents are ready for WG last call. The strprep document has already been through WG last call, but a couple of issues have recently been discussed on the list, in particular handling of insignificant spaces in substring matching. The latest draft (draft-ietf-ldapbis-strprep-05.txt) contains Kurt's proposed solution to this issue: to conceptually expand foo[space]bar into foo[space space]bar; a rationale is provided in Appendix B of the document. Bob (as co-chair) will assess consensus on this point to try to close the issue. A new topic has to do with handling "failures" in string mapping and whether "troublesome" characters should be permitted. The latest draft takes the position that they should not be, and Kurt (as editor) believes there is consensus on this point. Others present at the meeting (Jim Sermersheim and Roger Harrison) agree with this approach but think more discussion may be necessary. Jim Sermersheim discussed the protocol document (draft-ietf-ldapbis-protocol-30.txt). There is still some work to clarify the use of attributes and subtypes in search filters and search selection lists. There has been discussion of TLS layer removal and the effect of changes in TLS ciphersuites. The general approach is to remove from the document prescriptive text that is unnecessarily restrictive to implementations. For example it should not say that a client should "drop all PDUs after sending a closure alert", since the client may want to process a server close message. Language will have to be added to cover the security considerations of TLS ciphersuite changes. Kurt suggests that in general security factors will change throughout the life of an LDAP session, and that these are inputs to client and server policy. The standard can't prescribe all the effects since policies will be deployment-specific. For example, the openldap server is choosing to close a connection when its ciphersuite changes. Jim commented that some cleanup is needed in the document regarding the use of "PDU". Jim will submit a new rev of the document when the WG has come to consensus on these remaining points. The chairs will follow with a message to the list confirming that the new rev is OK, and if so will return the document to the IESG. Roger Harrison discussed the authmeth document (draft-ietf-ldapbis-authmeth-14.txt). Changes were made to reflect the consensus on terminology for connection/session/etc. The "association" term still has to be removed. Roger commented that given recent changes the state table has been reduced even more, and may be at the point of no longer being useful in the document, ie it was useful as a design tool but not as documentation. There was agreement on this point. In discussing handling of SASL-expressed authorization IDs, Kurt said it's important to remember that LDAP does not standardize and authorization model. Roger noted that a recently raised issue has to do with clarifying how a client should do matching on different types of subjectAltNames in certificates presented by servers via TLS. E.g., matching rules for DNS names are different from those for URIs. The draft RFC 3280bis has guidance on this (for its own purposes), so the LDAP document should base its language on the same matching specs used there. Kurt said that for example if a DNS name is an IDN, that the rule should be to use the toASCII conversion and use the result of that for matching. Roger also noted that the language about authorization factors should be made less prescriptive. Roger hopes to produce a -15 rev by April 8, and that that rev would be ready for WG last call. Kurt reviewed WG milestones. The key milestone is to deliver the entire revised LDAP technical specification to the IESG by April 2005, so this means proceeding with last call on authmeth in April, clearing up any remaining issues with other docs, and issuing a last call for the roadmap document in April. BCP64bis can be WGLC'd in May, and that would conclude outstanding items for the WG. Kurt noted that a Paris meeting, if held, would likely consider new work. The meeting was concluded at 1620. From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 15 13:22:19 2005 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 NAA23344 for ; Fri, 15 Apr 2005 13:22:18 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3FHJJJW001593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2005 17:20:57 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j3FHGktA001463; Fri, 15 Apr 2005 17:16:46 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, 15 Apr 2005 17:16:46 +0000 Received: from newodin.ietf.org ([132.151.6.50]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3FHGiRC001439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Apr 2005 17:16:45 GMT (envelope-from apache@newodin.ietf.org) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DMUQt-00046g-Oc; Fri, 15 Apr 2005 13:16:43 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'LDAP: The Protocol' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Fri, 15 Apr 2005 13:16:43 -0400 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-ID: ietf-ldapbis mailing list List-Unsubscribe: The IESG has received a request from the LDAP (v3) Revision WG to consider the following document: - 'LDAP: The Protocol ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-29. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-30.txt From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 15 13:52:45 2005 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 NAA26675 for ; Fri, 15 Apr 2005 13:52:45 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3FHpXKk002803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2005 17:51:36 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j3FHiVpn002631; Fri, 15 Apr 2005 17:44:31 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, 15 Apr 2005 17:44:31 +0000 Received: from boole.openldap.org (kurt@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3FHiUe0002621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Apr 2005 17:44:30 GMT (envelope-from kurt@boole.openldap.org) Received: (from kurt@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) id j3FHiU6M002620 for ietf-ldapbis@openldap.org; Fri, 15 Apr 2005 10:44:30 -0700 (PDT) (envelope-from kurt) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3FHgqaU002556 for ; Fri, 15 Apr 2005 17:42:52 GMT (envelope-from braden@ISI.EDU) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j3FHg8619649; Fri, 15 Apr 2005 10:42:08 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA01041; Fri, 15 Apr 2005 10:42:08 -0700 (PDT) Date: Fri, 15 Apr 2005 10:42:08 -0700 (PDT) Message-Id: <200504151742.KAA01041@gra.isi.edu> To: iesg@ietf.org Subject: Re: Last Call: 'LDAP: The Protocol' to Proposed Standard Cc: ietf-ldapbis@OpenLDAP.org, rfc-editor@rfc-editor.org X-Sun-Charset: US-ASCII X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-ID: ietf-ldapbis mailing list List-Unsubscribe: *> *> The IESG has received a request from the LDAP (v3) Revision WG to consider the following document: *> *> - 'LDAP: The Protocol ' *> as a Proposed Standard *> The Editor's Address section appears in the body of the document, rather than at the end as specified in RFC 2223bis. We see this error often these days; perhaps it is due to an error in xml2rfc? RFC Editor/bb From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 15 16:03:03 2005 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 QAA15798 for ; Fri, 15 Apr 2005 16:03:03 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3FK1E8r006649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2005 20:01:31 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j3FK0Xlr006616; Fri, 15 Apr 2005 20:00: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); Fri, 15 Apr 2005 20:00:33 +0000 Received: from highlandsun.propagation.net (highlandsun.propagation.net [66.221.212.168]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3FK0Ux3006605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Apr 2005 20:00:31 GMT (envelope-from hyc@highlandsun.com) Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id j3FK07fK002108; Fri, 15 Apr 2005 14:00:07 -0600 Message-ID: <42601D57.8090303@highlandsun.com> Date: Fri, 15 Apr 2005 13:00:23 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050401 MIME-Version: 1.0 To: Jim Sermersheim CC: ietf-ldapbis@OpenLDAP.org Subject: Re: Fwd: Re: draft-ietf-ldapbis-protocol - controls References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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-ID: ietf-ldapbis mailing list List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > I don't. What I'm saying is there was a message from Howard which seemed > to me to raise these two issues (a and b). Relaxing what "appropriate" > means doesn't address either of these issues. Maybe I'm wrong and the > only issue raised was that we want "appropriate for the operation" to > mean more than specified as appropriate for the operation by the control > spec. No response is needed though, I'm too tired of this issue to argue > anymore, no one else is concerned. I'll make the change. Since the Last Call just went out for draft 30, I just wanted to check the status of this change. -- -- 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 Fri Apr 15 21:44:31 2005 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 VAA17569 for ; Fri, 15 Apr 2005 21:44:30 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3G1hDKK015013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Apr 2005 01:43:29 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j3G1gpIk015003; Sat, 16 Apr 2005 01:42: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); Sat, 16 Apr 2005 01:42:51 +0000 Received: from boole.openldap.org (kurt@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3G1gk7Q014993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 16 Apr 2005 01:42:46 GMT (envelope-from kurt@boole.openldap.org) Received: (from kurt@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) id j3G1gjYa014992 for ietf-ldapbis@openldap.org; Fri, 15 Apr 2005 18:42:46 -0700 (PDT) (envelope-from kurt) Received: from mail-yellow.research.att.com (mail-dark.research.att.com [192.20.225.112]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3FMMuro010153 for ; Fri, 15 Apr 2005 22:22:58 GMT (envelope-from fenner@research.att.com) Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id E7566197359; Fri, 15 Apr 2005 18:22:04 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j3FMMpIU017266; Fri, 15 Apr 2005 15:22:51 -0700 Message-Id: <200504152222.j3FMMpIU017266@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: braden@ISI.EDU Subject: Re: Last Call: 'LDAP: The Protocol' to Proposed Standard Cc: iesg@ietf.org, ietf-ldapbis@OpenLDAP.org, rfc-editor@rfc-editor.org Date: Fri, 15 Apr 2005 15:22:51 -0700 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-ID: ietf-ldapbis mailing list List-Unsubscribe: Bob, May I suggest engaging the xml2rfc@lists.xml.resource.org list on this topic? They are preparing for a new release at the end of this month and have been eager to get feedback from the RFC Editor. (The xml2rfc order "References, Authors, Appendixes, Index" differs in other ways from the rfc2223bis order "Appendixes, References, Authors", and I don't feel qualified to judge whether, e.g., to suggest that xml2rfc starts using unnumbered references sections to let them fit after the Appendix is specifying the color of the toothbrush.) Bill From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 15 22:04:38 2005 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 WAA18450 for ; Fri, 15 Apr 2005 22:04:38 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3G23TC3015489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Apr 2005 02:03:37 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.13.1/8.13.1/Submit) with SMTP id j3G1xoQi015373; Sat, 16 Apr 2005 01:59: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); Sat, 16 Apr 2005 01:59:50 +0000 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3G1xlKN015338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Apr 2005 01:59:48 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050415185138.04fdf438@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 15 Apr 2005 18:59:24 -0700 To: Howard Chu From: "Kurt D. Zeilenga" Subject: Re: Fwd: Re: draft-ietf-ldapbis-protocol - controls Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org In-Reply-To: <42601D57.8090303@highlandsun.com> References: <42601D57.8090303@highlandsun.com> 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-ID: ietf-ldapbis mailing list List-Unsubscribe: At 01:00 PM 4/15/2005, Howard Chu wrote: >Jim Sermersheim wrote: >>I don't. What I'm saying is there was a message from Howard which seemed to me to raise these two issues (a and b). Relaxing what "appropriate" means doesn't address either of these issues. Maybe I'm wrong and the only issue raised was that we want "appropriate for the operation" to mean more than specified as appropriate for the operation by the control spec. No response is needed though, I'm too tired of this issue to argue anymore, no one else is concerned. I'll make the change. > >Since the Last Call just went out for draft 30, I just wanted to check the status of this change. There are a number of issues, including the above, raised since we progressed -30 which will need to be addressed prior to publication as an RFC. I'll ask Jim to post a summary of changes he thinks are supported by WG consensus for brief discussions, then I'll revise the summary based on those discussions and forward it to the IESG. Individuals are, of course, free to comment separately (before and/or after) I forward the summary to the IESG. Kurt, as LDAPBIS co-chair