From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 2 17:23:33 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12253 for ; Wed, 2 Apr 2003 17:23:29 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h32MMtmZ001571; Wed, 2 Apr 2003 22:24:33 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h32MLpGw001551; Wed, 2 Apr 2003 22:21:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 2 Apr 2003 22:21:51 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h32MLkmV001506; Wed, 2 Apr 2003 22:21:46 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 02 Apr 2003 15:21:25 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Wed, 02 Apr 2003 15:20:47 -0700 From: "Jim Sermersheim" To: , Subject: Re: I-D ACTION:draft-ietf-ldapbis-models-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit extensions (found in schema element syntaxes like ObjectClassDescription) no longer allows a word like "x-1.2.3.4" This was not a limitation in the original spec, is there a reason for allowing only ALPHA HYPHEN, and USCORE? I think it should allow %x21-7E (after the x-) Jim >>> "Kurt D. Zeilenga" 3/13/03 8:46:18 AM >>> In this revision, I have attempted to address issues raised during the WG Last Call. Please review. Kurt At 12:35 PM 3/7/2003, 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: Directory Information Models > Author(s) : K. Zeilenga > Filename : draft-ietf-ldapbis-models-07.txt > Pages : 49 > Date : 2003-3-7 > >The Lightweight Directory Access Protocol (LDAP) is an Internet >protocol for accessing distributed directory services which act in >accordance with X.500 data and service models. This document >describes the X.500 Directory Information Models. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-models-07.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ldapbis-models-07.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-models-07.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: <2003-3-7150730.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-ldapbis-models-07.txt > > From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 2 17:58:15 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14016 for ; Wed, 2 Apr 2003 17:58:13 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h32MuWmX003172; Wed, 2 Apr 2003 22:59:44 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h32MXGeG001962; Wed, 2 Apr 2003 22:33:16 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 2 Apr 2003 22:33:16 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h32MXDmV001946 for ; Wed, 2 Apr 2003 22:33:13 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 02 Apr 2003 15:32:53 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Wed, 02 Apr 2003 15:32:17 -0700 From: "Jim Sermersheim" To: , Subject: Extensibility of SearchRequest.attributes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I believe this data type needs to be re-defined in the LDAPBis work, and I believe there needs to be a more formal way of extending it with "special" values. Currently (in both RFC 2251, and LDAPBis work), this data type does not allow the string "*" (or the proposed "+" for that matter). Both specifications restrict it to a list of attribute descriptions. An attribute description must either be a numeric oid, or begin with a alpha. Yet both have "special wording" like: "There are two special values which may be used: an empty list with no attributes, and the attribute description string "*". Both of these signify that all user attributes are to be returned. (The "*" allows the client to request all user attributes in addition to any specified operational attributes).". Another proposal furthers this and allows "+" to indicate that all operational attributes are to be returned, and other proposals for other special strings are in the works. To start with, I think the current restriction needs to be lifted in the ldapbis work. The easiest thing to do here is to redefine SearchRequest.attributes as SEQUENCE OF OCTET STRING. It would be a little better to define it as a type that has an associated restriction described in ABNF, where the restriction is like, but less than the current attributedescription restriction. Furthermore, I forsee other "special strings" being introduced, and believe that we'll run out of handy things like * + # $ % etc (beside's they become less and less intuitive). I suggest we come up with some generalized standard extensibility mechanism for this. Something like putting special strings inside parens would work, and would allow the tradition of setting "x-" prefixed strings aside as experimental. Here's my suggested ABNF for a single search attribute (refer to http://ietf.org/internet-drafts/draft-ietf-ldapbis-models-07.txt for elements not defined here): searchattribute = descr / numericoid / %x2A / specialsearchattr specialsearchattr = LPAREN WSP (standardspecialsearchattr / experimentalspecialsearchattr) WSP RPAREN standardspecialsearchattr = 1*(%x21-28 / %x2A-7E) experimental = X HYPHEN standardspecialsearchattr Jim From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 3 03:13:00 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09798 for ; Thu, 3 Apr 2003 03:12:59 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h338Cvmh024023; Thu, 3 Apr 2003 08:13:17 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3381hLp023290; Thu, 3 Apr 2003 08:01:43 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 3 Apr 2003 08:01:43 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h3381fmV023276 for ; Thu, 3 Apr 2003 08:01:41 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h3381PBT054394; Thu, 3 Apr 2003 08:01:25 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030402232147.0274c630@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 02 Apr 2003 23:59:21 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldapbis-models-07.txt Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 02:20 PM 4/2/2003, Jim Sermersheim wrote: >extensions (found in schema element syntaxes like >ObjectClassDescription) no longer allows a word like "x-1.2.3.4" >This was not a limitation in the original spec, is there a reason for >allowing only ALPHA HYPHEN, and USCORE? RFC 2252 did not define a production for terms. I came up with xstring by first examining what would be appropriate for all terms (both private and non-private). I came up with: term = ALPHA *( ALPHA / HYPHEN / USCORE ) (I don't recall the exact rationale... likely I just thought keystring then realized USCORE was used in some terms). I then derived xstring from this. I think xstring should be quite restrictive. But as it unlikely that adding a few additional characters would break any implementations, I'm fine with adding one or two additional characters which folks are currently using or believe would be useful. >I think it should allow %x21-7E (after the x-) I think that would be problematic. Is xstring known to be too restrictive (e.g., you known of an existing private term which it disallows)? Or you just would like to have some more options? If yes to either, I prefer to add to only add a few. Would adding DOT be sufficient? From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 3 10:10:53 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23411 for ; Thu, 3 Apr 2003 10:10:52 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h33EgunH062434; Thu, 3 Apr 2003 15:10:37 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h33EZl3o062207; Thu, 3 Apr 2003 14:35:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 3 Apr 2003 14:35:47 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h33EZOmV062156; Thu, 3 Apr 2003 14:35:28 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 03 Apr 2003 07:35:04 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 03 Apr 2003 07:34:30 -0700 From: "Jim Sermersheim" To: Cc: Subject: Re: I-D ACTION:draft-ietf-ldapbis-models-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit At the very least, I suspect someone will want DIGIT and DOT in order to use numeric oids. I'm not aware of any current implementations that the restriction will break, so I'm not willing to burn a bunch of time arguing about allowing more. Jim >>> "Kurt D. Zeilenga" 4/3/03 12:59:21 AM >>> At 02:20 PM 4/2/2003, Jim Sermersheim wrote: >extensions (found in schema element syntaxes like >ObjectClassDescription) no longer allows a word like "x-1.2.3.4" >This was not a limitation in the original spec, is there a reason for >allowing only ALPHA HYPHEN, and USCORE? RFC 2252 did not define a production for terms. I came up with xstring by first examining what would be appropriate for all terms (both private and non-private). I came up with: term = ALPHA *( ALPHA / HYPHEN / USCORE ) (I don't recall the exact rationale... likely I just thought keystring then realized USCORE was used in some terms). I then derived xstring from this. I think xstring should be quite restrictive. But as it unlikely that adding a few additional characters would break any implementations, I'm fine with adding one or two additional characters which folks are currently using or believe would be useful. >I think it should allow %x21-7E (after the x-) I think that would be problematic. Is xstring known to be too restrictive (e.g., you known of an existing private term which it disallows)? Or you just would like to have some more options? If yes to either, I prefer to add to only add a few. Would adding DOT be sufficient? From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 3 14:57:09 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09186 for ; Thu, 3 Apr 2003 14:57:08 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h33JCumb079288; Thu, 3 Apr 2003 19:13:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h33J8HaX078990; Thu, 3 Apr 2003 19:08:17 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 3 Apr 2003 19:08:17 +0000 Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h33J8FmV078946 for ; Thu, 3 Apr 2003 19:08:15 GMT (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h33J7lE18395 for ; Thu, 3 Apr 2003 11:07:47 -0800 (PST) Received: from netscape.com ([10.169.192.46]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HCS7T100.S3I; Thu, 3 Apr 2003 11:07:49 -0800 Message-ID: <3E8C8684.9060903@netscape.com> Date: Thu, 03 Apr 2003 14:07:48 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: Jim Sermersheim CC: ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org Subject: Re: Extensibility of SearchRequest.attributes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > I believe this data type needs to be re-defined in the LDAPBis work, and > I believe there needs to be a more formal way of extending it with > "special" values. > > Currently (in both RFC 2251, and LDAPBis work), this data type does not > allow the string "*" (or the proposed "+" for that matter). Both > specifications restrict it to a list of attribute descriptions. An > attribute description must either be a numeric oid, or begin with a > alpha. Yet both have "special wording" like: "There are two special > values which may be used: an empty list with no attributes, and the > attribute description string "*". Both of these signify that all user > attributes are to be returned. (The "*" allows the client to request all > user attributes in addition to any specified operational attributes).". > Another proposal furthers this and allows "+" to indicate that all > operational attributes are to be returned, and other proposals for other > special strings are in the works. Can you provide some examples? I am generally in favor of allowing for extensions in many areas, but I am not convinced we need to allow it in this specific area. -Mark From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 3 19:23:32 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21097 for ; Thu, 3 Apr 2003 19:23:31 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h340Cuml096620; Fri, 4 Apr 2003 00:25:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3405NCV096321; Fri, 4 Apr 2003 00:05:23 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 4 Apr 2003 00:05:23 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h3405KmV096218 for ; Fri, 4 Apr 2003 00:05:20 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 03 Apr 2003 17:04:59 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 03 Apr 2003 17:03:55 -0700 From: "Jim Sermersheim" To: Cc: , Subject: Re: Extensibility of SearchRequest.attributes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yes, here are some examples of special attributes: Attribute Meaning "*" All User Attrs (P-S RFC) "+" All Operational Attrs (S-T I-D) "+" All Attributes of an object class (I-T I-D) "*;lang-" All User Attrs with lang-xx (no spec yet on remaining) "@" All Attrs listed at uri "*MCSN>" All User Attrs who's mod CSN is greater than that specified "*Len<" All User Attr val's less than len octets "^" No virtual attributes "^^" No collective attributes "$" Only static (no dynamically calculated) attributes ":-(" Attributes with deleted/unpurged values "+dirOp" All directoryOperation operational "+distOp" All distributedOperation operational "+dsaOp" All dsaOperation operational "#" All attributes belonging to specified syntax Obviously, there are many (inconsistent) ways to express these, and there are no guidelines or instructions to those who want to create new special attributes but don't want to collide with special attributes being defined by other people. Jim >>> Mark C Smith 4/3/03 12:07:48 PM >>> Jim Sermersheim wrote: > I believe this data type needs to be re-defined in the LDAPBis work, and > I believe there needs to be a more formal way of extending it with > "special" values. > > Currently (in both RFC 2251, and LDAPBis work), this data type does not > allow the string "*" (or the proposed "+" for that matter). Both > specifications restrict it to a list of attribute descriptions. An > attribute description must either be a numeric oid, or begin with a > alpha. Yet both have "special wording" like: "There are two special > values which may be used: an empty list with no attributes, and the > attribute description string "*". Both of these signify that all user > attributes are to be returned. (The "*" allows the client to request all > user attributes in addition to any specified operational attributes).". > Another proposal furthers this and allows "+" to indicate that all > operational attributes are to be returned, and other proposals for other > special strings are in the works. Can you provide some examples? I am generally in favor of allowing for extensions in many areas, but I am not convinced we need to allow it in this specific area. -Mark From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 4 00:56:18 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26808 for ; Fri, 4 Apr 2003 00:56:18 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h345qvmb011727; Fri, 4 Apr 2003 05:56:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h345n9ih011475; Fri, 4 Apr 2003 05:49:09 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 4 Apr 2003 05:49:09 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h345n6mV011459 for ; Fri, 4 Apr 2003 05:49:06 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h345mVBT063352; Fri, 4 Apr 2003 05:48:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030403205848.02251550@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 03 Apr 2003 21:46:28 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Extensibility of SearchRequest.attributes Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 02:32 PM 4/2/2003, Jim Sermersheim wrote: >To start with, I think the current restriction needs to be lifted in >the ldapbis work. The easiest thing to do here is to redefine >SearchRequest.attributes as SEQUENCE OF OCTET STRING. We need to be careful here. That said, another possibility would be to change it to: SEQUENCE OF AttributeDescriptionOrSpecial AttributeDescriptionOrSpecial ::= LDAPString where the LDAPString is contains a value conforming to the production: attributeDescriptionOrSpecial = attributeDescription / specials specials = "*" and a statement: The specials production may be updated by standard track technical specifications updating this document to allow additional specials. Servers MUST treat specials they do not recognize as unrecognized attribute types. This leaves the exact form of a future specials up to future standard track technical specifications. If one wanted to allow non-standard track specification of specials, then one could write a standard track specification defining a family of specials that have disambiguated by an IANA registry of specials. I rather leave this to others (e.g., not LDAPBIS). Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 4 04:25:18 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11987 for ; Fri, 4 Apr 2003 04:25:17 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h3492vmn019011; Fri, 4 Apr 2003 09:03:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h348fUFN017215; Fri, 4 Apr 2003 08:41:30 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 4 Apr 2003 08:41:30 +0000 Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h348fPmV017204 for ; Fri, 4 Apr 2003 08:41:25 GMT (envelope-from helmut.volpers@siemens.com) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h348fN913356; Fri, 4 Apr 2003 10:41:23 +0200 (MEST) Received: from pappel.asw.mchp.siemens.de ([139.25.160.30]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h348fNJ03847; Fri, 4 Apr 2003 10:41:23 +0200 (MEST) Received: by pappel.asw.mchp.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Apr 2003 10:41:20 +0200 Message-ID: From: "Volpers, Helmut" To: "'Jim Sermersheim'" , mcs@netscape.com Cc: ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org Subject: RE: Extensibility of SearchRequest.attributes Date: Fri, 4 Apr 2003 10:41:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Hi, I am a little bit confused about the examples of the special attributes. I have no problem if your server supports this special attributes, but I hope your client will not send it to my server. How will your client decide whether this attributes can be used (Vendors Name ?). I don't think its a topic for LDAPbis ?! Helmut > -----Original Message----- > From: Jim Sermersheim [mailto:jimse@novell.com] > Sent: Freitag, 4. April 2003 02:04 > To: mcs@netscape.com > Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org > Subject: Re: Extensibility of SearchRequest.attributes > > > Yes, here are some examples of special attributes: > > Attribute Meaning > "*" All User Attrs (P-S RFC) > "+" All Operational Attrs (S-T I-D) > "+" All Attributes of an object class (I-T I-D) > "*;lang-" All User Attrs with lang-xx (no spec yet on > remaining) > "@" All Attrs listed at uri > "*MCSN>" All User Attrs who's mod CSN is greater than that > specified > "*Len<" All User Attr val's less than len octets > "^" No virtual attributes > "^^" No collective attributes > "$" Only static (no dynamically calculated) attributes > ":-(" Attributes with deleted/unpurged values > "+dirOp" All directoryOperation operational > "+distOp" All distributedOperation operational > "+dsaOp" All dsaOperation operational > "#" All attributes belonging to specified syntax > > Obviously, there are many (inconsistent) ways to express these, and > there are no guidelines or instructions to those who want to > create new > special attributes but don't want to collide with special attributes > being defined by other people. > > Jim > > >>> Mark C Smith 4/3/03 12:07:48 PM >>> > Jim Sermersheim wrote: > > I believe this data type needs to be re-defined in the LDAPBis work, > and > > I believe there needs to be a more formal way of extending it with > > "special" values. > > > > Currently (in both RFC 2251, and LDAPBis work), this data type does > not > > allow the string "*" (or the proposed "+" for that matter). Both > > specifications restrict it to a list of attribute descriptions. An > > attribute description must either be a numeric oid, or begin with a > > alpha. Yet both have "special wording" like: "There are two special > > values which may be used: an empty list with no attributes, and the > > attribute description string "*". Both of these signify that all > user > > attributes are to be returned. (The "*" allows the client to request > all > > user attributes in addition to any specified operational > attributes).". > > Another proposal furthers this and allows "+" to indicate that all > > operational attributes are to be returned, and other proposals for > other > > special strings are in the works. > > Can you provide some examples? I am generally in favor of allowing for > > extensions in many areas, but I am not convinced we need to > allow it in > > this specific area. > > -Mark > From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 4 04:25:19 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11990 for ; Fri, 4 Apr 2003 04:25:18 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h3492vmp019011; Fri, 4 Apr 2003 09:03:43 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h348v1Qw018515; Fri, 4 Apr 2003 08:57:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 4 Apr 2003 08:57:01 +0000 Received: from nb2.stroeder.com (krl9-d9bb4f66.pool.mediaWays.net [217.187.79.102]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h348uvmV018500 for ; Fri, 4 Apr 2003 08:56:57 GMT (envelope-from michael@stroeder.com) Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 17CB96B10B; Fri, 4 Apr 2003 10:56:57 +0200 (CEST) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 353D26B0E3; Fri, 4 Apr 2003 10:56:56 +0200 (CEST) Message-ID: <3E8D48D8.4080807@stroeder.com> Date: Fri, 04 Apr 2003 10:56:56 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: "Volpers, Helmut" Cc: "'Jim Sermersheim'" , mcs@netscape.com, ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org Subject: Re: [ldapext] RE: Extensibility of SearchRequest.attributes References: In-Reply-To: X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Volpers, Helmut wrote: > > I am a little bit confused about the examples of the special attributes. > > I have no problem if your server supports this special attributes, but > I hope your client will not send it to my server. I hope your server won't crash when receiving these special attributes in a search request. ;-) > How will your client decide whether this attributes can be used (Vendors > Name ?). A client can look at attribute 'supportedFeatures' in RootDSE. My client is checking for 1.3.6.1.4.1.4203.1.5.1 (defined in draft-zeilenga-ldap-opattrs) and then sends '+'. Ciao, Michael. >>-----Original Message----- >>From: Jim Sermersheim [mailto:jimse@novell.com] >>Sent: Freitag, 4. April 2003 02:04 >>To: mcs@netscape.com >>Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org >>Subject: Re: Extensibility of SearchRequest.attributes >> >> >>Yes, here are some examples of special attributes: >> >>Attribute Meaning >>"*" All User Attrs (P-S RFC) >>"+" All Operational Attrs (S-T I-D) >>"+" All Attributes of an object class (I-T I-D) >>"*;lang-" All User Attrs with lang-xx (no spec yet on >>remaining) >>"@" All Attrs listed at uri >>"*MCSN>" All User Attrs who's mod CSN is greater than that >>specified >>"*Len<" All User Attr val's less than len octets >>"^" No virtual attributes >>"^^" No collective attributes >>"$" Only static (no dynamically calculated) attributes >>":-(" Attributes with deleted/unpurged values >>"+dirOp" All directoryOperation operational >>"+distOp" All distributedOperation operational >>"+dsaOp" All dsaOperation operational >>"#" All attributes belonging to specified syntax >> >>Obviously, there are many (inconsistent) ways to express these, and >>there are no guidelines or instructions to those who want to >>create new >>special attributes but don't want to collide with special attributes >>being defined by other people. >> >>Jim >> >> >>>>>Mark C Smith 4/3/03 12:07:48 PM >>> >> >>Jim Sermersheim wrote: >> >>>I believe this data type needs to be re-defined in the LDAPBis work, >> >>and >> >>>I believe there needs to be a more formal way of extending it with >>>"special" values. >>> >>>Currently (in both RFC 2251, and LDAPBis work), this data type does >> >>not >> >>>allow the string "*" (or the proposed "+" for that matter). Both >>>specifications restrict it to a list of attribute descriptions. An >>>attribute description must either be a numeric oid, or begin with a >>>alpha. Yet both have "special wording" like: "There are two special >>>values which may be used: an empty list with no attributes, and the >>>attribute description string "*". Both of these signify that all >> >>user >> >>>attributes are to be returned. (The "*" allows the client to request >> >>all >> >>>user attributes in addition to any specified operational >> >>attributes).". >> >>>Another proposal furthers this and allows "+" to indicate that all >>>operational attributes are to be returned, and other proposals for >> >>other >> >>>special strings are in the works. >> >>Can you provide some examples? I am generally in favor of allowing for >> >>extensions in many areas, but I am not convinced we need to >>allow it in >> >>this specific area. >> >>-Mark From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 4 10:23:53 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26126 for ; Fri, 4 Apr 2003 10:23:52 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34FMwmb043539; Fri, 4 Apr 2003 15:23:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h34FE8cA042369; Fri, 4 Apr 2003 15:14:09 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 4 Apr 2003 15:14:08 +0000 Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34FE3mV042315; Fri, 4 Apr 2003 15:14:04 GMT (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h34FDhn14961; Fri, 4 Apr 2003 07:13:43 -0800 (PST) Received: from netscape.com ([10.169.192.53]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HCTRMV03.34K; Fri, 4 Apr 2003 07:13:43 -0800 Message-ID: <3E8DA125.3060702@netscape.com> Date: Fri, 04 Apr 2003 10:13:41 -0500 From: mcs@netscape.com (Mark C Smith) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jim Sermersheim , ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org Subject: Re: Extensibility of SearchRequest.attributes References: <5.2.0.9.0.20030403205848.02251550@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030403205848.02251550@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree with the approach suggested by Kurt. Creating an extensibility mechanism for AttributeDescriptions is a new LDAP feature and should be out of scope for LDAPBis. But doing a little work in LDAPBis to allow for the possibility makes sense to me. I am a little concerned about leaving the possibilities for "specials" wide open. If we adopt the statement suggested by Kurt, then servers must accept any octet inside an AttributeDescription. Perhaps most implementations already do, but some may not. -Mark Smith Netscape Kurt D. Zeilenga wrote: > > We need to be careful here. > > That said, another possibility would be to change it to: > SEQUENCE OF AttributeDescriptionOrSpecial > AttributeDescriptionOrSpecial ::= LDAPString > > where the LDAPString is contains a value conforming to the production: > attributeDescriptionOrSpecial = attributeDescription / specials > specials = "*" > > and a statement: > The specials production may be updated by standard track > technical specifications updating this document to allow > additional specials. Servers MUST treat specials they do > not recognize as unrecognized attribute types. > > This leaves the exact form of a future specials up to > future standard track technical specifications. > > If one wanted to allow non-standard track specification of > specials, then one could write a standard track specification > defining a family of specials that have disambiguated by > an IANA registry of specials. I rather leave this to others > (e.g., not LDAPBIS). > > Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 4 10:49:57 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27160 for ; Fri, 4 Apr 2003 10:49:56 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34FWwo9044279; Fri, 4 Apr 2003 15:51:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h34FP3uX043675; Fri, 4 Apr 2003 15:25:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 4 Apr 2003 15:25:03 +0000 Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34FP0mV043648 for ; Fri, 4 Apr 2003 15:25:00 GMT (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h34FOdn16262 for ; Fri, 4 Apr 2003 07:24:39 -0800 (PST) Received: from netscape.com ([10.169.192.53]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HCTS5301.L4Z; Fri, 4 Apr 2003 07:24:39 -0800 Message-ID: <3E8DA3B5.80208@netscape.com> Date: Fri, 04 Apr 2003 10:24:37 -0500 From: mcs@netscape.com (Mark C Smith) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org Subject: Re: Extensibility of SearchRequest.attributes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit OK; thanks for the list. I hope I never have to implement support for all of these in a server (not that each one is very difficult; this is just a long list). A side note: it makes sense to me to express concepts like "all" in an AttributeDescriptionList, but I think it makes more sense to use a control to modify how the entire list is processed. So I would use a control to express these concepts from your list of examples: > "*Len<" All User Attr val's less than len octets > "^" No virtual attributes > "^^" No collective attributes > "$" Only static (no dynamically calculated) attributes > ":-(" Attributes with deleted/unpurged values The "*Len<" one is included because I might want to say "return values for attributes a, b, c whose length is less than 1000 octets" or "return all operational attributes whose length is less than 512 octets." Controls have other nice properties: collisions can't happen (due to use of OIDs), handling of unknown controls is well defined, etc. -Mark Smith Netscape Jim Sermersheim wrote: > Yes, here are some examples of special attributes: > > Attribute Meaning > "*" All User Attrs (P-S RFC) > "+" All Operational Attrs (S-T I-D) > "+" All Attributes of an object class (I-T I-D) > "*;lang-" All User Attrs with lang-xx (no spec yet on > remaining) > "@" All Attrs listed at uri > "*MCSN>" All User Attrs who's mod CSN is greater than that > specified > "*Len<" All User Attr val's less than len octets > "^" No virtual attributes > "^^" No collective attributes > "$" Only static (no dynamically calculated) attributes > ":-(" Attributes with deleted/unpurged values > "+dirOp" All directoryOperation operational > "+distOp" All distributedOperation operational > "+dsaOp" All dsaOperation operational > "#" All attributes belonging to specified syntax > > Obviously, there are many (inconsistent) ways to express these, and > there are no guidelines or instructions to those who want to create new > special attributes but don't want to collide with special attributes > being defined by other people. > > Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 4 12:12:02 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29577 for ; Fri, 4 Apr 2003 12:12:01 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34HCwmb053900; Fri, 4 Apr 2003 17:13:12 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h34HAXoN053768; Fri, 4 Apr 2003 17:10:33 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 4 Apr 2003 17:10:33 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34HASmV053749 for ; Fri, 4 Apr 2003 17:10:29 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 04 Apr 2003 10:10:08 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Fri, 04 Apr 2003 10:09:30 -0700 From: "Jim Sermersheim" To: , Cc: , Subject: RE: Extensibility of SearchRequest.attributes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit ldapbis has everything to do with interoperability. The fact that you hope no client sends one of these strings to your server, and the fact that there are currently no instructions on what should happen if one does means that thisis a topic for ldapbis. ldapbis needs to tell servers that it's ok, for unknown strings (which are invalid attribute names) to be sent, and for servers to ignore those unknown strings. Jim >>> "Volpers, Helmut" 4/4/03 1:41:15 AM >>> Hi, I am a little bit confused about the examples of the special attributes. I have no problem if your server supports this special attributes, but I hope your client will not send it to my server. How will your client decide whether this attributes can be used (Vendors Name ?). I don't think its a topic for LDAPbis ?! Helmut > -----Original Message----- > From: Jim Sermersheim [mailto:jimse@novell.com] > Sent: Freitag, 4. April 2003 02:04 > To: mcs@netscape.com > Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org > Subject: Re: Extensibility of SearchRequest.attributes > > > Yes, here are some examples of special attributes: > > Attribute Meaning > "*" All User Attrs (P-S RFC) > "+" All Operational Attrs (S-T I-D) > "+" All Attributes of an object class (I-T I-D) > "*;lang-" All User Attrs with lang-xx (no spec yet on > remaining) > "@" All Attrs listed at uri > "*MCSN>" All User Attrs who's mod CSN is greater than that > specified > "*Len<" All User Attr val's less than len octets > "^" No virtual attributes > "^^" No collective attributes > "$" Only static (no dynamically calculated) attributes > ":-(" Attributes with deleted/unpurged values > "+dirOp" All directoryOperation operational > "+distOp" All distributedOperation operational > "+dsaOp" All dsaOperation operational > "#" All attributes belonging to specified syntax > > Obviously, there are many (inconsistent) ways to express these, and > there are no guidelines or instructions to those who want to > create new > special attributes but don't want to collide with special attributes > being defined by other people. > > Jim > > >>> Mark C Smith 4/3/03 12:07:48 PM >>> > Jim Sermersheim wrote: > > I believe this data type needs to be re-defined in the LDAPBis work, > and > > I believe there needs to be a more formal way of extending it with > > "special" values. > > > > Currently (in both RFC 2251, and LDAPBis work), this data type does > not > > allow the string "*" (or the proposed "+" for that matter). Both > > specifications restrict it to a list of attribute descriptions. An > > attribute description must either be a numeric oid, or begin with a > > alpha. Yet both have "special wording" like: "There are two special > > values which may be used: an empty list with no attributes, and the > > attribute description string "*". Both of these signify that all > user > > attributes are to be returned. (The "*" allows the client to request > all > > user attributes in addition to any specified operational > attributes).". > > Another proposal furthers this and allows "+" to indicate that all > > operational attributes are to be returned, and other proposals for > other > > special strings are in the works. > > Can you provide some examples? I am generally in favor of allowing for > > extensions in many areas, but I am not convinced we need to > allow it in > > this specific area. > > -Mark > From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 4 12:32:22 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00339 for ; Fri, 4 Apr 2003 12:32:21 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34HX3mZ055010; Fri, 4 Apr 2003 17:33:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h34HEMrZ053975; Fri, 4 Apr 2003 17:14:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 4 Apr 2003 17:14:22 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34HEJmV053961 for ; Fri, 4 Apr 2003 17:14:20 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 04 Apr 2003 10:14:19 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Fri, 04 Apr 2003 10:13:37 -0700 From: "Jim Sermersheim" To: Cc: , Subject: Re: Extensibility of SearchRequest.attributes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yeah, I just popped these off the top of my head--some are more reasonable than others. I'm not sure that I plan to implement any or all of them. The nice thing about not defining a control is that clients don't have to be re-compiled. >>> Mark C Smith 4/4/03 8:24:37 AM >>> OK; thanks for the list. I hope I never have to implement support for all of these in a server (not that each one is very difficult; this is just a long list). A side note: it makes sense to me to express concepts like "all" in an AttributeDescriptionList, but I think it makes more sense to use a control to modify how the entire list is processed. So I would use a control to express these concepts from your list of examples: > "*Len<" All User Attr val's less than len octets > "^" No virtual attributes > "^^" No collective attributes > "$" Only static (no dynamically calculated) attributes > ":-(" Attributes with deleted/unpurged values The "*Len<" one is included because I might want to say "return values for attributes a, b, c whose length is less than 1000 octets" or "return all operational attributes whose length is less than 512 octets." Controls have other nice properties: collisions can't happen (due to use of OIDs), handling of unknown controls is well defined, etc. -Mark Smith Netscape Jim Sermersheim wrote: > Yes, here are some examples of special attributes: > > Attribute Meaning > "*" All User Attrs (P-S RFC) > "+" All Operational Attrs (S-T I-D) > "+" All Attributes of an object class (I-T I-D) > "*;lang-" All User Attrs with lang-xx (no spec yet on > remaining) > "@" All Attrs listed at uri > "*MCSN>" All User Attrs who's mod CSN is greater than that > specified > "*Len<" All User Attr val's less than len octets > "^" No virtual attributes > "^^" No collective attributes > "$" Only static (no dynamically calculated) attributes > ":-(" Attributes with deleted/unpurged values > "+dirOp" All directoryOperation operational > "+distOp" All distributedOperation operational > "+dsaOp" All dsaOperation operational > "#" All attributes belonging to specified syntax > > Obviously, there are many (inconsistent) ways to express these, and > there are no guidelines or instructions to those who want to create new > special attributes but don't want to collide with special attributes > being defined by other people. > > Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 4 12:46:58 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00896 for ; Fri, 4 Apr 2003 12:46:58 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34HgwnL055815; Fri, 4 Apr 2003 17:48:33 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h34HbSZl055523; Fri, 4 Apr 2003 17:37:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 4 Apr 2003 17:37:28 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34HbMmV055477; Fri, 4 Apr 2003 17:37:22 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 04 Apr 2003 10:37:02 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Fri, 04 Apr 2003 10:36:33 -0700 From: "Jim Sermersheim" To: , Cc: , Subject: Re: Extensibility of SearchRequest.attributes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think the first thing to do is get consensus on whether new special attributes are allowed. I believe the intent of RFC 2251 is that special strings can be used to request different things in the return attributes, thus it itself allows a *. I further believe that the RFC simply missed the point that it was self-inconsistent in the way it defined the data type for the return attr specification. Thus, I believe it needs to a) fix the inconsistency, b) allow for future special strings, and possibly c) define how future extensions should be defined. I'm fine with the suggestion Kurt made, though I'm still nervous about the proliferation of special strings. I'd really like to see some "x-" mechanism available--but I agree, that can be done outside the scope of ldapbis. Unless there are other opinions, I will assume consensus is that we do (a) and (b) above. Jim >>> Mark C Smith 4/4/03 8:13:41 AM >>> I agree with the approach suggested by Kurt. Creating an extensibility mechanism for AttributeDescriptions is a new LDAP feature and should be out of scope for LDAPBis. But doing a little work in LDAPBis to allow for the possibility makes sense to me. I am a little concerned about leaving the possibilities for "specials" wide open. If we adopt the statement suggested by Kurt, then servers must accept any octet inside an AttributeDescription. Perhaps most implementations already do, but some may not. -Mark Smith Netscape Kurt D. Zeilenga wrote: > > We need to be careful here. > > That said, another possibility would be to change it to: > SEQUENCE OF AttributeDescriptionOrSpecial > AttributeDescriptionOrSpecial ::= LDAPString > > where the LDAPString is contains a value conforming to the production: > attributeDescriptionOrSpecial = attributeDescription / specials > specials = "*" > > and a statement: > The specials production may be updated by standard track > technical specifications updating this document to allow > additional specials. Servers MUST treat specials they do > not recognize as unrecognized attribute types. > > This leaves the exact form of a future specials up to > future standard track technical specifications. > > If one wanted to allow non-standard track specification of > specials, then one could write a standard track specification > defining a family of specials that have disambiguated by > an IANA registry of specials. I rather leave this to others > (e.g., not LDAPBIS). > > Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 4 12:56:29 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01155 for ; Fri, 4 Apr 2003 12:56:29 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34HqwnL056898; Fri, 4 Apr 2003 17:57:55 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h34HhV4H055889; Fri, 4 Apr 2003 17:43:31 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 4 Apr 2003 17:43:31 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34HhSmV055870 for ; Fri, 4 Apr 2003 17:43:29 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h34Hh7BT067901; Fri, 4 Apr 2003 17:43:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030404093917.02445b40@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 04 Apr 2003 09:41:04 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Re: Extensibility of SearchRequest.attributes Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 09:36 AM 4/4/2003, Jim Sermersheim wrote: >I'm fine with the suggestion Kurt made, though I'm still nervous about >the proliferation of special strings. Requiring that specials be extended by standard track specifications (until someone defines a general specials extension mechanism) will slow proliferation. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 4 14:04:39 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02930 for ; Fri, 4 Apr 2003 14:04:39 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34Iqwnb061218; Fri, 4 Apr 2003 19:05:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h34InHP8060628; Fri, 4 Apr 2003 18:49:17 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 4 Apr 2003 18:49:17 +0000 Received: from galois.openldap.org (kurt@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34InEmV060617 for ; Fri, 4 Apr 2003 18:49:14 GMT (envelope-from kurt@galois.openldap.org) Received: (from kurt@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) id h34InERj060616 for ietf-ldapbis@openldap.org; Fri, 4 Apr 2003 18:49:14 GMT (envelope-from kurt) Received: from imf23bis.bellsouth.net (mail223.mail.bellsouth.net [205.152.58.193]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34IBjmV058375 for ; Fri, 4 Apr 2003 18:11:45 GMT (envelope-from aok123@bellsouth.net) Received: from newton ([65.80.144.227]) by imf23bis.bellsouth.net (InterMail vM.5.01.04.25 201-253-122-122-125-20020815) with ESMTP id <20030404181339.JAOT22441.imf23bis.bellsouth.net@newton>; Fri, 4 Apr 2003 13:13:39 -0500 From: "Alex Karasulu" To: Cc: Subject: What ever happened to the information contained within this draft? Date: Fri, 4 Apr 2003 13:35:05 -0500 Message-ID: <000501c2fad8$ecb54da0$640110ac@trunk.joshuatree.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C2FAAF.03DF45A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C2FAAF.03DF45A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Here's the draft I'm referring to. I know the draft has expired however I'm looking for a definitive source for this information. 2251 has pieces strewn all over and I don't have the feeling that it explains the usage of error codes in the detail that this draft seemed to. Any idea where the definitive source for this information can be located? http://www.watersprings.org/pub/id/draft-just-ldapv3-rescodes-02.txt Thanks much, -Alex ------=_NextPart_000_0006_01C2FAAF.03DF45A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40"> Heres the draft Im referring to. I know the draft has expired = however Im looking for a definitive source for this information. 2251 has pieces strewn all over = and I dont have the feeling that it explains the usage of error codes = in the detail that this draft seemed to. = Any idea where the definitive source for this information can be = located? http://www.watersprings.org/pub/id/draft-just-ldapv3-rescodes-02.txt= Thanks much, -Alex ------=_NextPart_000_0006_01C2FAAF.03DF45A0-- From owner-ietf-ldapbis@OpenLDAP.org Fri Apr 4 14:34:37 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04126 for ; Fri, 4 Apr 2003 14:34:37 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34JX4ml067164; Fri, 4 Apr 2003 19:35:45 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h34JVefX067145; Fri, 4 Apr 2003 19:31:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 4 Apr 2003 19:31:40 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h34JVbmV067135 for ; Fri, 4 Apr 2003 19:31:37 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h34JU8BT069241; Fri, 4 Apr 2003 19:30:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030404111558.02356938@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 04 Apr 2003 11:27:55 -0800 To: "Alex Karasulu" From: "Kurt D. Zeilenga" Subject: Re: What ever happened to the information contained within this draft? Cc: , In-Reply-To: <000501c2fad8$ecb54da0$640110ac@trunk.joshuatree.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Much of the information in this draft should have found its way into the revised LDAP Technical Specification being engineered by this working group, namely incorporated into draft-ietf-ldapbis-protocol. Presently, RFC 3377 is the definitive LDAP technical specification with RFC 2251 and X.511(93) being the normative source for this information. However, you may find that our "work in progress" draft-ietf-ldapbis-* provides better, but not (yet) definitive, information. I encourage you to review the WG I-Ds and to comment where you think it lacks the necessary detail and/or clarity to allow an independent developer to produce an interoperable LDAP implementation. Regards, Kurt At 10:35 AM 4/4/2003, Alex Karasulu wrote: >xmlns:w="urn:schemas-microsoft-com:office:word" mlns="http://www.w3.org/TR/REC-html40"> Heres the draft Im referring to. I know the draft has expired owever Im looking for a definitive source for this information. 2251 has pieces strewn all over nd I dont have the feeling that it explains the usage of error codes n the detail that this draft seemed to. ny idea where the definitive source for this information can be ocated? http://www.watersprings.org/pub/id/draft-just-ldapv3-rescodes-02.txt Thanks much, -Alex From owner-ietf-ldapbis@OpenLDAP.org Sun Apr 6 21:34:32 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11326 for ; Sun, 6 Apr 2003 21:34:32 -0400 (EDT) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h371X3mZ059165; Mon, 7 Apr 2003 01:35:34 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h371S5IB059034; Mon, 7 Apr 2003 01:28:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 7 Apr 2003 01:28:05 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h371RumV058994; Mon, 7 Apr 2003 01:27:56 GMT (envelope-from Ron.Ramsay@ca.com) content-class: urn:content-classes:message Subject: RE: Extensibility of SearchRequest.attributes Date: Mon, 7 Apr 2003 11:27:49 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: Extensibility of SearchRequest.attributes Thread-Index: AcL60nDyGOWL+tqdSgK01srLMIoKqQB0YQ/g From: "Ramsay, Ron" To: "Jim Sermersheim" , , Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id h371RvmV059006 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Why do you believe special strings can be used. I looked at RFC 2251 and, regarding 'attributes', it says there are two special values. One is no values at all and the other is the string "*". The ASN.1 defines 'attributes' to be of type AttributeDescriptionList, which would seem to disallow arbitrary strings? I think it is weirdness and that, as Mark Smith says, controls should be used to cause special behaviours. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Saturday, 5 April 2003 03:37 To: mcs@netscape.com; Kurt@OpenLDAP.org Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org Subject: Re: Extensibility of SearchRequest.attributes I think the first thing to do is get consensus on whether new special attributes are allowed. I believe the intent of RFC 2251 is that special strings can be used to request different things in the return attributes, thus it itself allows a *. I further believe that the RFC simply missed the point that it was self-inconsistent in the way it defined the data type for the return attr specification. Thus, I believe it needs to a) fix the inconsistency, b) allow for future special strings, and possibly c) define how future extensions should be defined. I'm fine with the suggestion Kurt made, though I'm still nervous about the proliferation of special strings. I'd really like to see some "x-" mechanism available--but I agree, that can be done outside the scope of ldapbis. Unless there are other opinions, I will assume consensus is that we do (a) and (b) above. Jim >>> Mark C Smith 4/4/03 8:13:41 AM >>> I agree with the approach suggested by Kurt. Creating an extensibility mechanism for AttributeDescriptions is a new LDAP feature and should be out of scope for LDAPBis. But doing a little work in LDAPBis to allow for the possibility makes sense to me. I am a little concerned about leaving the possibilities for "specials" wide open. If we adopt the statement suggested by Kurt, then servers must accept any octet inside an AttributeDescription. Perhaps most implementations already do, but some may not. -Mark Smith Netscape Kurt D. Zeilenga wrote: > > We need to be careful here. > > That said, another possibility would be to change it to: > SEQUENCE OF AttributeDescriptionOrSpecial > AttributeDescriptionOrSpecial ::= LDAPString > > where the LDAPString is contains a value conforming to the production: > attributeDescriptionOrSpecial = attributeDescription / specials > specials = "*" > > and a statement: > The specials production may be updated by standard track > technical specifications updating this document to allow > additional specials. Servers MUST treat specials they do > not recognize as unrecognized attribute types. > > This leaves the exact form of a future specials up to > future standard track technical specifications. > > If one wanted to allow non-standard track specification of > specials, then one could write a standard track specification > defining a family of specials that have disambiguated by > an IANA registry of specials. I rather leave this to others > (e.g., not LDAPBIS). > > Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Apr 7 11:29:36 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23678 for ; Mon, 7 Apr 2003 11:29:35 -0400 (EDT) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h37Eh4mb097377; Mon, 7 Apr 2003 14:43:57 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h37EdTo8097187; Mon, 7 Apr 2003 14:39:29 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 7 Apr 2003 14:39:29 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h37EdNmV097140; Mon, 7 Apr 2003 14:39:24 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 07 Apr 2003 08:39:03 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 07 Apr 2003 08:38:08 -0600 From: "Jim Sermersheim" To: , , Cc: , Subject: RE: Extensibility of SearchRequest.attributes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Well, as you point out, in one breath RFC 2251 disallows the "*" string, and in another, it allows it. It is not self consistent. I believe the intent may have been to allow special strings. Furthermore, other Internet-Drafts that describe new special strings have made significant progress with no apparent concern from community members (draft-zeilenga-ldap-opattrs (Proposed Standard, under IESG Evaluation), and draft-zeilenga-ldap-adlist). We either need to allow special strings to be defined, or disallow anything other than "*" and empty, and raise a red flag concerning those two I-D's Jim >>> "Ramsay, Ron" 4/6/03 7:27:49 PM >>> Why do you believe special strings can be used. I looked at RFC 2251 and, regarding 'attributes', it says there are two special values. One is no values at all and the other is the string "*". The ASN.1 defines 'attributes' to be of type AttributeDescriptionList, which would seem to disallow arbitrary strings? I think it is weirdness and that, as Mark Smith says, controls should be used to cause special behaviours. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Saturday, 5 April 2003 03:37 To: mcs@netscape.com; Kurt@OpenLDAP.org Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org Subject: Re: Extensibility of SearchRequest.attributes I think the first thing to do is get consensus on whether new special attributes are allowed. I believe the intent of RFC 2251 is that special strings can be used to request different things in the return attributes, thus it itself allows a *. I further believe that the RFC simply missed the point that it was self-inconsistent in the way it defined the data type for the return attr specification. Thus, I believe it needs to a) fix the inconsistency, b) allow for future special strings, and possibly c) define how future extensions should be defined. I'm fine with the suggestion Kurt made, though I'm still nervous about the proliferation of special strings. I'd really like to see some "x-" mechanism available--but I agree, that can be done outside the scope of ldapbis. Unless there are other opinions, I will assume consensus is that we do (a) and (b) above. Jim >>> Mark C Smith 4/4/03 8:13:41 AM >>> I agree with the approach suggested by Kurt. Creating an extensibility mechanism for AttributeDescriptions is a new LDAP feature and should be out of scope for LDAPBis. But doing a little work in LDAPBis to allow for the possibility makes sense to me. I am a little concerned about leaving the possibilities for "specials" wide open. If we adopt the statement suggested by Kurt, then servers must accept any octet inside an AttributeDescription. Perhaps most implementations already do, but some may not. -Mark Smith Netscape Kurt D. Zeilenga wrote: > > We need to be careful here. > > That said, another possibility would be to change it to: > SEQUENCE OF AttributeDescriptionOrSpecial > AttributeDescriptionOrSpecial ::= LDAPString > > where the LDAPString is contains a value conforming to the production: > attributeDescriptionOrSpecial = attributeDescription / specials > specials = "*" > > and a statement: > The specials production may be updated by standard track > technical specifications updating this document to allow > additional specials. Servers MUST treat specials they do > not recognize as unrecognized attribute types. > > This leaves the exact form of a future specials up to > future standard track technical specifications. > > If one wanted to allow non-standard track specification of > specials, then one could write a standard track specification > defining a family of specials that have disambiguated by > an IANA registry of specials. I rather leave this to others > (e.g., not LDAPBIS). > > Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Apr 7 22:01:49 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14117 for ; Mon, 7 Apr 2003 22:01:48 -0400 (EDT) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h381XFmZ024287; Tue, 8 Apr 2003 01:37:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h381SvcB024152; Tue, 8 Apr 2003 01:28:57 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 8 Apr 2003 01:28:57 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h381SomV024121; Tue, 8 Apr 2003 01:28:50 GMT (envelope-from Ron.Ramsay@ca.com) content-class: urn:content-classes:message Subject: RE: Extensibility of SearchRequest.attributes Date: Tue, 8 Apr 2003 11:28:35 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: Extensibility of SearchRequest.attributes Thread-Index: AcL9E3MtCIxIXO+BSS+5QmaWIPZkQAAWQpJg From: "Ramsay, Ron" To: "Jim Sermersheim" , , Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id h381SpmV024126 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I hadn't realised that "+" was PS and that it had passed last call. However, as "*" only returns normal attributes, and as operational attributes have to be named to be returned, perhaps there is a case for "+". X.500 has a framework for this - a comparable facility in LDAP would have been another item, say "op-attributes" after the item "attributes". But that is water under the bridge. I'd like to see the nonsense stop at "+". A control could serve for the other uses, you just need an I-D to define an OID and some strings (or integers?) Extended-EIS:Control= OID:Name=x.y.z Boolean:Criticality ANY:Value=@Table Table=(table of values and meanings) Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Tuesday, 8 April 2003 00:38 To: Ramsay, Ron; mcs@netscape.com; Kurt@OpenLDAP.org Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org Subject: RE: Extensibility of SearchRequest.attributes Well, as you point out, in one breath RFC 2251 disallows the "*" string, and in another, it allows it. It is not self consistent. I believe the intent may have been to allow special strings. Furthermore, other Internet-Drafts that describe new special strings have made significant progress with no apparent concern from community members (draft-zeilenga-ldap-opattrs (Proposed Standard, under IESG Evaluation), and draft-zeilenga-ldap-adlist). We either need to allow special strings to be defined, or disallow anything other than "*" and empty, and raise a red flag concerning those two I-D's Jim >>> "Ramsay, Ron" 4/6/03 7:27:49 PM >>> Why do you believe special strings can be used. I looked at RFC 2251 and, regarding 'attributes', it says there are two special values. One is no values at all and the other is the string "*". The ASN.1 defines 'attributes' to be of type AttributeDescriptionList, which would seem to disallow arbitrary strings? I think it is weirdness and that, as Mark Smith says, controls should be used to cause special behaviours. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Saturday, 5 April 2003 03:37 To: mcs@netscape.com; Kurt@OpenLDAP.org Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org Subject: Re: Extensibility of SearchRequest.attributes I think the first thing to do is get consensus on whether new special attributes are allowed. I believe the intent of RFC 2251 is that special strings can be used to request different things in the return attributes, thus it itself allows a *. I further believe that the RFC simply missed the point that it was self-inconsistent in the way it defined the data type for the return attr specification. Thus, I believe it needs to a) fix the inconsistency, b) allow for future special strings, and possibly c) define how future extensions should be defined. I'm fine with the suggestion Kurt made, though I'm still nervous about the proliferation of special strings. I'd really like to see some "x-" mechanism available--but I agree, that can be done outside the scope of ldapbis. Unless there are other opinions, I will assume consensus is that we do (a) and (b) above. Jim >>> Mark C Smith 4/4/03 8:13:41 AM >>> I agree with the approach suggested by Kurt. Creating an extensibility mechanism for AttributeDescriptions is a new LDAP feature and should be out of scope for LDAPBis. But doing a little work in LDAPBis to allow for the possibility makes sense to me. I am a little concerned about leaving the possibilities for "specials" wide open. If we adopt the statement suggested by Kurt, then servers must accept any octet inside an AttributeDescription. Perhaps most implementations already do, but some may not. -Mark Smith Netscape Kurt D. Zeilenga wrote: > > We need to be careful here. > > That said, another possibility would be to change it to: > SEQUENCE OF AttributeDescriptionOrSpecial > AttributeDescriptionOrSpecial ::= LDAPString > > where the LDAPString is contains a value conforming to the production: > attributeDescriptionOrSpecial = attributeDescription / specials > specials = "*" > > and a statement: > The specials production may be updated by standard track > technical specifications updating this document to allow > additional specials. Servers MUST treat specials they do > not recognize as unrecognized attribute types. > > This leaves the exact form of a future specials up to > future standard track technical specifications. > > If one wanted to allow non-standard track specification of > specials, then one could write a standard track specification > defining a family of specials that have disambiguated by > an IANA registry of specials. I rather leave this to others > (e.g., not LDAPBIS). > > Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 8 02:03:26 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21837 for ; Tue, 8 Apr 2003 02:03:25 -0400 (EDT) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h38635mb032111; Tue, 8 Apr 2003 06:03:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h385wAjt032001; Tue, 8 Apr 2003 05:58:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 8 Apr 2003 05:58:10 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.9/8.12.9) with ESMTP id h385w0mV031969; Tue, 8 Apr 2003 05:58:04 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 07 Apr 2003 23:57:50 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 07 Apr 2003 23:57:00 -0600 From: "Jim Sermersheim" To: , , Cc: , Subject: RE: Extensibility of SearchRequest.attributes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ron, you're absolutely right about the control thing. There is nothing that can be done with a special string that can't be done with a control. Special strings have the advantage that oftentimes existing applications can just use them without being re-compiled. I do not think we can allow "+", and disallow others. How would such a thing be worded in 2251bis without "extending"? Oh, I know. It can say that all attrDescriptions are allowed, as well as the "*" string, and also any future extensions, so long as they only use the "+" string. ha ha ha. Consensus seems murky on this topic. Does anyone else out there have further input? Jim >>> "Ramsay, Ron" 4/7/03 7:28:35 PM >>> I hadn't realised that "+" was PS and that it had passed last call. However, as "*" only returns normal attributes, and as operational attributes have to be named to be returned, perhaps there is a case for "+". X.500 has a framework for this - a comparable facility in LDAP would have been another item, say "op-attributes" after the item "attributes". But that is water under the bridge. I'd like to see the nonsense stop at "+". A control could serve for the other uses, you just need an I-D to define an OID and some strings (or integers?) Extended-EIS:Control= OID:Name=x.y.z Boolean:Criticality ANY:Value=@Table Table=(table of values and meanings) Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Tuesday, 8 April 2003 00:38 To: Ramsay, Ron; mcs@netscape.com; Kurt@OpenLDAP.org Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org Subject: RE: Extensibility of SearchRequest.attributes Well, as you point out, in one breath RFC 2251 disallows the "*" string, and in another, it allows it. It is not self consistent. I believe the intent may have been to allow special strings. Furthermore, other Internet-Drafts that describe new special strings have made significant progress with no apparent concern from community members (draft-zeilenga-ldap-opattrs (Proposed Standard, under IESG Evaluation), and draft-zeilenga-ldap-adlist). We either need to allow special strings to be defined, or disallow anything other than "*" and empty, and raise a red flag concerning those two I-D's Jim >>> "Ramsay, Ron" 4/6/03 7:27:49 PM >>> Why do you believe special strings can be used. I looked at RFC 2251 and, regarding 'attributes', it says there are two special values. One is no values at all and the other is the string "*". The ASN.1 defines 'attributes' to be of type AttributeDescriptionList, which would seem to disallow arbitrary strings? I think it is weirdness and that, as Mark Smith says, controls should be used to cause special behaviours. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Saturday, 5 April 2003 03:37 To: mcs@netscape.com; Kurt@OpenLDAP.org Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org Subject: Re: Extensibility of SearchRequest.attributes I think the first thing to do is get consensus on whether new special attributes are allowed. I believe the intent of RFC 2251 is that special strings can be used to request different things in the return attributes, thus it itself allows a *. I further believe that the RFC simply missed the point that it was self-inconsistent in the way it defined the data type for the return attr specification. Thus, I believe it needs to a) fix the inconsistency, b) allow for future special strings, and possibly c) define how future extensions should be defined. I'm fine with the suggestion Kurt made, though I'm still nervous about the proliferation of special strings. I'd really like to see some "x-" mechanism available--but I agree, that can be done outside the scope of ldapbis. Unless there are other opinions, I will assume consensus is that we do (a) and (b) above. Jim >>> Mark C Smith 4/4/03 8:13:41 AM >>> I agree with the approach suggested by Kurt. Creating an extensibility mechanism for AttributeDescriptions is a new LDAP feature and should be out of scope for LDAPBis. But doing a little work in LDAPBis to allow for the possibility makes sense to me. I am a little concerned about leaving the possibilities for "specials" wide open. If we adopt the statement suggested by Kurt, then servers must accept any octet inside an AttributeDescription. Perhaps most implementations already do, but some may not. -Mark Smith Netscape Kurt D. Zeilenga wrote: > > We need to be careful here. > > That said, another possibility would be to change it to: > SEQUENCE OF AttributeDescriptionOrSpecial > AttributeDescriptionOrSpecial ::= LDAPString > > where the LDAPString is contains a value conforming to the production: > attributeDescriptionOrSpecial = attributeDescription / specials > specials = "*" > > and a statement: > The specials production may be updated by standard track > technical specifications updating this document to allow > additional specials. Servers MUST treat specials they do > not recognize as unrecognized attribute types. > > This leaves the exact form of a future specials up to > future standard track technical specifications. > > If one wanted to allow non-standard track specification of > specials, then one could write a standard track specification > defining a family of specials that have disambiguated by > an IANA registry of specials. I rather leave this to others > (e.g., not LDAPBIS). > > Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 15 01:54:20 2003 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 BAA04526 for ; Tue, 15 Apr 2003 01:54:20 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3F5n0Q3015588; Tue, 15 Apr 2003 05:55:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3F5mw2o015577; Tue, 15 Apr 2003 05:48:58 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 15 Apr 2003 05:48:58 +0000 Received: from adacel.com (gunsmoke.adacel.com.au [210.11.130.7]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3F5msPh015561 for ; Tue, 15 Apr 2003 05:48:55 GMT (envelope-from mark.ennis@adacel.com) Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with MailMarshal (v5,0,3,91) id ; Tue, 15 Apr 2003 15:46:45 +1000 Received: (qmail 23556 invoked from network); 15 Apr 2003 05:43:14 -0000 Received: from unknown (HELO adacel.com) (10.32.24.164) by nexus.adacel.com with SMTP; 15 Apr 2003 05:43:14 -0000 Message-ID: <3E9B9D28.9090209@adacel.com> Date: Tue, 15 Apr 2003 15:48:24 +1000 From: Mark Ennis User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ldapbis@OpenLDAP.org Subject: Should response-auth be optional for digest authentication in authmeth? References: <200303071153.GAA21309@ietf.org> In-Reply-To: <200303071153.GAA21309@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The current draft of authmeth (draft-ietf-ldapbis-authmeth-05.txt) indicates, in section 8.2 paragraph 6, that the response-auth SASL message is only included in the bind response for a successful bind when the server supports subsequent authentication. This seems counter to the intention of RFC2831 section 2.1.3 which indicates that the response-auth should always be returned. The response-auth provides one of the security aspects documented in RFC2831, that of protection against "Spoofing by counterfeit servers" (section 3.8). RFC2617, upon which RFC2831 is based, describes this protection as "The optional response digest in the "response-auth" directive supports mutual authentication -- the server proves that it knows the user's secret, and with qop=auth-int also provides limited integrity protection of the response.". Note that response-auth is optional in RFC2617, but not (in my opinion) in RFC2831. Was this diversion from the apparent intention of RFC2831 intentional and if so, what is the reasoning behind weakening the authentication procedure in this way? Regards, Mark Ennis From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 16 01:59:27 2003 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 BAA23427 for ; Wed, 16 Apr 2003 01:59:26 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3G5woEl008633; Wed, 16 Apr 2003 06:00:13 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3G5w4xS008607; Wed, 16 Apr 2003 05:58:04 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 16 Apr 2003 05:58:04 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3G5w3Eh008593 for ; Wed, 16 Apr 2003 05:58:03 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 15 Apr 2003 23:57:42 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Tue, 15 Apr 2003 23:56:49 -0600 From: "Jim Sermersheim" To: Subject: LDAP URL extension value escapement Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark, I think the definition of exvalue in http://ietf.org/internet-drafts/draft-ietf-ldapbis-url-03.txt is too loose. Multiple extensions are delimited by commas, so we either need to dis-allow commas in the value, or specify that they must be escaped. Jim From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 17 09:57:51 2003 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 JAA21198 for ; Thu, 17 Apr 2003 09:57:50 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3HDr1El019701; Thu, 17 Apr 2003 13:53:41 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3HDo2lf019555; Thu, 17 Apr 2003 13:50:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 17 Apr 2003 13:50:02 +0000 Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3HDo1Eh019529 for ; Thu, 17 Apr 2003 13:50:02 GMT (envelope-from mcs@netscape.com) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h3HDnYn19083 for ; Thu, 17 Apr 2003 06:49:34 -0700 (PDT) Received: from netscape.com ([10.169.192.42]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HDHQC900.GCC; Thu, 17 Apr 2003 06:48:09 -0700 Message-ID: <3E9EB0ED.6030304@netscape.com> Date: Thu, 17 Apr 2003 09:49:33 -0400 From: mcs@netscape.com (Mark C Smith) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: ietf-ldapbis@OpenLDAP.org Subject: Re: LDAP URL extension value escapement References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > Mark, > > I think the definition of exvalue in > http://ietf.org/internet-drafts/draft-ietf-ldapbis-url-03.txt is too > loose. Multiple extensions are delimited by commas, so we either need to > dis-allow commas in the value, or specify that they must be escaped. This is specified in text at the end of section 5: ... An octet MUST be escaped using the % method described in section 2.4 of [RFC2396] in any of these situations: The octet is not in the reserved set defined in section 2.2 of [RFC2396] or in the unreserved set defined in section 2.3 of [RFC2396]. It is the single Reserved character '?' and occurs inside a dn, filter, or other element of an LDAP URL. It is a comma character ',' that occurs inside an extension value. Does that address your concern? -Mark From owner-ietf-ldapbis@OpenLDAP.org Tue Apr 22 11:58:57 2003 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 LAA14582 for ; Tue, 22 Apr 2003 11:58:55 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3MFfeGV072012; Tue, 22 Apr 2003 16:00:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3MFeNGP071973; Tue, 22 Apr 2003 15:40:23 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 22 Apr 2003 15:40:23 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3MFeMEh071937 for ; Tue, 22 Apr 2003 15:40:22 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 22 Apr 2003 09:40:01 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Tue, 22 Apr 2003 09:38:57 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: LDAP URL extension value escapement Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ok, I didn't read that. Is there a reason to not include the escapement rules in the BNF itself? Jim >>> Mark C Smith 4/17/03 7:49:33 AM >>> Jim Sermersheim wrote: > Mark, > > I think the definition of exvalue in > http://ietf.org/internet-drafts/draft-ietf-ldapbis-url-03.txt is too > loose. Multiple extensions are delimited by commas, so we either need to > dis-allow commas in the value, or specify that they must be escaped. This is specified in text at the end of section 5: ... An octet MUST be escaped using the % method described in section 2.4 of [RFC2396] in any of these situations: The octet is not in the reserved set defined in section 2.2 of [RFC2396] or in the unreserved set defined in section 2.3 of [RFC2396]. It is the single Reserved character '?' and occurs inside a dn, filter, or other element of an LDAP URL. It is a comma character ',' that occurs inside an extension value. Does that address your concern? -Mark From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 23 10:41:00 2003 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 KAA21228 for ; Wed, 23 Apr 2003 10:40:59 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3NEfmEl044227; Wed, 23 Apr 2003 14:42:24 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3NEfRT3044202; Wed, 23 Apr 2003 14:41:27 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 23 Apr 2003 14:41:27 +0000 Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3NEfPEh044189 for ; Wed, 23 Apr 2003 14:41:25 GMT (envelope-from mcs@netscape.com) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h3NEf4n09199 for ; Wed, 23 Apr 2003 07:41:04 -0700 (PDT) Received: from netscape.com ([10.169.192.30]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HDSWPV00.1OS; Wed, 23 Apr 2003 07:39:31 -0700 Message-ID: <3EA6A5FF.1070800@netscape.com> Date: Wed, 23 Apr 2003 10:41:03 -0400 From: mcs@netscape.com (Mark C Smith) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: ietf-ldapbis@OpenLDAP.org Subject: Re: LDAP URL extension value escapement References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > > Ok, I didn't read that. Is there a reason to not include the escapement > rules in the BNF itself? Let me think about that one. The escaping rules are applied in a general way to the entire URL. It might be tricky to include them in the BNF (although in principle I agree that would be an improvement). -Mark From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 23 11:08:38 2003 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 LAA22667 for ; Wed, 23 Apr 2003 11:08:37 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3NF5mFD045904; Wed, 23 Apr 2003 15:10:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3NExv7J045523; Wed, 23 Apr 2003 14:59:57 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 23 Apr 2003 14:59:57 +0000 Received: from nb2.stroeder.com (krl9-d9bb4c04.pool.mediaWays.net [217.187.76.4]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3NExsEh045512 for ; Wed, 23 Apr 2003 14:59:54 GMT (envelope-from michael@stroeder.com) Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 90EC57880A for ; Wed, 23 Apr 2003 16:59:50 +0200 (CEST) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 0A69B787FE for ; Wed, 23 Apr 2003 16:59:50 +0200 (CEST) Message-ID: <3EA6AA65.30006@stroeder.com> Date: Wed, 23 Apr 2003 16:59:49 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: ietf-ldapbis@OpenLDAP.org Subject: Re: LDAP URL extension value escapement References: <3EA6A5FF.1070800@netscape.com> In-Reply-To: <3EA6A5FF.1070800@netscape.com> X-Enigmail-Version: 0.74.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark C Smith wrote: > > The escaping rules are applied in a general way to the entire URL. To the entire URL? I'd rather say to the components of the URL. Maybe I did get something wrong. Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 23 14:52:54 2003 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 OAA00459 for ; Wed, 23 Apr 2003 14:52:53 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3NIrnEl059545; Wed, 23 Apr 2003 18:54:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3NImSAE059340; Wed, 23 Apr 2003 18:48:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 23 Apr 2003 18:48:28 +0000 Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3NImREh059314 for ; Wed, 23 Apr 2003 18:48:27 GMT (envelope-from mcs@netscape.com) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h3NIlun15731 for ; Wed, 23 Apr 2003 11:47:57 -0700 (PDT) Received: from netscape.com ([10.169.192.30]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HDT85900.D2A; Wed, 23 Apr 2003 11:46:21 -0700 Message-ID: <3EA6DFDA.9040108@netscape.com> Date: Wed, 23 Apr 2003 14:47:54 -0400 From: mcs@netscape.com (Mark C Smith) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= CC: ietf-ldapbis@OpenLDAP.org Subject: Re: LDAP URL extension value escapement References: <3EA6A5FF.1070800@netscape.com> <3EA6AA65.30006@stroeder.com> In-Reply-To: <3EA6AA65.30006@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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-Unsubscribe: Content-Transfer-Encoding: 8bit Michael Ströder wrote: > Mark C Smith wrote: > > > > The escaping rules are applied in a general way to the entire URL. > > To the entire URL? I'd rather say to the components of the URL. > Maybe I did get something wrong. No, you are right. I should've said "applied in a general way to components of the URL." But even the word "general" is a little misleading because of the special case for commas inside URL extensions. -Mark From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 23 22:59:08 2003 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 WAA19645 for ; Wed, 23 Apr 2003 22:59:07 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3O2xqEl086320; Thu, 24 Apr 2003 03:00:27 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3O2rur0086150; Thu, 24 Apr 2003 02:53:56 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 24 Apr 2003 02:53:56 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3O2rtEh086140 for ; Thu, 24 Apr 2003 02:53:55 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h3O2rtDV048466 for ; Thu, 24 Apr 2003 02:53:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030423194532.021a4060@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 23 Apr 2003 19:51:38 -0700 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Integer ABNF in syntaxes I-D Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I think the production Integer = [ HYPHEN ] number is incorrect. I think it should be: Integer = ( HYPEN LDIGIT *DIGIT ) / number That is, -0 should be invalid. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 24 02:12:43 2003 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 CAA05391 for ; Thu, 24 Apr 2003 02:12:43 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3O6BrEl091966; Thu, 24 Apr 2003 06:12:46 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3O68R48091881; Thu, 24 Apr 2003 06:08:27 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 24 Apr 2003 06:08:27 +0000 Received: from adacel.com (gunsmoke.adacel.com.au [210.11.130.7]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3O68OEh091834 for ; Thu, 24 Apr 2003 06:08:25 GMT (envelope-from steven.legg@adacel.com.au) Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with MailMarshal (v5,0,3,91) id ; Thu, 24 Apr 2003 16:06:13 +1000 Received: (qmail 24751 invoked from network); 24 Apr 2003 06:08:01 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 24 Apr 2003 06:08:01 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" , Subject: RE: Integer ABNF in syntaxes I-D Date: Thu, 24 Apr 2003 16:08:00 +1000 Message-ID: <002a01c30a27$dc4f6960$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <5.2.0.9.0.20030423194532.021a4060@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > I think the production > Integer = [ HYPHEN ] number > > is incorrect. I think it should be: > Integer = ( HYPEN LDIGIT *DIGIT ) / number Agreed. I've made the change for the next revision of the draft. Regards, Steven > > > That is, -0 should be invalid. > > Kurt > > From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 24 07:30:05 2003 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 HAA11238 for ; Thu, 24 Apr 2003 07:30:05 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3OBTtEl010442; Thu, 24 Apr 2003 11:30:39 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3OBSexJ010315; Thu, 24 Apr 2003 11:28:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 24 Apr 2003 11:28:40 +0000 Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3OBSbEh010283; Thu, 24 Apr 2003 11:28:38 GMT (envelope-from hbf@bombur.uio.no) Received: from mons.uio.no ([129.240.130.14]) by pat.uio.no with esmtp (Exim 2.12 #7) id 198eu3-00055V-00; Thu, 24 Apr 2003 13:28:35 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 198ety-0000kn-00; Thu, 24 Apr 2003 13:28:30 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 198ett-0001pW-00; Thu, 24 Apr 2003 13:28:25 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Integer ABNF in syntaxes I-D In-reply-to: <5.2.0.9.0.20030423194532.021a4060@127.0.0.1> Date: Thu, 24 Apr 2003 13:28:25 +0200 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt D. Zeilenga wrote: > I think the production > Integer = [ HYPHEN ] number > > is incorrect. I think it should be: > Integer = ( HYPEN LDIGIT *DIGIT ) / number > > That is, -0 should be invalid. I don't see why. What I'm wondering is why 003 is invalid. Though I agree that either both should be valid or both invalid. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 24 09:35:28 2003 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 JAA16116 for ; Thu, 24 Apr 2003 09:35:28 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3ODZtEl020059; Thu, 24 Apr 2003 13:36:06 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3ODV3T5019448; Thu, 24 Apr 2003 13:31:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 24 Apr 2003 13:31:03 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3ODV2Eh019436 for ; Thu, 24 Apr 2003 13:31:02 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h3ODV1DV052412; Thu, 24 Apr 2003 13:31:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030424060519.022d3e88@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 24 Apr 2003 06:28:44 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Integer ABNF in syntaxes I-D Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030423194532.021a4060@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 04:28 AM 4/24/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga wrote: >> I think the production >> Integer = [ HYPHEN ] number >> >> is incorrect. I think it should be: >> Integer = ( HYPEN LDIGIT *DIGIT ) / number >> >> That is, -0 should be invalid. > >I don't see why. What I'm wondering is why 003 is invalid. >Though I agree that either both should be valid or both invalid. Because implementations, clients in particular, are very bad at parsing anything out of the ordinary. For example, consider all the clients which improperly treat anything starting with a "0" as base 8. Or clients which choke on "-0". Operational experience has shown that providing multiple encoding options leads to interoperability problems as not all implementations will implement (proper) decoders for each case. It is much better to have only one encoding option and promote ("be liberal in what you except but strict in what you generate"). Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 24 10:33:01 2003 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 KAA18387 for ; Thu, 24 Apr 2003 10:33:01 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3OEHtFj026034; Thu, 24 Apr 2003 14:34:34 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3OEGABY025845; Thu, 24 Apr 2003 14:16:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 24 Apr 2003 14:16:09 +0000 Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3OEG6Eh025795; Thu, 24 Apr 2003 14:16:07 GMT (envelope-from hbf@bombur.uio.no) Received: from mons.uio.no ([129.240.130.14]) by pat.uio.no with esmtp (Exim 2.12 #7) id 198hW9-0003Z4-00; Thu, 24 Apr 2003 16:16:05 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 198hW9-0003IE-00; Thu, 24 Apr 2003 16:16:05 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 198hW8-0002GG-00; Thu, 24 Apr 2003 16:16:04 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Integer ABNF in syntaxes I-D In-Reply-To: <5.2.0.9.0.20030424060519.022d3e88@127.0.0.1> References: <5.2.0.9.0.20030423194532.021a4060@127.0.0.1> <5.2.0.9.0.20030424060519.022d3e88@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 24 Apr 2003 16:16:04 +0200 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt D. Zeilenga writes: >At 04:28 AM 4/24/2003, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga wrote: >>> That is, -0 should be invalid. >> >>I don't see why. What I'm wondering is why 003 is invalid. >>Though I agree that either both should be valid or both invalid. > > Because implementations, clients in particular, are very bad > at parsing anything out of the ordinary. (...) OK. > It is much better to have only one encoding option and promote ("be > liberal in what you except but strict in what you generate"). With 'liberal in what you expect', do you mean a server could accept -0 and 003, but if so it should rewrite them to 0 and 3? Do the drafts allow that? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Apr 24 11:19:31 2003 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 LAA19632 for ; Thu, 24 Apr 2003 11:19:30 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3OF5uFP032062; Thu, 24 Apr 2003 15:21:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3OF0Lqt031847; Thu, 24 Apr 2003 15:00:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 24 Apr 2003 15:00:21 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3OF0KEh031837 for ; Thu, 24 Apr 2003 15:00:20 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h3OF0JDV053174; Thu, 24 Apr 2003 15:00:19 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030424072649.0228dfd0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 24 Apr 2003 07:58:01 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Integer ABNF in syntaxes I-D Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030424060519.022d3e88@127.0.0.1> <5.2.0.9.0.20030423194532.021a4060@127.0.0.1> <5.2.0.9.0.20030424060519.022d3e88@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 07:16 AM 4/24/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 04:28 AM 4/24/2003, Hallvard B Furuseth wrote: >>>Kurt D. Zeilenga wrote: >>>> That is, -0 should be invalid. >>> >>>I don't see why. What I'm wondering is why 003 is invalid. >>>Though I agree that either both should be valid or both invalid. >> >> Because implementations, clients in particular, are very bad >> at parsing anything out of the ordinary. (...) > >OK. > >> It is much better to have only one encoding option and promote ("be >> liberal in what you except but strict in what you generate"). s/except/accept/ >With 'liberal in what you expect', do you mean a server could accept -0 >and 003, but if so it should rewrite them to 0 and 3? s/server/implementation/ and s/should/must/, yes. >Do the drafts allow that? I don't recall an explicit statement to this effect in the drafts, but I believe it is allowed by general interoperability principles of the Internet. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 30 06:24:07 2003 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 GAA27374 for ; Wed, 30 Apr 2003 06:24:06 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3UAOfEl024659; Wed, 30 Apr 2003 10:25:43 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3UAO5sO024644; Wed, 30 Apr 2003 10:24:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 30 Apr 2003 10:24:05 +0000 Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3UAO3Eh024586 for ; Wed, 30 Apr 2003 10:24:04 GMT (envelope-from gvithalprasad@novell.com) Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Wed, 30 Apr 2003 04:23:43 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Wed, 30 Apr 2003 04:23:31 -0600 From: "Vithalprasad Gaitonde" To: Cc: "Vijay KN" , "Savitha R" Subject: result code for a deleted identity on a connection Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit If a client does a bind with an identity and then while the bound connection is still open, the object which has bound gets deleted, what is the expected server behaviour when the client tries to make the next request on that connection? Should the connection revert to anonymous ? - This seems inappropriate as the client would not know why he is suddenly not getting access to some objects which he had access to earlier. The appropriate behaviour should probably be to send a result code back and close the connection (as if there had been an unbind). None of the current result codes defined in http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-13.txt seem to be apprpriate for this. The closest is insufficient access. We should probably have a result code like invalidIdentity which is sent back with a notice of disconnection (section 4.4.1 protocol draft) followed by a closing of the connection by the server. Comments ? Prasad From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 30 08:28:34 2003 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 IAA29729 for ; Wed, 30 Apr 2003 08:28:34 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3UCIgFD030164; Wed, 30 Apr 2003 12:29:59 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3UCEA86029966; Wed, 30 Apr 2003 12:14:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 30 Apr 2003 12:14:10 +0000 Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3UCE8Eh029956 for ; Wed, 30 Apr 2003 12:14:09 GMT (envelope-from hbf@bombur.uio.no) Received: from mons.uio.no ([129.240.130.14]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19AqTI-00019j-00; Wed, 30 Apr 2003 14:14:00 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 19AqTG-00020a-00; Wed, 30 Apr 2003 14:13:58 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19AqTB-0006mT-00; Wed, 30 Apr 2003 14:13:53 +0200 From: Hallvard B Furuseth Message-Id: To: Vithalprasad Gaitonde Cc: ietf-ldapbis@OpenLDAP.org, Vijay KN , Savitha R Subject: Re: result code for a deleted identity on a connection In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 30 Apr 2003 14:13:53 +0200 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Vithalprasad Gaitonde writes: > If a client does a bind with an identity and then while the bound > connection is still open, the object which has bound gets deleted, what > is the expected server behaviour when the client tries to make the next > request on that connection? > Should the connection revert to anonymous ? - This seems inappropriate > as the client would not know why he is suddenly not getting access to > some objects which he had access to earlier. Right. > The appropriate behaviour should probably be to send a result code back > and close the connection (as if there had been an unbind). I suspect it might be a lot of work for servers to keep track of this. So I think the server should have that option, but it should also have the option not to notice this condition and keep serving requests as if nothing happened. > None of the current result codes defined in > http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-13.txt > seem to be apprpriate for this. The closest is insufficient access. > We should probably have a result code like invalidIdentity How about invalidCredentials? > which is sent back with a notice of disconnection (section 4.4.1 > protocol draft) followed by a closing of the connection by the server. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 30 08:28:45 2003 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 IAA29744 for ; Wed, 30 Apr 2003 08:28:44 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3UCUfEl031247; Wed, 30 Apr 2003 12:30:44 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3UCRJxO030833; Wed, 30 Apr 2003 12:27:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 30 Apr 2003 12:27:19 +0000 Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3UCRIEh030788 for ; Wed, 30 Apr 2003 12:27:18 GMT (envelope-from gvithalprasad@novell.com) Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Wed, 30 Apr 2003 06:26:58 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Wed, 30 Apr 2003 06:26:46 -0600 From: "Vithalprasad Gaitonde" To: Cc: "Vijay KN" , "Savitha R" , Subject: Re: result code for a deleted identity on a connection Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit "I suspect it might be a lot of work for servers to keep track of this. So I think the server should have that option, but it should also have the option not to notice this condition and keep serving requests as if nothing happened." Well...wouldn't this be a security breach. The object may have been deleted by the administrator as he is an invalid user for the directory (e.g. left the Organization). In such a case, it would be inappropriate for the user to be allowed access. invalidCredentials may be a misleading error code to return as the bind has already succeeded. Prasad >>> Hallvard B Furuseth 4/30/2003 5:43:53 PM >>> Vithalprasad Gaitonde writes: > If a client does a bind with an identity and then while the bound > connection is still open, the object which has bound gets deleted, what > is the expected server behaviour when the client tries to make the next > request on that connection? > Should the connection revert to anonymous ? - This seems inappropriate > as the client would not know why he is suddenly not getting access to > some objects which he had access to earlier. Right. > The appropriate behaviour should probably be to send a result code back > and close the connection (as if there had been an unbind). I suspect it might be a lot of work for servers to keep track of this. So I think the server should have that option, but it should also have the option not to notice this condition and keep serving requests as if nothing happened. > None of the current result codes defined in > http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-13.txt > seem to be apprpriate for this. The closest is insufficient access. > We should probably have a result code like invalidIdentity How about invalidCredentials? > which is sent back with a notice of disconnection (section 4.4.1 > protocol draft) followed by a closing of the connection by the server. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 30 09:43:03 2003 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 JAA03010 for ; Wed, 30 Apr 2003 09:43:03 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3UDUgFV035743; Wed, 30 Apr 2003 13:44:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3UDTsLR035651; Wed, 30 Apr 2003 13:29:54 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 30 Apr 2003 13:29:54 +0000 Received: from boole.openldap.org (kurt@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3UDTrEh035629 for ; Wed, 30 Apr 2003 13:29:53 GMT (envelope-from kurt@boole.openldap.org) Received: (from kurt@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) id h3UDTqUh035628 for ietf-ldapbis@openldap.org; Wed, 30 Apr 2003 13:29:52 GMT (envelope-from kurt) Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3UCL1Eh030245 for ; Wed, 30 Apr 2003 12:21:01 GMT (envelope-from KNVIJAY@novell.com) Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Wed, 30 Apr 2003 06:20:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Wed, 30 Apr 2003 06:20:28 -0600 From: "Vijay KN" To: , "Vithalprasad Gaitonde" Cc: "Savitha R" , Subject: Re: result code for a deleted identity on a connection Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hallvard, I am not very clear how a server can continue to serve requests on the connection. If new objects are created on the connection after the user object deletion, then what is the user-id assigned by the server as the creator/owner for such objects (since the user object has been deleted) ? Audit logs would show that objects were created by the user, after the user object had been deleted. Isn't this a problem ? Vijay >>> Hallvard B Furuseth 4/30/2003 5:43:53 PM >>> Vithalprasad Gaitonde writes: > If a client does a bind with an identity and then while the bound > connection is still open, the object which has bound gets deleted, what > is the expected server behaviour when the client tries to make the next > request on that connection? > Should the connection revert to anonymous ? - This seems inappropriate > as the client would not know why he is suddenly not getting access to > some objects which he had access to earlier. Right. > The appropriate behaviour should probably be to send a result code back > and close the connection (as if there had been an unbind). I suspect it might be a lot of work for servers to keep track of this. So I think the server should have that option, but it should also have the option not to notice this condition and keep serving requests as if nothing happened. > None of the current result codes defined in > http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-13.txt > seem to be apprpriate for this. The closest is insufficient access. > We should probably have a result code like invalidIdentity How about invalidCredentials? > which is sent back with a notice of disconnection (section 4.4.1 > protocol draft) followed by a closing of the connection by the server. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 30 11:05:08 2003 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 LAA08069 for ; Wed, 30 Apr 2003 11:05:08 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3UF6jEp045118; Wed, 30 Apr 2003 15:06:58 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3UEx7Co044518; Wed, 30 Apr 2003 14:59:07 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 30 Apr 2003 14:59:07 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3UEx6Eh044508 for ; Wed, 30 Apr 2003 14:59:06 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h3UEx09a017498; Wed, 30 Apr 2003 14:59:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030430070834.02a42210@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Apr 2003 07:56:37 -0700 To: "Vithalprasad Gaitonde" From: "Kurt D. Zeilenga" Subject: Re: result code for a deleted identity on a connection Cc: , "Vijay KN" , "Savitha R" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 03:23 AM 4/30/2003, Vithalprasad Gaitonde wrote: >If a client does a bind with an identity and then while the bound >connection is still open, the object which has bound gets deleted, what >is the expected server behaviour when the client tries to make the next >request on that connection? The server should likely disconnect the client immediately upon knowing the credentials are no longer valid. (I note that the server may not immediately know the credentials are invalid.) >Should the connection revert to anonymous ? Well, I think the server should move the client into an "authentication state unknown" state and refuse to process operations (other those which establish authentication associations) until both client and server have established a new authentication association. That is, the server should not just continue as if the client had established an anonymous authentication association. >We should probably have a result code like invalidIdentity which is >sent back with a notice of disconnection (section 4.4.1 protocol draft) >followed by a closing of the connection by the server. RFC 2251, 4.4.1: > - strongAuthRequired: The server has detected that an established > underlying security association protecting communication between > the client and server has unexpectedly failed or been compromised. I think it would be reasonable to return this in this case as well. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 30 17:23:51 2003 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 RAA24673 for ; Wed, 30 Apr 2003 17:23:50 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3ULOjEl076920; Wed, 30 Apr 2003 21:25:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3ULJZlV076633; Wed, 30 Apr 2003 21:19:35 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 30 Apr 2003 21:19:35 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3ULJXEh076618 for ; Wed, 30 Apr 2003 21:19:33 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h3ULJX9a020374 for ; Wed, 30 Apr 2003 21:19:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030430135114.02a35608@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Apr 2003 14:17:09 -0700 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: protocol: new SASL layers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I believe this text should be deleted. > If a SASL transfer encryption or integrity mechanism has been negotiated, > that mechanism does not support the changing of credentials from one > identity to another, then the client MUST instead establish a new > connection. Each SASL negotiation is, generally, independent of other SASL negotiations. If there were dependencies between multiple negotiations of a particular mechanism, the mechanism technical specification should detail how applications are to deal with them. LDAP should not require any special handling. And if an LDAP client had used such a mechanism, it would have the option of using another mechanism. Comments? Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Apr 30 17:58:50 2003 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 RAA25562 for ; Wed, 30 Apr 2003 17:58:49 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3UM0mEl078461; Wed, 30 Apr 2003 22:01:00 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) with SMTP id h3ULxdbk078399; Wed, 30 Apr 2003 21:59:39 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 30 Apr 2003 21:59:39 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h3ULxcEh078388 for ; Wed, 30 Apr 2003 21:59:38 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h3ULxb9a020688 for ; Wed, 30 Apr 2003 21:59:37 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030430145215.02963190@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Apr 2003 14:57:14 -0700 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Re: protocol: new SASL layers In-Reply-To: <5.2.0.9.0.20030430135114.02a35608@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Additionally, it should be made clear in the technical specification that SASL layers, once installed in a session, can be replaced with new SASL layers (after appropriate SASL negotiation) but cannot be de-installed. That is, completing DIGEST-MD5 authentication with layers followed by a simple bind does not cause the layers to be de-installed. Kurt At 02:17 PM 4/30/2003, Kurt D. Zeilenga wrote: >I believe this text should be deleted. >> If a SASL transfer encryption or integrity mechanism has been negotiated, >> that mechanism does not support the changing of credentials from one >> identity to another, then the client MUST instead establish a new >> connection. > >Each SASL negotiation is, generally, independent of other SASL >negotiations. If there were dependencies between multiple >negotiations of a particular mechanism, the mechanism technical >specification should detail how applications are to deal with >them. LDAP should not require any special handling. And if >an LDAP client had used such a mechanism, it would have the >option of using another mechanism. > >Comments? > >Kurt